Re: [idn] IDNA interoperability failures, once again

["Eric A. Hall" <ehall@ehsco.com>]

"Adam M. Costello" wrote:

> > Have you documented the use of i18n domain names in URLs somewhere?
> 
> IDNA.  It documents how to use IDNs anywhere you can use regular domain
> names.

With all of the authority and justification afforded to the authors by the
IETF and W3C, no doubt.

> > In conjunction with a SeeAlso header field or a RFC822-style
> > References header field, this would not only mean that I was now
> > generating illegal header fields
> 
> I don't know what a SeeAlso header field is.  A References header field
> contains a list of <word>s and <msg-id>s, which can be distinguished
> syntactically because the <msg-id>s begin and end with angle brackets
> while the <word>s do not.

Ok, let's go there (sticking with 822 for context):

 | msg-id      =  "<" addr-spec ">"
 | addr-spec   =  local-part "@" domain
 | domain      =  sub-domain *("." sub-domain)
 | sub-domain  =  domain-ref / domain-literal
 | domain-ref  =  atom
 | atom        =  1*<any CHAR except specials, SPACE and CTLs>
 | CHAR        =  <any ASCII character>        ; (  0-177,  0.-127.)

As we can see, a Message-ID header field that includes decoded output from
an ACE-encoded IDN is not a valid Message-ID.

Although you may believe that this data-type only has relevant definition
when it is encapsulated within an email message, I can assure you that the
data-type is used in several locations, and that the values will come and
go in and out of messages. Yes, a messaging application should check
before it accepts the value, but it should also check before it
TRANSLITERATES THE ENCODED VALUE. The DEFAULT behavior should be to NEVER
GENERATE THE DECODED OUTPUT.

IDNA provides a encoding of an i18n domain name which is safe for transfer
within the Message-ID header field. That is all. It is not safe for
anything to transliterate the encoded sequence. You must not encourage
such foolishness with a "requirement".

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/