[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] IDNRA comments
- To: Dave Crocker <dhc@dcrocker.net>
- Subject: Re: [idn] IDNRA comments
- From: James Seng <James@Seng.cc>
- Date: Fri, 01 Sep 2000 07:52:25 +0800
- Cc: idn@ops.ietf.org
- Delivery-date: Thu, 31 Aug 2000 16:53:44 -0700
- Envelope-to: idn-data@psg.com
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/