Subject: Re: [EAI] ATOMIC or not

From: "Yao Jiankang" <[email-masked]>
Date: Wed, 12 Jul 2006 02:14:33 +0800

according to my understanding in the meeting, it seems that we have a rough
consensus about removing the "atomic" parameter although some still prefer
atomic. Yes, If someone still prefer atomic and do some algorithmic
transformation from UTF-8 address to ASCII address, in operation guideline
document, we may suggest some  algorithmic transformation method to
transform the UTF-8 address to ASCII address as the alt-address if some one
perfer transformation address as the alt-address instead of another ascii
address.

Yao Jiankang

----- Original Message ----- 
From: "Edmon Chung" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 12, 2006 1:54 AM
Subject: [EAI] ATOMIC or not

>
> During the session today in Montreal, a discussion was raised about the
use of the ATOMIC parameter.  This was brought up during the discussion of
the consolidation of using one instead of 2 parameters in the SMTP
extension, as well as the syntax of whether such a parameter should be
within the regular address angled brackets "<>" or outside.  A suggestion
was made to eliminate the use of the ATOMIC identification completely and a
consensus was sought, which showed support in the room.  However, it
occurred to me that many in the room was a bit confused about what was being
decided.  This is exemplified I think by the continued discussion about
having an ATOMIC "transformed" format of an internationalized email address
in the subsequent draft discussions by the respective authors.
>
> Because almost all of the current drafts include the concept of having an
ATOMIC parameter, I think it is prudent that we have a more indepth
discussion on the subject.
>
> Before jumping to the discussion, it is useful I think to point out that
(at least as far as my understanding goes) the use of ATOMIC presumes that
in conjunction there is a generally known algorithm that can be used to
transform ("downgrade" or "upgrade") an internationalized email address.
Therefore, if an internationalized email address can be such "transformed",
then the ATOMIC bit can be set.  This will allow mail servers to
downgrade/upgrade an address when needed.
>
> From both the Headers document as well as the Downgrade document, it seems
to me that the ATOMIC "flag" may be useful.  The presentation from Nai Wen
(TWNIC), especially his trial/demo discussion, also seem to suggest that
having the ATOMIC (more importantly the algorithm for transforming to a
downgraded format) functionality maybe very useful.
>
> The argument put forth against having ATOMIC was clear: the sender could
always use a particular algorithm to provide an alt-address and therefore,
simply having an option to announce an alt-address is good enough.
>
> The argument for having the ATOMIC was not that clear (perhaps others can
add).  In my mind, I think the usefulness of having the ATOMIC flag is not
only that it allows a more concise way of sending/storing downgrade data, it
is much better for transportability and passing around.  Because mail is
passed around siginificantly, this is an important consideration in my mind.
What had NOT been discussed in the current set of drafts is whether an
"alt-address" can survive more than one series of transport.  I.e., if I
have obtained an alt-address from a particular internationalized email
address before, can I use it again in the future?... With ATOMIC, this can
be safely assumed.  With alt-address, this cannot be assumed.  Without the
ability of using downgrade information, downgrade may in itself become much
less useful, because when downgrade is most needed, often the downgrade
information would not be available.  Even if I have obtained an alt-address
before I cannot assume that I can use it again (or can I?)... but with
ATOMIC, I can assume that the downgrade is applicable in the future.  An MUA
or an MTA could therefore store these information for meaningful reuse.
>
> The problem overall of course is that (if my assumption earlier was
correct), and if we keep ATOMIC, we will need to define a known algorithm
for transforming an address.
>
> Anyway, an important point is, at least for myself, I am not ready to
completely eliminate ATOMIC yet until there is further thought on the issues
at stake.  I suspect there are others that share my concern... and more that
are just generally confused because of the number of inconsistencies between
the current set of drafts... Perhaps if and when the drafts are more
consistent, the usefulness (or uselessness) of the ATOMIC parameter/option
can be better evaluated...
> Edmon

----------------------------------------------------------------------------
----

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

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

---

From: "Shawn Steele" <[email-masked]>
Date: Wed, 12 Jul 2006 12:06:51 -0700

It seems to me that ALT-ADDR is more interesting than ATOMIC, and some
ATOMIC conversion could be done by a server to provide an ALT-ADDR if
necessary.

I could easily see some mail systems aliasing simple ASCII addresses to
an internationalized address (or the other way around) in a fashion that
may not necessarily be algorithmic.  For example, some systems could
provide transliterated ASCII addresses for their native
internationalized address.  Even for Latin, I'd expect that many people
would probably prefer just dropping accents than mangling their name
with some xn-- gobbledygook.  Any mechanism for ALT-ADDR should be
allowed so long as its understood by their mail server.

I'm curious though, if a system doesn't understand an internationalized
address, how is it going to know about an ALT-ADDR (or any other
mechanism?)  The usefulness seems to be that I could try to send to an
internationalized address, and if that fails I could try the ALT-ADDR
(assuming I'm a new mail transport that understands them.)  In that case
an algorithmic mapping like ACE isn't required.

It also seems likely that if ALT-ADDR is required at some stage that the
internationalized address would then either be lost or mangled.

- Shawn

SDE, Windows Globalization
Microsoft

---

From: "Shawn Steele" <[email-masked]>
Date: Thu, 13 Jul 2006 11:41:00 -0700

> Not true.  If an address is designated as ATOMIC, then I would store
that information cause I know
> that it could be used in the future.  If an alt-address is provided,
then I would probably have to
> discard it cause I cannot determine whether I can use that same
alt-addr in the future.

As was mentioned, you can't trust any address anyway

> The "alt-addr" mechanism seems to be becoming more and more an immense
> administrative nightmare!

Perhaps, but I'd like to point out that most mail servers already
support alternate addresses.  For example, I'm
[email-masked] or [email-masked]  Neither is really
very guaranteed, I could change then on a whim.  

What existing protocols don't really give us is a way for me to tell you
that I have multiple addresses.  I could easily see my Chinese coworkers
getting a third alias when IMA becomes common, regardless of the status
of alt-address.  A Chinese address would work well for some people, but
I would still find a latin address to be more usable.  This isn't a
technical limitation, but a human one.  In this case I'd imagine that a
business card would probably have the Chinese and Latin transliterated
addresses.

What doesn't currently exist is a way to exchange backup-addresses,
which is what the draft does with alt-address.  Presumably mail clients
that were IMA aware would capture both addresses to use as appropriate.

- Shawn