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

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 7 Jun 2011 15:54:32 +0800

----- Original Message ----- 
From: "Shawn Steele" <[email-masked]>
To: <[email-masked]>
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: Shawn Steele <[email-masked]>
Date: Tue, 7 Jun 2011 15:03:11 +0000

I don't object ;-)

-Shawn

 
http://blogs.msdn.com/shawnste

________________________________________
From: Jiankang YAO [[email-masked]]
Sent: Tuesday, June 07, 2011 12:54 AM
To: Shawn Steele; [email-masked]
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-10.txt

----- Original Message -----
From: "Shawn Steele" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, June 04, 2011 5:06 AM
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-10.txt

Jiankang Yao

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 07 Jun 2011 09:46:09 -0700

> I don't object ;-)

+1

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Joseph Yee <[email-masked]>
Date: Tue, 7 Jun 2011 12:50:24 -0400

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

---

From: Shawn Steele <[email-masked]>
Date: Tue, 7 Jun 2011 18:25:42 +0000

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:[email-masked]] 
Sent: Tuesday, June 07, 2011 9:50 AM
To: Shawn Steele
Cc: Jiankang YAO; [email-masked]
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-10.txt

Shawn and all,

Original:

Thoughts everyone?

Best,
Joseph

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

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

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 07 Jun 2011 11:26:28 -0700

On 6/7/2011 9:50 AM, Joseph Yee wrote:
> 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?

1. What is the reason for making any normative statement here?  What improvement 
is made in system behavior?  What bad things happen if systems do not follow the 
normative statements?

2. The "permission" contained in the second normative statement ("MAY") is 
redundant.  Systems can choose to do this or not do this, independent of this 
normative statement.  Hence, this has no effect on interoperability or other 
functionality.

d/

-- 

   Dave Crocker

---

From: Jason Nelson <[email-masked]>
Date: Wed, 8 Jun 2011 21:49:22 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Shawn Steele
Sent: Tuesday, June 07, 2011 11:26 AM
To: Joseph Yee
Cc: [email-masked]
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-10.txt

-Shawn

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

Shawn and all,

Original:

Thoughts everyone?

Best,
Joseph

---

From: "John Levine" <[email-masked]>
Date: 8 Jun 2011 22:45:18 -0000

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

I think bullet #2 in the middle of 3.2 makes it clear that submission
servers can do whatever it takes, so on further consideration I agree,
take out the last sentence in 3.2 and ship it.

R's,
John

---

From: Joseph Yee <[email-masked]>
Date: Mon, 13 Jun 2011 16:53:55 -0400

It covers MSA only, but more people considered the last sentence not part of scope for this draft and I agreed.  So the next revision should take out the last sentence in section 3.2.

Joseph