"Eric A. Hall" <[EMAIL PROTECTED]> wrote: > Nameprep is only essential to the creation and interpretation of the > domain names used with *specific* resource records.
Nameprep is at the heart of the definition of equivalent labels. In today's domain name system, you cannot have foo and Foo and FOO as three separate entries in the same zone. No matter which one you ask for, you'll get the same records back, because they are equivalent labels. This will still be true for IDNs. No matter whether you ask for f�o, F�o, or F�O, you'll get the same records back. (For the Latin-1-impaired, the non-ASCII characters are o with umlaut.) You seem to be proposing a model in which there might be special kinds of labels that use different Stringprep profiles that don't do case folding. But then queries for f�o, F�o, and F�O could return three different results. That would be a fundamental departure from today's model. Nameprep is inseparable from IDNA not only for names of resource records but also for domain names appearing inside resource records, because you never know when or why or by whom domain names will get compared. Let's examine how f�o and F�O can get compared. The ACE form of both is xx--fo-fka. But if we were to skip Nameprep when converting F�O, we would get xx--FO-ohA. Now consider an entity that knows that f�o and F�O and xx--fo-fka and xx--FO-ohA are domain labels, but does not know that they are special labels that don't use Nameprep. Will this entity consider f�o and F�O to be equivalent? Yes, because domain labels are case-insensitive. Will it consider f�o and xx--fo-fka to be equivalent? Yes, because the latter is the ACE encoding of the former. Will it consider labels xx--fo-fka and xx--FO-ohA to be equivalent? No, because they are ASCII labels and the usual ASCII comparison rules apply. Therefore, by transitivity of equivalence, this entity cannot consider F�O and xx--FO-ohA to be equivalent. That's an important result. An entity that doesn't know about special non-nameprepped labels cannot convert between the non-nameprepped-ACE form and the Unicode form (because it doesn't consider the two forms to be equivalent). Only an entity that knows the special nature of such labels can do the conversion. Therefore, we might as well not overload the IDNA prefix for such purposes, but instead use a different prefix associated with a different Stringprep profile. If an entity knows about the special non-nameprepped labels, it can easily look for the other prefix. If an entity doesn't know about the special non-nameprepped labels, it couldn't do the conversion anyway, so it doesn't matter that it doesn't know the prefix. Having different prefixes for different profiles would help avoid confusion and mistakes. I think these special non-nameprepped labels that you envision tend to be the result of mapping non-domain-label data onto domain labels (like email address local parts). Domain labels have their own matching rules, and those rules apply to all domain labels, and Nameprep is an integral part of those matching rules (for IDN labels). If you want to map some other data type onto domain labels, then it's up to you to define a mapping that copes with any differences between the domain label matching rules and the matching rules of the other data type. IDNA is designed to convert domain labels to other domain labels, and to compare domain labels. It is not designed to convert between domain labels and other data types. If you want to define such conversions, you are free to immitate IDNA. Maybe you will end up with something just like IDNA except that it uses a different Stringprep profile and a different ACE prefix. (But if the other data type has such different matching rules, it might be easier not to try to map it onto a domain name at all, but instead just let it be its own data type. There's no law that says everything needs to be represented as a domain name. Resource records can define arbitrary data formats.) > Is IDNA capable of producing identical output for two different inputs > (setting aside the issue of normalizations)? I'm not sure what you mean. Nameprep can of course produce identical output for two distinct inputs. But for two distinct outputs of Nameprep, ToASCII cannot produce the same output. AMC
