Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-10.txt

I agree.  While I am 100% for a downgrade solution I believe it is not part of the core documentation, so long as the core documents do not set prohibitions that would make downgrade by a submission server illegal.

-----Original Message-----
From: ima-bounces@ietf.org [mailto:ima-bounces@ietf.org] On Behalf Of Shawn Steele
Sent: Tuesday, June 07, 2011 11:26 AM
To: Joseph Yee
Cc: ima@ietf.org
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-10.txt

There is no context for IDNA in EAI, certainly not the ASCII form.  We're all about utf-8@utf-8, punycode is all about hacking DNS to make Unicode work in an ASCII environment.  I think it is worth mentioning that U-labels are required in EAI, however once you talk about sending through legacy smtp, you're automatically in "downgrade".  

Even though we don't really have "downgrade" any more, I think that any downgrade-like stuff should be in it's own document, like in the proposed email address selection informational doc.  (Where we recommend people create an ASCII address for accounts that have EAI addresses, for interop.  We can point out that if Unicode is only in the DNS portion, that you could "downgrade" that way)

Additionally, you cannot "just" convert Unicode to Punycode and have everything magically behave.  Encryption certs can get confused if the form in the cert and the form in the mail don't match.

So:  I think it is extremely valuable to be able to convert an EAI address that only has Unicode in the domain part to punycode.  However I don't think this is the right place to discuss it, it leads to all sorts of other questions that could make it harder to close this doc.  I'd rather have it live in it's own self-contained place so that it didn't interfere with publishing the core RFCs.

-Shawn

-----Original Message-----
From: Joseph Yee [mailto:jyee@afilias.info] 
Sent: Tuesday, June 07, 2011 9:50 AM
To: Shawn Steele
Cc: Jiankang YAO; ima@ietf.org
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-10.txt

Shawn and all,

From your original comment that I believed that you are not against the conversion. IDN RFCs say that U-labels are preferred IDNA aware application and no prohibition on using A-labels. As you say IDN RFCs cover {U,A}-label usage, this paragraph is to reinforce it in EAI context. This conversion is quiet specific and worth to document here, to maximize deliverability (my personal opinion). I would suggest to reword it rather than remove it.  And IIRC, we discussed to have this paragraph as bulletin 4 in the same section in the past, may worth to think about it again.

Original:
   An EAI-aware MUA/MSA sending to a legacy SMTP server [RFC5321] and
   [RFC5322] MAY convert an ASCII@U-label [RFC5890] address into the
   format of ASCII@A-label [RFC5890] if the email address is in the
   format of ASCII@U-label.

Suggestion (may move it as point 4):
    EAI-aware MUA/MSA SHOULD use U-label [RFC5980] where possible, but if the address is in the format of ASCII@U-label, the EAI-aware MUA/MSA MAY convert the address to ASCII@A-label [RFC5980] format to try delivering the mail thru legacy SMTP server [RFC5321] [RFC5322]. 

Thoughts everyone?

Best,
Joseph

On 2011-06-07, at 11:03 AM, Shawn Steele wrote:

> I don't object ;-)
> 
> -Shawn
> 
>  
> http://blogs.msdn.com/shawnste
> 
> 
> ________________________________________
> From: Jiankang YAO [yaojk@cnnic.cn]
> Sent: Tuesday, June 07, 2011 12:54 AM
> To: Shawn Steele; ima@ietf.org
> Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-10.txt
> 
> ----- Original Message -----
> From: "Shawn Steele" <Shawn.Steele@microsoft.com>
> To: <ima@ietf.org>
> Sent: Saturday, June 04, 2011 5:06 AM
> Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-10.txt
> 
> 
>>> An EAI-aware MUA/MSA sending to a legacy SMTP server  and may 
>>> convert an ASCII@U-label  address into the format of ASCII@A-label 
>>> if the email address is in the format of ASCII@U-label.
>> 
>> I think this is extraneous and not necessary.
>> 
>> I think we mentioned before that when EAI-aware servers are communicating with legacy SMTP servers, then the EAI standards no longer apply.  Then the legacy SMTP RFCs apply.  The IDN RFCs are already clear about that happens to U-Labels in an ASCII environment, so this isn't necessary.
>> 
>> 
> 
> If no one objects it, I will remove  the parapraph above in the new version.
> 
> Jiankang Yao
> 
>> Also, with a "strict" interpretation of the legacy SMTP behavior, the EAI RFCs wouldn't apply, which would include this RFC and any of this language within it.
>> 
>> Eg: Legacy SMTP + IDN "works fine" regardless of these RFCs.  Nothing 
>> we add here will help or hinder that.  *IF* we want to address this 
>> type of thing, then it should go into a separate document about 
>> mitigating the legacy compatibility issues.  (Eg: alternate routes, 
>> try different addresses, etc.)
>> 
>> -=Shawn
>> _______________________________________________
>> IMA mailing list
>> IMA@ietf.org
>> https://www.ietf.org/mailman/listinfo/ima
> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www.ietf.org/mailman/listinfo/ima

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www.ietf.org/mailman/listinfo/ima