[Ietf-not43] issues and questions on FIRS

[Eric A. Hall]

on 8/18/2003 11:14 AM Andrew Newton wrote:

> My concern is that the xn-- 7-bit versions of the domains are the
> things that will be flying around the Internet and people will need to
> refer to them, even if some of their software does the Unicode
> conversion.  The fact is, the xn-- 7-bit version is what IS going to be
> in the zone files, and for troubleshooting purposes we need to be able
> to refer to them.

Not to belabor this particular point, but rather the issue as a whole...
The format of a domain name in any particular zone file is going to be
determined by the feature set of the server in use. Somebody is eventually
 going to figure out that administrators in ~Japan would prefer to have
their zone files use ~Katakana instead of ASCII. There is absolutely no
reason that a server cannot convert the data into ACE when the zone data
is loaded into memory (exceptions exist for products that ignore the DNS
in-band replication service in favor of things like rsynch, but those are
also marketing choices). So again all of this stuff is symptomatic of the
current state of the products and not a deliberate restriction. We should
be planning for where we think we'll be (or where we want to be) in 10
years, not where the last 20 years forced the current offerings to be.

> I have no problem with the protocol also allowing a user to specify the
> name in Unicode.  IRIS takes care of both cases.  I just think it is 
> important to also specify it for people mucking around in the 7-bit
> world.

I'm not sure we're on the same wavelength. What inputs or outputs are you
worried about specifically?

In the current model, the client is required to normalize input to the
UTF-8 representations of the canonical UCS name, and most of the
protocol-level traffic is required to use UTF-8 . That's JUST the
protocol-level traffic.

The format of the database contents are intended to represent the richest
possible view since those can always be down-converted. So for something
like an entry name (the cn attribute) that would be the UTF-8 form.
However, there are other classes of attributes where this is not going to
be an option. For example, the mail and labeledURI attributes are locked
to seven-bit syntaxes so they cannot (currently) use UTF-8. Meanwhile,
stuff like nameserver attributes would be stored in their rich form, but
would not use any of the escape mechanisms given their restrictions from
the DNS service.

Separately, the client is allowed to convert response domain names into
IDNA for local display purposes if necessary. For example, I could add an
"--output=idna" switch to firs.pl which would force the client to convert
any domain attribute to IDNA for display purposes. That would give users
the option of working with IDNA in all cases.

For anybody else's client (especially one which is intended to be highly
portable), IDNA might even be the default representation of the domain
name attributes.

So in all cases, the user has the option of working with whatever form
they find best suited to their needs.

All of this would also be possible if we reversed it around, such that
IDNA was used for the protocol messages, the database storage and the
default view, except that it would be much more difficult to implement
holistically and as deeply (it would require multiple search filters,
server-side conversion, etc).

Is there some other area of concern that I'm missing?

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