Subject: [EAI] ALT-ADDRESS and ATOMIC

From: Tony Finch <[email-masked]>
Date: Wed, 7 Jun 2006 22:05:04 +0100

Will the rationale for the ALT-ADDRESS and ATOMIC options be included in
any of the drafts? (Sorry if it's already there and I have missed it.)

Why not just require that downgrading is always possible? This would make
both options unnecessary, and I like the idea because it reduces the
number of protocol options and I can see some awkward interop and
usability problems caused by their existence.

I see problems coming from the fact that the correct values for the
ALT-ADDRESS and ATOMIC options must be accurately communicated from the
recipient to the sender before the message is sent. In the case of a
reply, how can senders extract these values from the messages they are
replying to?

In other cases, I imagine that it might be possible to get the values from
some structured electronic medium, such as an internationalized vcard or
an ldap directory with an internationalized schema or perhaps an extended
form of mailto: URI. In many cases the utf8 address will be cut-and-pasted
from a document or manually typed in from paper, and there's not the
slightest chance that you can expect users to understand the importance of
the IMA metadata or to transcribe it correctly. Furthermore, there's no
way that any automatic system in the sender's MUA or MSA can correct a
mistake.

What happens when there is a mistake? Does bouncing an erroneously
downgraded message have the same effect on the sender as bouncing a
message because it cannot be downgraded? If a sender's address book
mixes up the recipient's alt-address with one of the recipient's unrelated
non-utf8 addresses, the incorrect end site may or may not handle the
downgraded message sensibly.

Note that if all utf8 addresses are downgradeable, then internationalizing
email addresses in vcards or LDAP or URIs etc. is relatively simple: the
email address is still just a single field (without new IMA metadata); it
just has a more relaxed syntax.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
HEBRIDES: SOUTH OR SOUTHWEST 4 OR 5, OCCASIONALLY 6 IN NORTHWEST. RAIN OR
DRIZZLE. MODERATE OR GOOD WITH FOG PATCHES.

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

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Jun 2006 19:23:14 -0400

--On Wednesday, 07 June, 2006 22:05 +0100 Tony Finch
<[email-masked]> wrote:

> Will the rationale for the ALT-ADDRESS and ATOMIC options be
> included in any of the drafts? (Sorry if it's already there
> and I have missed it.)

Yes.  It is most likely to show up in a non-WG draft that
discusses constraints on solutions  and systems that are so
overconstrained as to make solutions impossible.  For a preview,
find one of the later versions of draft-klensin-emailaddr-i18n,
probably about -03.

> Why not just require that downgrading is always possible? This
> would make both options unnecessary, and I like the idea
> because it reduces the number of protocol options and I can
> see some awkward interop and usability problems caused by
> their existence.

Because, in the most general case, downgrading is simply not
possible, at least without imposing unreasonable constraints.
The problem, briefly, is that all sorts of things get encoded
into email local-parts today and one cannot downgrade addresses
on a message without either (i) giving up the ability to do the
things those encodings are used for in i18n messages (i.e.,
restricting their use to ASCII messages or (ii) strongly
restricting the order in which message-receiving MTAs do things,
i.e., their order of operations.   Neither of those options
seemed acceptable and, if we want to see deployment without
completely rewriting MTAs that are otherwise easy to adapt, wise.
 
> I see problems coming from the fact that the correct values
> for the ALT-ADDRESS and ATOMIC options must be accurately
> communicated from the recipient to the sender before the
> message is sent. In the case of a reply, how can senders
> extract these values from the messages they are replying to?

The right mechanism(s) for carrying this information is the
headers is being worked on now.  For a message that has already
been downgraded, the recipient should not have a problem.  For
one that is delivered with the utf8-addresses intact, presumably
the recipient won't send the message out via hosts or relays
that will require downgrading in the overwhelming number of
cases.   But the answer is that, in the most general case, what
you ask for may not be possible.

> In other cases, I imagine that it might be possible to get the
> values from some structured electronic medium, such as an
> internationalized vcard or an ldap directory with an
> internationalized schema or perhaps an extended form of
> mailto: URI. In many cases the utf8 address will be
> cut-and-pasted from a document or manually typed in from
> paper, and there's not the slightest chance that you can
> expect users to understand the importance of the IMA metadata
> or to transcribe it correctly. Furthermore, there's no way
> that any automatic system in the sender's MUA or MSA can
> correct a mistake.

Right.  There are some other cases that are even worse.

> What happens when there is a mistake? Does bouncing an
> erroneously downgraded message have the same effect on the
> sender as bouncing a message because it cannot be downgraded?
> If a sender's address book mixes up the recipient's
> alt-address with one of the recipient's unrelated non-utf8
> addresses, the incorrect end site may or may not handle the
> Note that if all utf8 addresses are downgradeable, then
> internationalizing email addresses in vcards or LDAP or URIs
> etc. is relatively simple: the email address is still just a
> single field (without new IMA metadata); it just has a more
> relaxed syntax.

Sure.  And, no disrepect intended, but if all pigs flew long
distances along paths that could be plotted, one could figure
out some interesting solutions to hunger problems in some parts
of the world.  

Unfortunately, if one imposes the constraints  "all messages
must be downgradable and downgrading is always required" then
the result is going to be either

* No internationalized email addresses or 

* Severe constraints on the features and characteristics of
email that can be used with such addresses

And, unfortunately, that choice is quite likely to lead to a
third choice:

* many local systems for doing email in particular languages and
scripts that don't, in general, interoperate with each other

A different way to look at this is that, in the current email
environment, if you send a message to me and can't spell my name
exactly the way I spell it, the message is going to bounce: the
mail system doesn't give you any right to expect corrections or
adaptation to near-matches, although some systems will do that.
If you have a Chinese colleague and try to use her Chinese
address, and can't spell the name exactly the way she spells it,
you also expect the message to bounce.   If you extend that
principle to your having to spell the address in the same way
that she, and all intermediate systems, spell it, we would be in
exactly the same position we would be in if we _never_
downgrade.  

Efforts are underway to define downgrading so that it can be
applied when it is appropriate, when people want to do the work,
and when circumstances are right.  Some reasonable people
believe that, in practice, it won't be used much and things will
bounce when messages with i18n information are transmitted
between upgraded and un-upgraded systems.

     john

---

From: Yangwoo Ko <[email-masked]>
Date: Thu, 08 Jun 2006 10:58:28 +0900

> find one of the later versions of draft-klensin-emailaddr-i18n,
Section 2.4 of eai-smtpext-00 draft includes a little stuff for this as 
well.
> (snip)

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 08 Jun 2006 10:50:20 +0100

> usability problems caused by their existence.

I never did understand what this was not so, but John keeps assuring us  
that it is. So please could we have a plausible example of something that  
would not work without "ATOMIC", and in which even upgrading a previously  
ACEd local-part would not be good enough.
> reply, how can senders extract these values from the messages they are

It is clear to me that ATOMICITY is a property of the mailbox, and  
therefore must be included syntactically within the interlationalized  
mailbox somehow. It would then appear automatically in the Reply-To header  
and in lists of published email addresses and in lists kept by list  
expanders. It would also pass the telephone and fax tests that way.

But I thought we had already agreed to do that. There seems to be  
agreement that the syntax of an internationalized mailbox may include an  
ALT-ADDRESS (though it is yet unresolved whether the separator will be  
",", "|" or something else). It was also stated that the ATOMIC property  
would appear in it somewhere, though I never saw any suggested syntax for  
that.

Essentially, ATOMICITY is a property of the local-part, so it should  
syntactically be associated with that (even having the local-part begin  
with "ATOMIC would work, but is ugly). Perhaps some other separator than  
"@", or maybe a double "@@" to signify atomicity?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Tony Finch <[email-masked]>
Date: Thu, 8 Jun 2006 18:29:47 +0100

On Wed, 7 Jun 2006, John C Klensin wrote:
>
> > Why not just require that downgrading is always possible?
>
> Because, in the most general case, downgrading is simply not possible,
> at least without imposing unreasonable constraints. The problem,
> briefly, is that all sorts of things get encoded into email local-parts
> today and one cannot downgrade addresses on a message without either (i)
> giving up the ability to do the things those encodings are used for in
> i18n messages (i.e., restricting their use to ASCII messages or (ii)
> strongly restricting the order in which message-receiving MTAs do
> things, i.e., their order of operations.  Neither of those options
> seemed acceptable and, if we want to see deployment without completely
> rewriting MTAs that are otherwise easy to adapt, wise.

I've looked at the longer version of this argument in
draft-klensin-emailaddr-i18n-03 and I think I understand the point,
but I still don't think the "atomic" flag is necessary.

As things are specified at the moment, if I send an 14ed message to your
i14ed "atomic" address with no alt-address, and an intermediate MTA is not
i14ed, then the message has to be bounced.

However, the reason your address is "atomic" is that your system can't
handle downgraded addresses correctly, i.e. in the way it would if they
were still in their canonical form. So why can't YOUR system just
bounce those problem addresses?

I suppose your special processing might do something foolish instead of
bouncing the message, but in that case it would do something foolish if I
sent it ascii-only gibberish, and we've still lost nothing by the absence
of ATOMIC.

When I sent my previous message I was also skeptical about the utility of
alt-addresses, but on further thought I decided there might be an
aesthetic argument for attaching them to the various "from" addresses, so
that an ascii-only recipient has a non-obfuscated address to reply to. I
now see that alt-addresses might also be a work-around for non-"atomic"
i14ed addresses (both "from" and "to"), where the special processing of
the alt-address would work in cases where it wouldn't for an
auto-downgraded address. I remain somewhat doubtful that people will be
able to use them effectively.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FORTIES CROMARTY FORTH TYNE DOGGER: VARIABLE BECOMING SOUTHEAST 3 OR 4,
OCCASIONALLY 5 LATER IN CROMARTY. FAIR. MODERATE WITH FOG PATCHES.

---

From: Yangwoo Ko <[email-masked]>
Date: Fri, 09 Jun 2006 17:28:17 +0900

> able to use them effectively.

I am doubtful too. It will be probably impractical to assume that
average email users understand why (or why not) their email addresses 
are ATOMIC.

However, on the other side, it seems more probable that some people 
would not (or could not) accept that they should have alternative 
Roman-based addresses that are just obfuscated to them. In my 
environment (i.e. Korea), young generation will stick to use ASCII 
addresses in most cases, while they use EAI addresses only as a fun or 
for cultural identification. However, older generation will certainly 
prefer to use "only" Korean email addresses. It will be a big burden for 
them to memorize Roman based alternative addresses even though the job 
is too trivial for the rest. For those people, "always use ATOMIC" can 
be a quite reasonable option to email client software vendors.

Regards

---

From: Tony Finch <[email-masked]>
Date: Fri, 9 Jun 2006 16:15:37 +0100

On Fri, 9 Jun 2006, Yangwoo Ko wrote:
>
> However, older generation will certainly prefer to use "only" Korean
> email addresses. It will be a big burden for them to memorize Roman
> based alternative addresses even though the job is too trivial for the
> rest. For those people, "always use ATOMIC" can be a quite reasonable
> option to email client software vendors.

Wouldn't it be better for them to allow downgrading so that it's possible
for them to communicate with the ascii-only world when necessary? They
don't have to worry about the details of their gibberish downgraded
address.

And in any case, isn't the value of the ATOMIC flag a decision for
postmasters, not for end-users?

And don't we want to allow i14ed communication between i14ed islands via
ascii-only relays? e.g. Korean students at my university with i14ed MUAs
communicating with their i14ed parents via my ascii-only MTAs?

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BAILEY FAEROES: SOUTH OR SOUTHEAST 4 OR 5, INCREASING 6 AT TIMES. RAIN OR
SHOWERS. MODERATE OR GOOD WITH FOG PATCHES.

---

From: Yangwoo Ko <[email-masked]>
Date: Sat, 10 Jun 2006 13:15:30 +0900

Tony Finch wrote:
>> However, older generation will ermiecertainly prefer to use "only" Korean

We seem to agree what we want to accomplish with this EAI effort. That
is to allow local part have non ASCII while not breaking down the
existing email world in the perspective of not only postmasters but
also users.

The only (the only one? I hope so.) discrepancy is raised when we
are searching the right trade-off point between smooth integration with
the existing world and ease of user learning.

If we design that non ASCII addresses should be always "safe to
downgrade", then users don't need to care about possible downgrading
along the path.

On the other hand, some of us (including me) believe that the above
restriction (i.e. always donwgradable non ASCII) is harmful in the long
run.

I don't believe that any one of the above two is definitely better than
the other. I hope that the distinction and pros/cons of the two could
be clarified through the WG process and experiments.

Regards

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 10 Jun 2006 10:39:28 +0200

> the existing world and ease of user learning.
I think there are other reasons why downgrading may not always be desirable.
One important issue we have not discussed yet is the "signed mail" 
problem - a digital signature will not verify after a downgrade (the 
workarounds for this are likely impossible in practice).
One way of handling that issue MAY be to find a way in which the sender 
can indicate that if downgrading is required for delivery, he wants the 
message bounced, so that he can generate a (signed) ASCII version 
instead of the UTF8SMTP version.
> be clarified through the WG process and experiments. 
If we give the users control of this, users may show us the way.

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 10 Jun 2006 20:20:27 +0100

> instead of the UTF8SMTP version.

If the sender indicates that his I??n address is Non-Atomic, and declines  
to provide an Alt-Address, then that effect will be achieved.

In any case, even if headers are included within the digital signature  
(and signing just the body is sufficient for many purposes) it should be  
possible to arrange that the To: header is excluded from the Signature -  
the From is the important one to sign, and the sender can arrange for an  
aascii address in there.

---

From: Tony Finch <[email-masked]>
Date: Mon, 12 Jun 2006 20:00:28 +0100

> restriction (i.e. always donwgradable non ASCII) is harmful in the long

I'm worried that the additional complexity is damaging in the long
run, because it affects everything that handles email addresses, including
user interfaces and non-email protocols that incidentally handle email
addresses, because they all have to be extended to deal with the new
metadata. Furthermore, the complexity seems to be designed to support
shoddy implementations of i14ed email that can't even reliably detect a
downgrade error.

The signature problem is not specific to i18n: it already exists for
8BITMIME and BINARYMIME. There are a few answers: the relevant signature
standards could require ascii-armoured messages, but that's undesirable
because we'd like to move towards 8 bit email; or downgradability could be
a per-message attribute rather than a per-address attribute - which makes
sense since many of the downgrading problems only relate to the message
data.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
LUNDY FASTNET IRISH SEA: SOUTH OR SOUTHWEST 4 OR 5, OCCASIONALLY 6 AT FIRST IN
IRISH SEA, VEERING WEST 3 OR 4. SHOWERS AT FIRST. GOOD.