Re: [idn] IDNRA comments

[James Seng <James@Seng.cc>]

A twist in the same argument but would make good sense too :-)

Care to doc this down in an I-D? We need a transition doc.

-James Seng

Dave Crocker wrote:
> 
> 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/