[idn] profiles and the i18n namespace

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

Herewith are a couple of examples of the way that profiles within the
i18n namespace could/should work. These are entirely invented.

One potential usage would be AppleTalk Name Binding Protocol (NBP) entries
which were stored in the DNS. If I were to design such a beast, I might
want to use multiple RRs which would facilitate easy registration via
Dynamic DNS and which would also support easy browsing of a zone. Thus I
might create a mutant of the SRV RR specifically for determining the local
atalk zone, an RR for finding all of the registered NBP names within the
atalk zone, and an RR for finding the IP address of a specific node:

 _nbp._atalk.domain           ATSRV  <atzone>.domain

 _nbp._atalk.<atzone>.domain  ATNBP  <nbpnode1>.<atzone>.domain
                              ATNBP  <nbpnode2>.<atzone>.domain
                              ATNBP  <nbpnode3>.<atzone>.domain

 <nbpnode1>.<atzone>.domain   ATA4   <ip4-address>

 <nbpnode2>.<atzone>.domain   ATA4   <ip4-address>

 <nbpnode3>.<atzone>.domain   4ATA   <ip4-address>


In order to use this I would need two profiles. I would need a profile for
defining the valid syntax for the owner domain name of the ATSRV mutant,
although the existing SRVprofile would work fine for the naming shown. I
would also need a new profile for the domain name elements (owner names
and RRdata) which explicitly referenced the NBP nodes.

Note that _Inside AppleTalk_ already provides normalization rules and
whatnot which suits their needs, so those would presumably be mapped into
the new profile directly (ass-u-me, this is just for example purposes).

This approach would mean that NBP clients would be able to easily predict
the naming they needed to register a node within the atalk zone for the
network they were on, and could pass a pre-structured name and RR to
dynamic DNS without DDNS needing to know anything about the name (a
gateway could also do this easily). Meanwhile, the structured profile also
makes it easy for applications to work with the names they get back from
the DNS when browsing the atalk zone. Clearly a structured profile would
be needed even if this model were slapped onto STD13 octets, but it would
also be necessary for the clients to make sense of the data from an i18n
namespace too.

The only real question at that point is whether or not the i18n namespace
can handle the alternative profile. The nameprep-only camp is arguing
against this on the grounds that it makes the namespace ambiguous,
although there is no technical reason (IMO) that this won't work.

First of all, a design as in the above avoids collisions through the use
of service-specific owner names. This would be intelligent and reasonable
design for anybody that wanted to avoid collisions. But let's assume they
don't take such reasonable measures. Let's also asume that reasonable
steps aren't taken to prevent collisions through nameprep comparisons.
What the heck, let's assume a worst case scenario where the owner names
are variants of a name and that they even reference each other through a
service-specific alias:

   _nbp._atalk.example.com.   ATNBP    MyMăc.example.com.

   MyMăc.example.com.         ATCNAME  mymăc.example.com.
   mymăc.example.com.         A        192.168.0.10

Assuming that the RR definitions and NBPprep profile allows for such
behavior, an NBP browser would still use the input from the ATNBP RR to
seed the original query. The user hasn't typed in the name. Insted the
target of the query would be the octet sequence of "MyMăc.example.com."

Note that this kind of mapping would even be required for a human to find
a match in the zone. A human query for "mymăc" would not work, since there
is no ATA4 or ATCNAME RR with that (octet-specific) owner name. Some kind
of application-specific stringprepping MUST ALWAYS BE USED for that
service to work at all.

Similarly, queries by traditional applications would not collide either,
since the queried names would have been fed through nameprep somewhere in
the process and would have collapsed down to the normalized form before
they were ever issued as DNS lookups. If the application is mangling the
nameprep process so badly that it doesn't collapse the owner name, well,
it's already broken. But even in that broken state NO ERRORS ARE PRODUCED
since there is no A RR at MyMăc.example.com., nor can there ever be one
since the nameprep rules associated with the A RR prohibit it.

For all of those reasons, I think it is rather plain that there isn't any
risk from cross-pollution, as long as the data-typing rules are adhered to
by both parties (the application that created the name, and the
application that is issuing a lookup for the name). Even if only one of
the parties enforces the rules, there is no serious risk of casual
collision (everyday queries for A and whatnot) since the application RRs
won't exist at the queried labels.

As for whether or not this makes the namespace confusing to users, I don't
think so, since most users don't ever see the innards of the namespace.
Even in the example above they would only see the NBP friendly name and
would have no idea that there are DNS names involved there.

Let the shredding begin.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/