"Adam M. Costello" wrote: > > "Eric A. Hall" <[EMAIL PROTECTED]> wrote: > > > IDNA applies to any domain name defined as a profile of stringprep, > > and is not dependent on nameprep. > > Nameprep is essential to any IDN solution (IDNA or any other).
Nameprep is only essential to the creation and intepretation of the domain names used with *specific* resource records. Storing, transferring and converting the data does not require this knowledge. For example, the authoritative master for a zone needs to know that nameprep applies to the owner name of an i18n A RR, so that these rules can be enforced when the RR is created. Similarly, an application which can create and/or read i18n A RRs from EDNS messages needs to know that nameprep applies so that it can validate the domain name. However, a cache inbetween an EDNS client and server does not need to know these rules, since it will only work with data which has already been properly formatted by the client or server. Furthermore, a cache which converts a UTF-8 i18n A RR into ACE does not need to know the rules, because the input data will have already been formatted properly. This is also true for replication servers within the zone; they can assume that the original data is properly formatted, with no knownledge of the rules used to generate that data. This same reasoning applies to all RRs regardless of the stringprep profile they use. If an i18n RP RR contains an i18n email address, the i18n localpart rules would only apply to the creation of the RR data. The infrastructure can be relatively ignorant about these rules. Consider another example, where a specific application requires the use of an i18n RR which does not conform to nameprep. It is feasible that a FOO RR will need to define it's own rules, perhaps because the application requires all-uppercase, or because the RR data is storing raw text which must not be normalized. If the infrastructure is opaque, then these RRs can be defined at the authoritative master for the zone and within the application that uses these RRs, while the infrastructure can be completely ignorant of the rules. Caches can even perform conversion because the rules say (or they *SHOULD* say) that the inputs and outputs are simple octet streams. That is the same model used today and we need to stick with it. > In order > to avoid chaos, we need everyone (not just DNS servers, but applications > and everything else) to agree on whether two domain names are the same > or not. Is IDNA capable of producing identical output for two different inputs (setting aside the issue of normalizations)? That is the only real question as to whether or not the separation can occur. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
