Subject: [EAI] UTF8 MUST NOT transmit...

From: Shawn Steele <[email-masked]>
Date: Fri, 18 Jan 2008 09:04:44 -0800

>    If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP
>    client MUST NOT transmit an internationalized address...

So I assume a Punycode encoded domain name isn't considered "internationalized" for this context?

I'm concerned a tiny bit about "MUST NOT".  Although its not reliable, it seems to me that some mail systems permit non-ASCII labels and are successful, at least within their domain, and often in a broader context.

- shawn

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Jan 2008 13:36:54 -0500

--On Friday, 18 January, 2008 09:04 -0800 Shawn Steele
<[email-masked]> wrote:

>>    If the UTF8SMTP SMTP extension is not offered by the
>>    Server, the SMTP client MUST NOT transmit an
>>    internationalized address...
> 

That is correct.   A punycoded domain name is an ASCII LDH name
except to systems that specifically recognize IDNA.

> I'm concerned a tiny bit about "MUST NOT".  Although its not
> reliable, it seems to me that some mail systems permit
> non-ASCII labels and are successful, at least within their
> domain, and often in a broader context.

This turns out to be the old "just send 8" debate in another
form.  MUST NOT is appropriate because, if such addresses are
used without the extension, interoperability cannot be
guaranteed or even predicted.  Some systems will reject the
addresses, others will trash them (e.g., by dropping the
high-order bits), others may do other things, including having
them work.  But note that, if the addresses are transmitted
without the extension, a whole series of things need to happen
in a consistent way to avoid breaking things downstream.  

Just for example, one needs Return-path to be mapped correctly
into the headers, and then to be interpreted correctly, to
prevent bad things from happening down the line.   That is true
even if the only non-ASCII component of the address is the
domain name. Few of the systems that simply transmit and accept
non-ASCII addresses have thought through and worked out all of
those details in a comprehensive way.  If it were completely
obvious, the details associated with this extension would
probably be unnecessary and a "SHOULD" might be in order.

Of course, almost anything can be done by private, out of band,
agreements, but such activities lie outside the standard.

    john

---

From: Shawn Steele <[email-masked]>
Date: Fri, 18 Jan 2008 10:41:00 -0800

> except to systems that specifically recognize IDNA.

Its probably worth pointing out that punycode names are permitted.  I realize that punycode names are technically ASCII, however IDN aware readers may equate them with "internationalized", so it'd be good to clarify this point.

> I'm concerned a tiny bit about "MUST NOT"

Thanks for the clarification :)

- Shawn

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Jan 2008 14:09:03 -0500

--On Friday, 18 January, 2008 10:41 -0800 Shawn Steele
<[email-masked]> wrote:

>> That is correct.   A punycoded domain name is an ASCII LDH
>> name except to systems that specifically recognize IDNA.
> 
> Its probably worth pointing out that punycode names are
> permitted.  I realize that punycode names are technically
> ASCII, however IDN aware readers may equate them with
> "internationalized", so it'd be good to clarify this point.

yes, you are probably correct.  I can easily fix that in
"framework", but the WG is still undecided whether to try to
reissue "framework" (i.e., update RFC4952) in this round or to
hold it for a standards-track round of processing.  Perhaps a
simple note could be added to the statement in "smtpext".

> Thanks for the clarification :)

:-)

     john

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 21 Jan 2008 10:57:52 -0500

On Fri, Jan 18, 2008 at 10:41:00AM -0800, Shawn Steele wrote:
> 
> Its probably worth pointing out that punycode names are permitted.  I
> realize that punycode names are technically ASCII, however IDN aware
> readers may equate them with "internationalized", so it'd be good to
> clarify this point.

I think this is a good idea.

A
--
Andrew Sullivan  | [email-masked]
The plural of anecdote is not data.
		--Roger Brinner