on 7/3/2002 3:28 AM Erik Nordmark wrote: >> | 2. Perform the steps specified in [NAMEPREP] and fail if there is >> | an error. The AllowUnassigned flag is used in [NAMEPREP]. >> >> "allowunassigned" does not appear in draft-ietf-idn-nameprep-11.txt
> What is the problem? Anal types like me see StudlyCapped functions and flags and expect to find them documented. Other than that, none I suppose. >> Collectively this means that nameprep is still the gatekeeper, and >> that profiles other than nameprep cannot be encoded with IDNA. > > When there are additional profiles for domain names, [...] There are already profiles described for iSCSI names and Kerberos realms. > it might makes > sense to have a standards track RFC that either updates the IDNA RFC to > say when the new profile can be used, or (depending on how different > things would be for the new usage) it might make sense to have a > standards track RFC which uses "newprep" plus punycode. Requiring new codecs for new profiles is all cost and zero benefit. What possible value is there in forcing applications to define new codecs with different outputs for their alternative names? > But such a > future doesn't mean that IDNA can bypass the requirement that nameprep > applies today - removing that requirement might lead folks to believe > they can do non-standard prep and still be compliant with IDNA. Being "compliant" with IDNA is a matter of surviving a trip through ToASCII and back. As far as I can tell, any standards-track stringprep profile which uses label sequences can meet this requirement. > That would lead to non-interoperability as far as I can tell. If an organization starts using kerberos-prep for zone delegation or addressing purposes then yes, there would be interoperability problems with the applications that decode the sequences. In fact there would be so many problems that one is left to wonder how anybody would willfully do something that stupid. On the other hand, requiring new profiles to develop new codecs imposes its own interoperability problems. EG, all forms of network data are guaranteed to be opaque to everybody until all of the codecs have been installed on every machine on the planet. You can't encode/decode Kerberos names into a local text file until you've got the codec... This would be a significant negative development towards the notion of transparency. One codec for all domain name-like profiles of stringprep should be enough. I thought we had settled this argument a couple of weeks ago. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
