Re: [idn] IDNA interoperability failures, once again

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

"Adam M. Costello" wrote:

> "Eric A. Hall" <ehall@ehsco.com> wrote:

> > Are you SURE you want to do this with Received?
> 
> Yes.

> Novice users never even see Received headers.  Users who know enough to
> request to see Received headers will also know enough to request ASCII
> if they need it.

Spam complaints are the common example of normal users seeing received
header fields, when they are copied and pasted into complaint messages,
the encoded representation (your default) will be what's sent.
Administrators blocking sender domains are the common example of advanced
users seeing domains. In many cases (such as ISP mail systems) the only
view to this information will be through a web UI.

Nowhere in your specification does it state that encoded and non-encoded
views of a domain name should be provided. Do you plan on adding this,
since you won't back away from the claim that it is safe to mandate the
automatic transliteration of ACE sequences?

> > Are you SURE you want to do this with List-* and Content-Location
> > header fields?
> 
> Content-Location is an HTTP header field, and HTTP responses are not
> normally displayed, but if an application wanted to display an HTTP
> response, then it should display the non-ASCII form of the domain name
> if it can (unless the user requests otherwise or special circumstances
> make this problematic).

> I don't know what List-* fields are, but if they are defined to contain
> domain names, then it's the same story as Content-Location.

Content-Location is a MIME header field (see RFC 2557). The List-* header
fields defined in RFC 2369 provide URLs for common list-management
functions. The point of this question is to see if you would dive in and
embrace transliteration of URLs as well, which you seem to think is also a
good idea. Have you documented the use of i18n domain names in URLs
somewhere? I mean, as hard as some of your peers argued against this very
issue, I'm surprised that you're inviting it without any sort of
documentation for review.

> > Are message identifiers also candidates, since they are structured
> > the same as email addresses?  Are you SURE you want to do this with
> > Message-ID?
> 
> Same story as Received.

Message-ID values are frequently referenced in multiple locations, not all
of which are in structured fields. By allowing them to be transliterated
for display, you are inviting them to be converted. This is, in turn,
implicitly expanding the structured header fields that will allow them.

For example, I have cited previous messages by Message-ID throughout this
very thread, and your default interpretation would have made it so that
those values were only seen (and therefore copied and pasted) in their
encoded form. 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 but that I was poisoning the entire
thread and every copy of those messages (including archives), AND THIS
WOULD BE ENTIRELY DUE TO YOUR DEFAULT MANDATE.

In short, mandates such as this one encourage bleed-over inside of
structured data-formats, ACCELERATE ENTROPY ON THE INTERNET. That this is
all being done without any documentation on the affected elements, without
any viable justification whatsoever (supporting the promise of your
religious text is not viable justification), and without any authority
over the affected network services is the very paragon of opinioneering
and absurdity.

> As for "mandate", keep in mind this sentence from the IDNA
> introduction:
> 
>   This document does not require any applications to conform to IDNA,
>   but applications can elect to use IDNA in order to support IDN while
>   maintaining interoperability with existing infrastructure.
> 
> If IDNA is more trouble than it's worth for particular applications,
> those applications can just ignore it.

Then why are you defending it? Declare IDNA as a method for encoding i18n
domain names into an ASCII-compatible encoding, step away from the foolery
of mandating its use with everything that looks like a domain name, and
leave the integration work to the governing bodies that actually have the
authority, expertise and bandwidth to deal with the associated issues.

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