Adam M. Costello writes: > IDNA can't set requirements for all these protocols, because it's way > outside the scope and expertise if this working group.
Next I suppose you'll claim that RFC 2277, which requires UTF-8 support for text in all protocols, can't possibly exist. It is clearly within the scope of IDN to do the same for domain names. Doing the same for mailbox names is arguably also within the scope of IDN, since domain names are copied to mailbox names in many cases. More importantly, to the extent that shortsighted WG limitations screw up the engineering, those limitations obviously have to be removed. Furthermore, IDN _does_ have the expertise to fix SMTP, HTTP, etc. The fixes are so easy that I bet even you can understand them. See, these protocols work with 8-bit bytes. (The Internet, in case you haven't noticed, transmits 8-bit bytes.) But sometimes the protocols specifically prohibit bytes 128-255. We simply eliminate those prohibitions. Implementations are required to treat bytes 128-255 in domain names, mailbox names, etc. as nicely as ASCII letters; the default character set is simply declared to be UTF-8. Failure to support UTF-8 is considered a software bug. Data creators are cautioned against venturing outside ASCII before the bugs are fixed. Can you find even a single standard Internet protocol with domain names that aren't covered by this rule? Can you show us even a single piece of networking code for which you can't figure out how to follow this rule? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago
