Re: [idn] IDNRA comments

[Dave Crocker <dhc@dcrocker.net>]

At 01:57 PM 8/31/00 +0200, Harald Tveit Alvestrand wrote:
>   I am not happy to end up with a situation where we will probably have 
> ACE on the wire forever, but I can live with that.

We might have it on the wire for a very long time, but that does not mean 
that we must have ONLY ace on the wire.

A variation of James Seng's comment is to view ACE for exactly what it 
is.  Not a character set, but a character set ENCODING.  The IRDA proposal, 
therefore, is exactly like the content-transfer-encoding scheme for MIME.

That is, it puts all of the (initial) burden for new character sets on 
those wishing to use it, rather than on the DNS infrastructure.  However 
the DNS infrastructure can still migrate to provide support, but it does 
not have to do this initially.

IRDA allows use of existing DNS servers.  However, it does not mean that 
ACE must live inside the servers forever.

For oDNS (old DNS) servers, there will never be any awareness of the new 
character set.  For DNSng (whatever the next generation of DNS 
client/server protocol is), the server can store the data in native 
(non-ACE) form and deliver it to requesting clients according to the 
protocol they use for querying.  They deliver it in ACE form for oDNS 
clients and in UTF form for DNSng.


>I suggest to make another picture.

Pictures like these are extremely important, since they make clear what 
form the data are in at different points.


The effect of IRDA:

1.  DNS server administration can continue unaffected, however...

2.  Some publicly visible DNS strings (stored as ACE in old servers) are 
going to look very strange.

3.  Clients and administrations wishing to support additional character 
sets can do so with changes only to the participating clients' software and 
to the DNS administration order-entry software.

4.  Servers can be upgraded at a later time and outside of the critical 
path for adoption of additional character sets.

5.  DNS names in an additional character set are going to be unusable for 
the ASCII-oriented user population; this is a major deficiency, but does 
not appear to have a near-term remedy, because...

6.  It would be wonderful to have ACE produce an ASCII encoding that is 
tolerable to human, but that probably requires wasting too many characters 
in a domain field to be acceptable.  (To re-invoke the MIME model, the 
difference in similar to the intention behind quoted-printable, versus 
bin64; unfortunately, quoted-printable has proved ineffective.)

d/