on 6/13/2002 12:49 AM Adam M. Costello wrote:
> Suppose the IETF were to issue a clarification of the DNS spec stating > in no uncertain terms that bytes 80..FF in domain names must match > exactly, and that there is no standard interpretation of those bytes as > characters (not for any existing DNS services anyway). Then I wouldn't > object if applications that don't like Nameprep were encouraged to use > 8-bit names in DNS for non-human-oriented purposes. > Eric, would you be satisfied with that? What do other people think of > that idea? I've given this some thought, and I think it's a creative approach. But I don't think it's the right approach, since it only ingrains some of the problems. I know you don't want to hear this but it would actually make much more sense to do the exact opposite, which is to prohibit eight-bit for the standard RRs (which is also what John was saying I think) and to embrace and encourage the use of multiple profiles in the i18n namespace. Profiles present a great opportunity to enforce strong and consistent data-typing with the different domain names. Part of the problem with the legacy domain names is that they are so malleable with different interpretations depending on the spec you read. Look at STD19, which was written to provide an encoding for NetBIOS names, but which MS no longer uses due (partly) to i18n issues. Meanwhile, they use RFC 2181 as justification for storing UTF-8 characters in A RRs. I'd much rather see DNSEXT prohibit eight-bit codes in A RRs and encourage MS to use the same A RRs as everybody else so that subsequent future uses of A RRs were consistent. But I'd ALSO encourage them to define a structured syntax for i18n NetBIOS names as well. Leaving the eight-bit codespace there just means they don't have to do either of those things, meaning that different networks will look for i18n A RRs in different ways and places. In short, encouraging the use of profiles for all domain names encourages strong data-typing across all applications which use all domain names, which benefits interoperability tremendously. This favortism towards strong data-typing also benefits applications which pass i18n domain names as in-band protocol data. Obviously, nameprep allows an i18n version of Finger (as an example) to know precisely what the rules are for the domain names that it exchanges, as would an i18n profile of mailbox names. Along the same lines, a profile for Kerberos also provides a way for participating applications to be able to create and verify those domain names when they need the protocol information, even if this data never goes into DNS. But if it does go into DNS they can use the profile there as well. draft-ietf-krb-wg-krb-dns-locate-02.txt described a way to provide DNS->Realm mappings using TXT RRdata to store the Kerberos realm name, but a profile would allow a kerberos-specific RR to be creeated for the same purpose and with greater efficiency and accuracy (note that Kerberos' use of uppercase for realm names prohibits nameprep). There is another reason for going this route, which is that the presence of eight-bit codes in the STD13 namespace makes managing UCS names in dual-mode servers extremely difficult. It essentially requires that servers flag eight-bit domain names as NOT UCS so that the names don't get looked at when an EDNS/deACE'd query comes in. Part of the original motivation for going to a profile centric world was to resolve this specific problem. I don't want it back in after all this. Anyway, those are my reasons for arguing that DNSEXT clarify the interpretation of RRs in the legacy namespace at the same time the new namespace is defined. Leaving those in there wouldn't really solve any of the problems we are trying to fix in the long run. I will post a discussion of the i18n namespace with multiple profiles tomorrow which will hopefully remove your remaining doubts about its viability. It is really fairly simple and straightforward, and it yields many benefits, some of which are outlined above. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
