Re: [EAI] Comments on draft-ietf-eai-rfc5336bis-00 (not frmwrk-4952bis-01)

[Joseph Yee <[e-mail]>]

The follow text is what Ernie suggested for 5336bis

> 	>>    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.

Which Shawn expressed concern, and I believed (and Shawn agreed) that text in Section 7.1 in Framework-02 addressed Shawn's concern.  So the text above is good (from consensus) for SMTPbis section 3.2 last paragraph.

Hope this is clear, because it involves two docs to discuss two "inter-related" issues at the same time.

Joseph

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

> The whole part is different (or I missed it) in the new 02 draft, so I think it's fine now.
> 
> Sorry, I'm getting "digests", so I have to cut & paste the subject, and obviously didn't get it right :)
> 
> -Shawn
> 
> -----Original Message-----
> From: Ernie Dainow [mailto:[e-mail]] 
> Sent: Monday, July 12, 2010 8:04 AM
> To: Shawn Steele
> Cc: John C Klensin; [e-mail]
> Subject: Re: [EAI] Comments on draft-ietf-eai-rfc5336bis-00 (not frmwrk-4952bis-01)
> 
> The confusion here is that it actually applies to a different thread. 
> The wording I suggested and is being amended by Shawn (with which I
> agree) is from the thread
> 
> More comments on draft-ietf-eai-rfc5336bis-00
> 
> not from Re: [EAI] Comments on draft-ietf-eai-frmwrk-4952bis-01
> 
>    -Ernie
> 
> 
> 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
>> 
> 
> _______________________________________________
> IMA mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ima