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

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

Harald Tveit Alvestrand wrote:
> Ernie Dainow skrev:
>>
>> 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.
> Into the "from" or the "to" fields?
> My opinion is slightly different for the two cases....
This particular case was copied into the To field.
More completely, the two failure cases are
      UTF8SMTP                   "IDNA" Server
1)   From: ascii at ascii.         To: ascii at non-ascii  
2)   From: ascii at non-ascii   To: ascii at ascii         
No Alternate Addresses for any.
Note that if the user replaces the non-ascii domain with its punycode 
translation, the email is sent.

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