Re: [idn] One profile for domain names, or many?

["Eric A. Hall" <ehall@ehsco.com>]

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/