"Eric A. Hall" wrote:
> > I think the intended title of this document is "Stringprep Profile > > for Internationalized Domain Names". > > Based on a cursory analysis, this document is suitable as a standalone > description of i18n domain names Looking at this in more detail, I take that back. The i18n "domain name" specification needs to allow any valid UCS character code, and must not be restricted to hostname characters. As has been discussed multiple times, there are some domain names which are not hostnames, and this model will likely be valid in the future as well. The obvious example of this is mailbox names. Some future version of an email specification may allow (for example) the use of non-combining characters in mailbox names. However, mailbox names are often stored in DNS labels, and under the current arrangement, those mailbox names would be normalized and lowercased as part of this process. In essence, the rules which are currently provided impose restrictions on any future mailbox name designs which the representative working group may come up with in the future. That is the obvious example. There are less-obvious examples of the same concern. However, in general, there should be a different stringprep profile for i18n "domain names" than for "host names", and IDNA (among other encoding or tagging sequences) must allow for all of these variations, rather than imposing artificial restrictions in this area. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
