Subject: [idn] Fw: Moving Towards UTF8 vs ASCII(ACE) Forever

From: "James Seng" <[email-masked]>
Date: Mon, 1 Apr 2002 10:00:00 +0800

fyi

----- Original Message -----
From: "Donald Eastlake 3rd" <[email-masked]>
To: <[email-masked]>
Sent: Monday, April 01, 2002 12:31 AM
Subject: Re: Moving Towards UTF8 vs ASCII(ACE) Forever

> There is now a standard way to encode URIs containing arbitrary UNICODE
> characters. This is described in RFC 3275 (which is currently a Draft
> Standard), in Section 4.3.3.1, and in the corresponding W3C document and
> has appeared in other W3C documents, for exampe XML Base.
>
> Donald
>
> On 30 Mar 2002, [ISO-8859-1] Claus Färber wrote:
>
> > Date: 30 Mar 2002 16:13:00 +0200
> > From: "[ISO-8859-1] Claus Färber" <[email-masked]>
> > To: [email-masked]
> > Subject: Re: Moving Towards UTF8 vs ASCII(ACE) Forever
> >
> > Keith Moore <[email-masked]> schrieb/wrote:
> > > second, "ASCII for the rest of our lives" is a mischaracterization.
> > > IDNA allows applications to accept and present IDNs in native
> > > form, without requiring all applications and infrastructure to
> > > upgrade before IDNs can be used. [...]
> > > users don't care whether IDN queries are encoded on the wire.
> >
> > This depends on your definition of "on the wire"; if you want to
> > IDNs to just work, you would have to put the ASCII version into
> > URIs, too. Users *do* care about URIs. If you put the UTF-8
> > version (%-escaped or maybe even unencoded according to a revision
> > of the URI specs) in the URI, they won't work with leagacy
> > software anyway (so ACE has no advantages).
> >
> > Claus
> > --
> > ------------------------
http://www.faerber.muc.de/ ------------------------
> > OpenPGP: DSS 1024/639680F0 E7A8 AADB 6C8A 2450 67EA AF68 48A5 0E63 6396
80F0

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 31 Mar 2002 18:44:47 -0800

Donald Eastlake 3rd <[email-masked]> wrote on the IETF list:

> There is now a standard way to encode URIs containing arbitrary
> UNICODE characters. This is described in RFC 3275 (which is
> currently a Draft Standard), in Section 4.3.3.1, and in the
> corresponding W3C document and has appeared in other W3C documents,
> for exampe XML Base.

So U+00E1 LATIN SMALL LETTER A WITH ACUTE (á), which is 0xC3 0xA1 in
UTF-8, is encoded as
"%C3%A1" (six bytes) according to RFC 3275.  All BMP characters above
U+07FF, including all CJK characters, take three UTF-8 bytes and thus
nine RFC 3275 bytes.

I thought CJK users and others wanted *better* compression.

(No, David, I know you're not all the same person.  I heard lots of
voices saying the same thing.)

-Doug Ewell
 Fullerton, California

---

From: "Bruce Thomson" <[email-masked]>
Date: Mon, 1 Apr 2002 12:28:33 +0900

> I thought CJK users and others wanted *better* compression.

They DO want it, but they want it for protocols where there is a severe
length limitation on the encoded form. Correct me if I'm wrong but I
don't think there's such a restriction on URIs.

Presumably any extension to DNS which made Unicode
explicity allowed would also allow longer strings?

Bruce