Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01 (and -02)

[Joseph Yee <[e-mail]>]

Shawn,

The discussion on encoding domain part with RFC3490 or RFC5890 is focus on what may/can do immediately with ascii-only@utf8-domain address (following the discussion that narrow down the scenario).  Your concern of too restrictive choices was addressed on section 7.1 in Framework-02 of what MUA and user can do.  The text there mentions wide range of approaches.  

I believed that Section 7.1 (in Framework-02) address your concern in Section 3.2 (UTF8SMTPbis).

Best
Joseph

On 2010-07-12, at 12:57 PM, Shawn Steele wrote:

> Sorry, I cut too much context.  I was replying to Ernie's reply where he said:
> 
> 	3.2. The UTF8SMTPbis Extension
> 	(last paragraph)  
> 
> 	   If a server advertises UTF8SMTP and the client does not recognize the
> 	   extension, the client may send a regular message [RFC2821 <http://tools.ietf.org/html/rfc2821>] and
> 	   [RFC2822 <http://tools.ietf.org/html/rfc2822>].  In this case, the client may continue to use the
> 	   [RFC3490 <http://tools.ietf.org/html/rfc3490>] or [RFC5890 <http://tools.ietf.org/html/rfc5890>] ToAscii() to encode the domain portion of an
> 	   address.
> 
> 	The second sentence is not very clear. Is the following what is meant
> 
> 	>>    In this case, the client will not be able to transmit any
> 	>>    messages which contain non-ASCII characters in the
> 	>>    local-part of any email addresses. If the non-ASCII
> 	>>    characters are confined only to the domain portion of the
> 	>>    address, such a client will be able to transmit messages
> 	>>    if it uses [RFC3490] or [RFC5890] ToAscii() to encode the
> 	>>    domain portions of these addresses.
> 
> So I suggested:
> 
>>   In this case, the client will not be able to transmit any
>> messages    which contain non-ASCII characters in the
>> local-part of any email    addresses. If the client has an
>> ASCII only address available, such    as an alias, or by
>> applying [RFC3490bis] ToAscii to the domain    portion of the
>> address, then it may be able to send the mail in    ASCII as
>> per [RFC2821].
> 
> Where you replied:
> 
> 	That statement would be true, but a lot less helpful than I think you want, if the last part of it read something like "...then it may be able to send a similar, transformed, message in ASCII as..."
> 
> The original idea seems to be that "If UTF8SMTP isn't supported, you might be able to try the old way by doing XXXXX".  Since we expect at least some users to have ASCII addresses, then XXXXX has more options than what Ernie's suggestion allowed.  That's all I was trying to say.  Even using Punycode as in the original idea would be a "transformed" message.
> 
> I'm not sure we need this text, since, of course, if the server doesn't support UTF8SMTP, the existing standards still work :)  It seems like there's no harm in pointing that out, but I don't want to be overly restrictive in our wording.
> 
> Re: transliterations, I think I was confusing.  We're expecting admins/users to create a Unicode address for their mailbox, and, likely, an ASCII address, which, in some cases, is probably a transliteration chosen by the admin or user.  (Eg: Tarek, my manager, instead of however that's spelled in Arabic).
> 
> - Shawn
> 
> -----Original Message-----
> From: John C Klensin [mailto:[e-mail]] 
> Sent: Monday, July 12, 2010 1:39 AM
> To: Shawn Steele; [e-mail]
> Subject: Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01
> 
> Shawn,
> 
> 
> --On Monday, July 12, 2010 06:08 +0000 Shawn Steele <[e-mail]> wrote:
> 
>>> The second sentence is not very clear. Is the following what is 
>>> meant?
>> 
>>>   In this case, the client will not be able to transmit any
>>>   messages which contain non-ASCII characters in the
>>>   local-part of any email addresses. If the non-ASCII
>>>   characters are confined only to the domain portion of the
>>>   address, such a client will be able to transmit messages
>>>   if it uses [RFC3490] or [RFC5890] ToAscii() to encode the
>>>   domain portions of these addresses.
> 
> I can't even find the above text in 4952bis-01.  To what are you referring?
> 
>> They may have ASCII aliases (eg: transliterations) available, so I 
>> think that's a tad too restrictive.
> 
> And I don't understand this comment.  If an ASCII alias is substituted for the non-ASCII local part, then the message proposed to be transmitted no longer contains a non-ASCII local part.  Either the local-part in the _message the client is going to transmit_ is all-ASCII or it isn't.  If it isn't, the above is true.  If it is all-ASCII, the above is irrelevant.  
> 
> If you are suggesting that two messages are somehow the same because one uses ASCII aliases for addresses found in the other, I think that takes us directly into the mess of having to assert an externally-verifiable identity binding between the two addresses.  Only the delivery MTA or the destination user can know that, and they aren't obligated to tell (even on VRFY).
> 
>>   In this case, the client will not be able to transmit any
>> messages    which contain non-ASCII characters in the
>> local-part of any email    addresses. If the client has an
>> ASCII only address available, such    as an alias, or by
>> applying [RFC3490bis] ToAscii to the domain    portion of the
>> address, then it may be able to send the mail in    ASCII as
>> per [RFC2821].
> 
> That statement would be true, but a lot less helpful than I think you want, if the last part of it read something like "...then it may be able to send a similar, transformed, message in ASCII as..."
> 
>   best,
>      john
> 
> 
> _______________________________________________
> IMA mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ima