Re: [EAI] ATOMIC or not

[Edmon Chung <[e-mail]>]

My main points are I think:

1. if we want to have a standard ACE transformation for local part, then we should keep the ATOMIC parameter (or some whay to convey that message) so that we can actually make use of the standard algorithm to assist in transport to ASCII only users.

2. if we decide not to transport the ATOMIC parameter some way (including specifying it as default), then there is no point having a standard ACE transformation, because everyone can have their own mechanism and it would work the same.

3. I believe there may be some benefit to have a standard ACE transformation, but am not sure.  I think we need further exploration, a couple of people have already suggested that there may be possibility to design a standard two-way convertible ACE for local part... so perhaps if we hear more there...

4. Therefore I think it may be premature to write off the atomic parameter.

Edmon




----- Original Message ----- 
From: "Yangwoo Ko" <[e-mail]>
To: "Edmon Chung" <[e-mail]>
Cc: <[e-mail]>
Sent: Saturday, July 15, 2006 11:04 PM
Subject: Re: [EAI] ATOMIC or not


> 
> Dear Edmon,
> 
> I agree with you that having ATOMIC as a flag is not
> equivalent to transporting algorithmically encoded
> all-ASCII address in an ALT-ADDR slot if;
> 
> * we fail to find almost-perfect "in-band" signaling
> for EAI suchas "xn--" in IDNA
> 
> * and hence it is not safe-to-upgrade
> 
> Is this your point?
> 
> Regards
> 
> Edmon Chung wrote:
>> I understand your analysis and the approach suggested.  Not saying it does not work...
>> 
>> However, my point is if "ATOMIC" as a parameter is never transported, then there is no need for a standardized way to create an ACE representation of a UT8 address.  Because each MUA can use any method of transformation to an alt-address they want and the protocol would still function without any problem.  Because in no place would the infrastructure attempt to up/down-convert the address.
>> 
>> Also, it will mean that there is no way i can obtain a relatively stable ASCII-representation/equivalent of an address.  In that case, when I re-initiate an email to a UTF8 address I would only be able to use the UTF8 address and cannot assume that the alt-address is still valid (unless we specify that in the standards).  This creates additional issue for situations of 3-party communications (scenario 2.5 in scenarios doc: http://www.ietf.org/internet-drafts/draft-ietf-eai-scenarios-01.txt).
>> 
>> To illustrate my point:
>> 
>> Lets say there are 3 parties: EAIuser1, EAIuser2 and ASCIIuserA
>> 
>> IF an ATOMIC parameter can be passed allong:
>> 
>> Lets say EAIuser1 sends to EAIuser2 and the path is fully EAI-aware, and that the ATOMIC parameter is passed along.  EAIuser2 can now store the information
>> 
>> THEN, EAIuser2 after a few weeks is interested to send email to EAIuser1 and ASCIIuserA together.  The transport EAIuser2->EAIuser1 can continue to use UTF8SMTP, and for EAIuser2->ASCIIuserA, a downgrade can happen by converting to ACE address based on the ATOMIC information.  Mail can be sent successfully.
>> 
>> IF however ATOMIC parameter cannot be passed along:
>> 
>> When EAIuser1 sends to EAIuser2, even if it provided the ALT-ADDRESS (no matter whether it was converted using an algorithm, because without the ATOMIC information we cannot assume it is)
>> 
>> WHEN EAIuser after a few weeks tries to initiate an email to EAIuser1 and ASCIIuserA together, it will not be able to successfully send to ASCIIuserA because the header downgrade could not happen for the field containing EAIuser1's address.
>> 
>> Edmon
>> 
>> 
>> 
>> 
>> ----- Original Message ----- 
>> From: "Tony Hansen" <[e-mail]>
>> To: "Edmon Chung" <[e-mail]>
>> Cc: <[e-mail]>
>> Sent: Thursday, July 13, 2006 4:18 PM
>> Subject: Re: [EAI] ATOMIC or not
>> 
>> 
>>> Let's separate out the current ATOMIC implementation and the ATOMIC
>>> concept. The ATOMIC concept says that the i18n localpart can be safely
>>> downgraded to the downgradable ACE form. That's it.
>>>
>>> During the EAI meeting, when people said to get rid of ATOMIC in SMTP,
>>> my understanding is that they were saying to get rid of the SMTP ATOMIC
>>> parameter. They were *not* saying anything about getting rid of the
>>> ATOMIC concept.
>>>
>>> If we want to support the ATOMIC concept, no matter how we do it, the
>>> sender needs to know if any given i18n localpart is ATOMIC. This doesn't
>>> necessarily mean that all intermediate hops in message transmission also
>>> needs to know it.
>>>
>>> Orthogonal to this concept is that of an alternate ascii-compatible
>>> address that would be used if the i18n localpart cannot be used.
>>>
>>> The ATOMIC information provides a way to indicate that the downgradable
>>> ACE form of the i18n address can be used as the alternate address.
>>>
>>> The single bit of knowledge about whether an i18n localpart is ATOMIC
>>> can be used and passed in several ways. The current specs call for the
>>> MUA to do the following processing:
>>>
>>> mua: if i18n address is ATOMIC
>>> mua: pass i18n address and info saying address is ATOMIC
>>> mua: else if there is an alternate ACE address
>>> mua: pass i18n address and alternate ACE address
>>> mua: else
>>> mua: pass i18n address
>>>
>>> When an MTA hits another MTA that is not i18n compatible, it must do the
>>> following processing:
>>>
>>> mta: if address is ATOMIC
>>> mta: downgrade message headers and body
>>> mta: convert i18n address to ACE
>>> mta: use converted address
>>> mta: else if there is an alternate ACE address
>>> mta: downgrade message headers and body
>>> mta: use alternate address
>>> mta: else
>>> mta: bounce the message
>>>
>>> Consider the following alternative where the MUA uses the knowledge that
>>> the i18n address is ATOMIC and uses that knowledge up front to set the
>>> alternate address.
>>>
>>> mua: if i18n address is ATOMIC
>>> mua: pass i18n address and generated ACE address as alternate
>>> mua: else if there is an alternate ACE address
>>> mua: pass i18n address and alternate ACE address
>>> mua: else
>>> mua: pass i18n address
>>>
>>> Now look at how much simpler the MTA becomes:
>>>
>>> mta: if there is an alternate ACE address
>>> mta: downgrade message headers and body
>>> mta: use alternate address
>>> mta: else
>>> mta: bounce the message 
>>>
>>> During the EAI meeting, when people said to get rid of ATOMIC in SMTP,
>>> my understanding is that they were saying to get rid of the SMTP ATOMIC
>>> parameter, but not the ATOMIC concept.
>>>
>>> Tony Hansen
>>> [e-mail]
>>>
>>> Edmon Chung wrote:
>>>> ----- Original Message ----- 
>>>> From: "Tony Finch" <[e-mail]>
>>>>>> 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.
>>>>> If you can't trust the alt-address then surely you can't trust the utf8
>>>>> address either. Or in other words, I don't think this kind of operational
>>>>> stability issue is relevant. You can always verify that the alt-address is
>>>>> the algorithmically-downgraded form of the utf8 address by doing the
>>>>> downgrade and comparing.
>>>> ALT-ADDRESS is not the same as ATOMIC.  ALT-ADDRESS can be any ASCII address.  E.g. "<chineseName>@domain.tld" can have an ALT-ADDR="[e-mail]" (note not even the domain needs to match).  That is why the alt-address cannot be a "stable" glue to the UTF8 address.  The UTF8 address can be fully trusted so can an ATOMIC address (well unless the standard transformation algorithm is changed... but that would be a different issue... more on versioning).
>>>>
>>>>> I'm seriously worried about the user-interface implications of non-atomic
>>>>> addresses.
>>>> Well without the ATOMIC parameter at all there is no way to say that an address is atomic... and based on the current set of specifications, Non-atomic is the default.
>>>>
>>>> Edmon
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> IMA mailing list
>>>> [e-mail]
>>>> https://www1.ietf.org/mailman/listinfo/ima
>>>
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> _______________________________________________
>> IMA mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/ima
> 
>

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