Re: [idn] WG last call summary

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

"Adam M. Costello" wrote:

> When a mail program displays a message header, it's not necessarily a
> real RFC 822 message header on the screen.  The mail program doesn't
> promise to speak RFC 822 to the human user.

822 defines data-types which are used by multiple protocols. Nothing
"speaks" 822. Rather, several distributed functions exchange data which
has been formatted according to the rules specified in 822. In many
places, the data can leave the messaging network entirely and then be
freely reinserted. It is at this juncture that the mandatory conversion
causes the breakage to occur.

When you give somebody your email address, do you give them the
human-friendly rendering of "Adam Costello" or do you give them the 822
email address? Will this change with IDNA? Wouldn't you stick with the
822-compliant form, knowing that the sacrosanct 822 encoding is going to
work? It will only take a couple of retransmissions before you figure out
that the personal-address-exchange protocol only functions with the 822
form. We know that this will happen, experience and evidence tells us so,
why not skip it altogether?

> The program might omit certain fields that are required, and
> might include non-ASCII characters (converted from RFC 2047 encoding).
> It might let me type non-ASCII characters into the Subject line of an
> outgoing message.  When I instruct the program to send a message, the
> program will take care to send an actual RFC 822 message, doing whatever
> encoding is necessary.

2047 avoids structured data-types specifically for the reasons I mention.
When 2047 breaks, delivery still occurs. And when it does break, it is
somewhat noticable.

> We have found the crux of our disagreement.  I maintain that IDNA does
> *not* extend or alter any data types.

Call it "replaces" if you wish, it is the same effect. The data being
presented to the user is not the Message-ID that has always been presented
in the same manner, those things which look URLs aren't actually URLs
anymore, and so forth. Yep, that is exactly the problem.


It should be pointed out here that removing the mandatory transliteration
gives the collective Internet more options, not fewer options. Removing it
means that those data-types which should be extended (probably email
addresses) will be extended by the authoritative source if they can be
fixed at all, thereby improving all of the uses for that data-type, and
forcing the agents that use those data-types to think about the
ramifications of those changes, and how they can provide the necessary
support (SMTP, IMAP, News, and the associated messaging system parts). I
mean, which would you rather have, vendors doing it different ways because
there is no guidance, or having the vendors get together to decide on a
common way because the standard is being changed?

Conversely, if a data-type cannot be changed, well, thank goodness that
this WG didn't break anything that depends on it. :/

Meanwhile, those data-types which *should not* be extended (such as
Message-ID, among others) will not be extended by either us or the
controlling body, meaning that no unnecessary breakage will ever occur
with those data-types. Cumulatively, this flexibility equates to smoother
deployment in the short run and deeper benefits in the long run. This
should not be considered a set-back.

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