"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/
