RE: [idn] My draft for internationalisation of DNS

[Karlsson Kent - keka <keka@im.se>]

Requiring that going from Unicode 3.0 to a successor would need
to start using EDNS is a bit strong I think.  Barring any major
catastrophic development of 10646, all that will happen is that
a "few" more characters are added (like about 41000 additional CJK
ideographs!).  I think that can be versioned in a smoother way than
jumping to EDNS.  Which characters are allowed or not should just
be a registration issue, not a protocol issue.  One might miss the
functionality of having the server normalise and downcase (for a
while), but that should only mean "not found" errors if the name
is not pre-normalised and pre-lowercase.

In my suggestion I had an additional reason to restrict IDNs to the
BMP initially (other than that that's all there is in Unicode 3.0):
namely small devices (like mobile phones).  They may stay with
UCS-2 (which is what some models of mobile phones are using)
rather than going to UTF-16 for quite a while.  But no, there
should be no protocol limitation to the BMP, just a registration
limitation.

As for sorting, I see two reasonable options: binary sort, or UTR 10
untailored default collation based sorting.  The latter will give
more "logical" result (though not tailored for a locale) for human
consumption than binary sort. But (from my point of view) I don't
want to request/assume a tie down of the UTR 10 tables (or ISO/IEC
14651 CTT, which is 'equivalent' in some sense) never to be changed
(and they are not tied down now). So if the result of this sorting
is not really for human consumption (as it apparently isn't), I'd
suggest sticking to "binary" sort, which is both simpler and won't
change (assuming normalisation + 'default' downcasing first).

		Kind regards
		/kent k


> -----Original Message-----
> From: Dan Oscarsson [mailto:Dan.Oscarsson@trab.se]
...
> Andy wrote (also related to Martin's comments):
> >I think this is a good basis for an IDN protocol, and is almost exactly
what
> >I would have written up had I had the time.  A few comments:
> >
> >There are some broken DNS servers which don't zero the last flag bit (the
> >one you have specified as the IN bit).  I suggest you use an EDNS option
> >instead (see RFC 2671).  In addition, I can imagine various levels of IDN
> >support (as more characters are added to ISO10646 for example) so a one
bit
> >flag may not be enough.
> 
> I wonder how the security extentions work as they also use some bits
> that are specified to be zero in RFC1035?
> 
> But you are right, there can be more levels of IDN support. This was also
> pointed out by Martin. I did not use EDNS because of the following
> reasons:
> - It should work with the current (that is now) DNS software.
> - There should be no additional requests needed to be sent for i18n aware
>   software.
>   
> EDNS, of what I can read, may result in an error message back from
> the DNS-server forcing the client to resend the request using old
> format. This will generate a lot of extra traffic and slow down things.
> 
> So, that is the reason for not using EDNS. But if EDNS could be used
without
> getting request rejected, it could be used. Looking at RFC1035 it
> might be possible to put something in the additional part of a request,
> without a rejection, but I do not know what current software does.
> 
> Anyway, to solve the problems with future extentions in the character set
> and additional i18n handling in DNS, we could define it as follows:
> 
> The protocol as defined in my draft defines the valid set of characters
> and rules as those defined by ISO 10646-1:2000/Unicode 3.0.
> When new characters are added to ISO 10646/Unicode or new i18n handling
> is needed, it will be handled by an extention as defined in EDNS.
> I18n aware software should not load or use characters outside the
> above range, unless they do not change the normalisation and 
> case folding mappings defined in Unicode 3.0.
> 
> This should allow IDN to be started to be used and it should be enough
> for several years. In that time EDNS should be ready to be used.
> When implementing Ii8n aware software, implementors should 
> look at EDNS and prepare for it.

...

> >You need to add a description of how DNS labels will sort (see section
8.2
> >of RFC 2535) so that DNSSEC will work.  I suggest that you specify that
> >names should be normalised and then lower-cased before sorting.
> >
> I looked at it, but missed that section. Thanks. I will something
> about that (though all names should be already normalised).
> 
>    Dan