Subject: Re: [IEE] WG Review: Email Address Internationalization (eai)

From: Martin Duerst <[email-masked]>
Date: Wed, 01 Mar 2006 16:39:57 +0900

Hello Dave,

At 17:47 06/02/27, you wrote:

 >> It may be the first time somebody is saying that using all 8 bits
 >> that TCP/IP provides needs a research effort.
 >
 >Since it is not what I said, it probably does not help dialogue to 
represent my concern this way.

Sorry to start my comments with this somewhat provocative and
simplifying statement.

You still may want to answer the rest of my mail.

I also agree with what Yangwoo Ko has said, and you seem to agree
to a large extent, too. My understanding is that we are all not
sure how well deployment will work, and we are very well aware
of the fact that deployment will be critical, and we need to work
hard to try to come up with finetuned proposals that do the best
in this respect.

Taking that back to the IRTF vs. Experimental discussion, it seems
to me that the only way to do research (if you want to call it that)
about deployment issues is to actually try to, at least experimentally,
deploy the technology. Testing out different alternatives/configurations/
settings as one would usually do in research doesn't seem like an
option. In my view even the Experimental stamp will hold back some
real-world deployment that might happen with Proposed. That's why
I said that I personally preferred Standards track: It's better to
go to Proposed and if necessary later to historical/obsolete than to
do IRTF or Experimental and miss a deployment opportunity because
we never actually really tried.

Regards,     Martin. 

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Yangwoo Ko <[email-masked]>
Date: Fri, 03 Mar 2006 18:18:53 +0900

Dear Dave Crocker,

Thanks for good points. Please find my replies embedded below.

Regards

Dave Crocker wrote:

>
> > Dicussion between Dave and John, quoted above, can be understood as how
>
>> significant it will be? I'd rather interpret the "significance" in 
>> somewhat different aspect.
>
>
> I think you have describe the question correctly.
>
> I think that a change in the form of email addresses that can cause 
> delivery to fail should be considered significant.

(Off-topic) Are we "changing the form" of email addresses? As a 
non-native English
speaker, it is always very hard to grasp various meanings and usages of 
English words.
I think we are just "adding more forms" thanks to the nice property of 
UTF-8.

(On) Delivery failure is not always bad. Through a failure notice, a 
user is able to see that
he/she should use alternative addresses if available. Though I don't 
think this type of human
assisted address alternation is the best engineering solution, it is 
still one of valuable
options we can take.

>
> It can/will partition the functional infrastructure.
>
>
>> As we assume, it seems to be relatively easy to do IMA only between 
>> agreed parties. The real devil lies at the boundary.
>
>
> Yes.  Exactly correct.
>
>
>> However good news is that, as a design team of this extention, we 
>> have a knob that controls how significantly we want to change the 
>> infrastructure. For example, in one extreme, we can just drop any 
>> mail that tries to cross the boundary. On the other extreme, every 
>> part of the Internet infrastructure is required to be upgraded 
>> somehow to support IMA so perfectly that users cannot even recognize 
>> that there is such boundary. In order to make IMA more usable, we 
>> want to deviate from the former extreme as much as possible. In order 
>> to make IMA be more practical, we cannot but deviate from the other 
>> extreme.
>
>
> How does a design team control the operational behavior of boundary 
> MTAs?  The experience with gatewaying between independent mail 
> services is that it is a challenge, at best.

I don't see your point. If a standard cannot define the behavior
of "compliant" components, then what is that standard for?

Or, are you saying that it is impossible to standardize the
behavior of gateways because the complexity of gatewaying
is simply beyond the human-being's brain power?

> Further, the experience with the use of "private" IP Addresses within 
> networks is they leak out into the public Internet.

Yes. They will leak regardless of how hard we try to
design the right thing. However, we have defined private IP address
range and users are using it everyday. Because it is very useful to
solve many real issues.

No one can say that I18N addresses will not leak at all. Users who
are not using EAI-enabled components will get hurt from time
to time. It seems impossible (or at least impractically hard) to avoid
this type of uncomfort completely. If IETF as a community
has a rough consensus that any form of leak with any frequency is
significant and  any new idea leading to that significant change should
be dealt by IRTF, then let EAI be discussed at IRTF.

>
> In the last 25 years, there have been somewhere between 0 and few 
> efforts to affect basic deliverability.  (DSN is the possible 
> exception and it's adoption history provides quite an education.)
>
> d/
>

---

From: Dave Crocker <[email-masked]>
Date: Sun, 12 Mar 2006 12:58:10 -0800

Yangwoo Ko,

> I think we are just "adding more forms" thanks to the nice property of 

(I think your English is excellent, and that asking about my use of "form", 
here, is entirely reasonable, even among native English speakers.)

A basic justification for using 'native' UTF-8 is that it is now very widely 
available on end-user systems.  Indeed, this is a powerful argument for doing 
things differently today than has been done in the past. That is, this is the 
reason to use UTF-8, for the larger set of characters -- rather than to perform 
a special encoding on top of existing net ASCII.

So I hope it is clear that the concern I am expressing is not with the choice to 
use 'native' UTF-8.  Originally I questioned this choice, but I now think that 
the justification for doing UTF-8 is quite solid.  (Forgive my quoting the word 
native, but I like to keep in mind that UTF-8, itself, is merely an encoding of 
the native data form.  As was pointed out, we tend to not even use the correct 
name for that form.)

However, I think that the change being described is quite basic, because it 
means that legacy email implementations will not be able to process addresses 
that are in the new form.  This means that the new email address rules will 
create a separate, parallel name space.

(I suppose that, strictly speaking, the new space is a superset -- I think this 
is what you mean by "adding more forms" and I believe your are correct. However, 
this upgrade means that old email systems cannot directly exchange mail with new 
environments.  This is, of course, a very basic disruption to Internet mail 
service.)

In order to exchange mail between the new and the old environments there MUST be 
a gateway -- and I mean gateway in the true sense: a relay that modifies the 
message, in order to overcome incompatibilities between the two environments.

Most significant is that this incompatibility is with addressing.  An impact 
does not get any more basic, for email.

(By the way, folks are using the term "downgrading" and I believe that that is 
technically incorrect.  Downgrading usually means that information is lost.  I 
believe that a gateway between legacy email and EAI email will merely encode the 
address differently,rather than lose any addressing information detail.  If this 
understanding is incorrect, it needs to be clarified.)

> he/she should use alternative addresses if available. 

Please forgive me for disagreeing.

First of all this creates an enormous burden on end-users, and the average 
end-user will not have any idea how to fix the problem -- or, at least, I think 
that it is unreasonable to expect them to.

Second, the fact that email is store-and-forward can mean that there is 
indirection, such as with mailing lists.  So it is not at all clear that the 
correct entity will receive the notification, or that they will be given enough 
information.

Though I don't
> assisted address alternation is the best engineering solution, it is 

I think the impact of suddenly finding that email addressing does not always 
work is a rather serious impact on the perceived reliability and easy-of-use, 
Internet mail.

> of "compliant" components, then what is that standard for?

My point is that the EAI effort needs to specify the gateway standard as an 
integral part of the work.  Otherwise we are certain to partition Internet mail.

> is simply beyond the human-being's brain power?

I believe it is possible to specify the necessary gateway. In fact I suspect 
that this could be one of the more easy gateway specification tasks.

My point is that I believe it cannot be treated as a secondary or optional 
function.  I believe it is in the critical path and must be published at the 
same time as the basic EAI specification.

(Just to make something clear, I am extremely unhappy to hold this view.  I very 
much try to make the critical path as small as possible and I very much try to 
defer work on gateways.)

> range and users are using it everyday. Because it is very useful to

The difference is that all of the private addresses were specially reserved. 
Hence, it is often possible to detect their inappropriate occurrence, when they 
do leak.

Will that be true for EAI?

>  If IETF as a community

Indeed, it is not reasonable to demand perfection.  However I think it is 
equally unreasonable to treat the impact of this type of imperfection as secondary.

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>