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

[Harald Tveit Alvestrand <harald at alvestrand.no>]

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