Re: [idn] IDNA interoperability failures, once again

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

"Adam M. Costello" wrote:
> 
> [This message contains responses to D. J. Bernstein and Eric A. Hall
> regarding related issues.]

Please stop doing that, we are on about two totally different things.

> "Eric A. Hall" <ehall@ehsco.com> wrote:
> 
> > As we can see, a Message-ID header field that includes decoded output
> > from an ACE-encoded IDN is not a valid Message-ID.
> 
> Exactly right.  Therefore RFC-822 compliant mail programs will not put
> non-ASCII domain names in a Message-ID field.

You have completely missed the point. Message-ID is unique in that it
provides a serial number for a message. The decoded output for a
Message-ID header field MUST NEVER be presented, since it would be a
functionally different identifier whenever it was used. For example,
searching Google or an IMAP server for all of the messages associated with
the Message-ID of nn@zz--gobbledygook is completely different than
searching for a Message-ID of nn@<IDN>. Shall all such services be
upgraded to suit IDNA, even though many of these operations take place
outside of RFC [2]822 data-space?

The problem of pollution will also happen despite any mandate to the
contrary. This will most noticably occur with email addresses, where an
address is copied from say Pine to Hotmail; note that 2047 pollution also
occurs in this way, but since 2047 doesn't pollute the actual address, it
isn't actually fatal. You can say that applications shouldn't do that and
I'd agree with you. The secondary point is that we shouldn't be knocking
these applications over in the first place.

Regardless, I'm tired of chasing down your escape clauses. The idea that
you can somehow dictate a "requirement" (your word) that applications
SHOULD (your word) rewrite domain names regardless of functionality or
form is absurd. You have only ever had one option here, which is to defer
any and all such processing to those groups which actually define and
control those specifications. As much as you would like to believe
otherwise, you have zero authority to impose such behavior on anybody or
anything. Encouraging it is completely irresponsible. Until you remove
that requirement, this spec is broken. Period.

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