"D. J. Bernstein" <[EMAIL PROTECTED]> wrote: > > 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.
I was speaking about protocol requirements themselves, not meta-requirements imposed on protocol specifications. The RFC-2277 requirement that new protocols support UTF-8 for text is a meta-requirement. It doesn't say exactly how each protocol will satisfy that meta-requirement. The IDN working group could perhaps issue a similar meta-requirement saying that protocols that use domain names must be upgraded to support UTF-8, but people would still need to decide exactly what changes to make to each protocol to bring it into compliance with the meta-requirement, and that work would be done in other working groups, because it's out of scope of this one. [For the record, even if such a meta-requirement would be in-scope, I wouldn't recommend it. For some protocols it might not be worth the trouble to upgrade.] > (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. That's certainly one technique that almost any protocol *could* use to add support for UTF-8. But some protocols might prefer a more graceful transition than simply sending 8-bit data to old implementations that expect 7-bit data and letting them choke on it. For example, people have discussed negotiation and new header fields. There should be an opportunity for each protocol to use an upgrade path best suited to its needs. [And I think not upgrading should also be an option, since IDNA can still be used on top of protocols that don't upgrade.] AMC
