Re: [idn] Preserve case for IDNs during transportation

["Edmon Chung" <edmon@neteka.com>]

But is it not the same experience for the DNS today?  Case is preserved
during transport and matched by the server.  If authentication is required,
the client will match it correspondingly.
There is no issue about non-resolution because the client should retry if
the unpreped name is not found.  This infact is what some of the current
browsers already do for the casing in English.
Edmon


----- Original Message -----
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: "IETF idn working group" <idn@ops.ietf.org>
Sent: Thursday, June 13, 2002 8:08 PM
Subject: Re: [idn] Preserve case for IDNs during transportation


> Edmon Chung <edmon@neteka.com> wrote:
>
> > I think it makes a lot of sense to not force nameprep on the
> > application, but instead make it optional but mandatory on the server
> > end.  Just like what we have nowadays for English.
>
> I would have no objection to a newDNS protocol allowing unprepared
> non-ASCII text in queries and requiring the server to perform the
> preparation.  (Well, I might wonder about the computational load on the
> server.)
>
> But I don't like the idea of unprepared ACE forms.  It would mean
> disagreement about whether two ACE labels match.  Someone applying the
> traditional ASCII comparison might say they don't match, while someone
> applying your proposed decode-prepare-compare method might say they do
> match.  The conversions were designed so that comparing the ACE forms
> always yields the same answer as comparing the non-ASCII forms.  The
> conversions are designed so that "unprepared ACE forms" don't exist; if
> you think you have one, you will find that it doesn't decode, it's just
> an ASCII label that happens to begin with the ACE prefix, but it's not
> an ACE.
>
> AMC
>
>