Re: [EAI] Add requirement for punycode conversions in downgrade

[Ernie Dainow <edainow at ca.afilias.info>]

John C Klensin wrote:
> --On Tuesday, 18 March, 2008 22:23 +0100 Harald Tveit Alvestrand
> <harald at alvestrand.no> wrote:
>
>   
>> Ernie Dainow skrev:
>>     
>>> If Downgrade fails when sending to a recipient of the form 
>>> ascii at non-ascii , what is the recourse for the user? A very
>>> few IDNA  literate users might figure out how to do a
>>> punycode conversion and  use it as an Alternate Address. Most
>>> users would have to revert to  using a traditional email
>>> client. 
>>>       
>> Well, there are some possibilities for why we get that
>> situation:
>>
>> - User (or admin) has forgotten to set the Alternate Address
>> (misconfiguration). Is it better for a mid-net relay to pass
>> the message or to report to the sender that there's a
>> misconfiguratoin?
>>
>> - User (or admin) has decided that he doesn't care whether or
>> not messages get to non-UTF8SMTP users. Is it better for a
>> mid-net relay to pass the message or to report to the sender
>> that his wishes have been "honored"?
>>
>> - User (or admin) expected this message to go to only UTF8SMTP
>> users. Is it better for a mid-net relay to pass the message or
>> to report to the sender that his expectation was unrealistic?
>>
>> Note: I don't know whether the answers are one or the other.
>> But I can see arguments on both sides of the issue - "pass the
>> message" is not necessarily always the right choice.
>>     
>
> I think we are on the same page.  I don't know what the right
> answer is (either), but "convert and pass" is not as obvious to
> me as it apparently is to Ernie.
>   
Yes these are all possible scenarios, but whether the receiver is 
UTF8SMTP compliant or not is of interest to a relatively few number of 
technically knowledgeable email users compared to the millions of 
average email users who basically just want to see their email get 
delivered. After all, wasn't Downgrade included in the specification for 
exactly this reason -- to keep email flowing during an interim period 
when there is a mix of traditional and UTF8SMTP email systems?

The failure situation here is a lack of inter-operability between EAI 
and "IDNA" email. By IDNA email I mean a traditional email system in 
which the email client has been modified in accordance with RFC3490, so 
that users are able to enter email addresses with UTF8 domains (but the 
local part is restricted to all ASCII). The email client does punycode 
conversions on the domain part so that the messages sent are traditional 
email. I know there is one implementation that does this; I don't know 
how much it is used at this point. As the time stretches out to 2009 to 
get a standards track EAI completed, these "IDNA" email systems might be 
more widely used. So we have a situation where EAI supports traditional 
email via Downgrade but possibly not "IDNA" email.

As a concrete example of this, ICANN has an email test page for testing 
International top level domains at http://idn.icann.org/E-mail_test. 
Their second test is to copy an email address of the form 
ascii at non-ascii into an email client. Our current EAI implementation 
fails this test, following a strict adherence to the current EAI specs. 
I don't see any reason an implementation can't decide it will do the 
punycode conversion in Downgrade. It is supported by section 2.2 in 
draft-ietf-eai-smtpext: "An SMTP Client . . . MAY transmit the domain 
parts of mailbox names within SMTP commands or the message header in 
either the form of ACE labels as specified in IDNA [RFC3490] or as UTF-8 
strings." If we leave this decision up to the implementation, then we 
have a situation where EAI may or may not inter-operate with IDNA email. 
I think it would be better to have a clear statement on this, either EAI 
supports inter-operability with IDNA email or it does not.

Ernie
 




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