Subject: [idn] SC/TC equivalence

From: [email-masked]
Date: Sat, 11 Aug 2001 11:22:15 -0700

The statement is correct to the extent that every home has
a good collection of books, but the extent to the satement is:
 so we don't need a library in the city, that is where we depart.

[nameprep] is the place for case folding for Latin, then it should
be the place for other script folding as well.  If [nameprep]
is too complex, than it can be a directory type architecture using
language tag as keys.  If [nameprep] does not deal with 
SC/TC equivalence then we are back to the discussion to
two months ago.   Are there any draft demostrating how 
 [nameprep] process each incoming Unicode string step by 
step?

Liana

On Fri, 10 Aug 2001 10:28:02 -0700 "Mark Davis" <[email-masked]>
writes:
> For SC/TC equivalence, the feedback I have gotten is that "In 
> practice, most
> Chinese would expect either simplified or traditional, but not a 
> mixture of
> both", and from another writer, "Simplified and traditional are
> usually used in their own contexts, and a domain name is a single 
> context,
> and thus wouldn't result in a mixture of the two systems."
> 
> If that is true, then for TC/SC, unlike case, registering exactly two
> variants of any particular domain name would be sufficient; one 
> would not
> have to register n^2 combinations. Given that, registering SC/TC 
> variants is
> much more like registering two different languages and/or scripts, 
> something
> best left to documentation instead of changing nameprep.
> 
> Mark
> 
> ————�?
> 
> πάντων μέτρον ἄνθρωπος �?Πρωταγόρας
> [http://www.macchiato.com]
> 
> ----- Original Message -----
> From: "Erik Nordmark" <[email-masked]>
> To: "Adam M. Costello" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, August 09, 2001 23:47
> Subject: Re: [idn] SC/TC equivalence
> 
> 
> >
> > > Thank you!  One thing that should be considered by anyone 
> contemplating
> > > server-side equivalence rules is that clients will not know that 
> the
> > > names are equivalent.  For web browsers, this will affect 
> visited link
> > > coloring, page caching, cookie permissions, etc.  Similar 
> pitfalls will
> > > exist in other applications.  Zone administrators willing to 
> tolerate
> > > such limitations are free to do server-side equivalence matching 
> to
> > > their heart's content.  It would be ludicrous for this working 
> group to
> > > try to prohibit this practice, because it's equivalent to 
> populating the
> > > zone with identical data for all the matching names, which is 
> obviously
> > > permitted.
> >
> > I don't think this WG prohibits this - it shouldn't as far as I 
> can tell.
> > But the ability of the client to tell
> > that it got the right answer to a DNS query does add some severe
> constraints.
> > [I assume DNS protocol experts will correct me if I got thins 
> wrong.]
> >
> > If the client asks for A and gets a respose with QNAME A' and 
> answer X
> then how
> > does the client know that it wasn't spoofed? Applying DNSSEC would 
> just
> tell
> > the client that X is indeed the answer to the question for A'.
> >
> > So unless the server mains records for both A and A' (with their 
> SIGs)
> > (where A and A' really expand to all the possible combinations as 
> in
> > the UNAME) then the client needs to verify that A and A'
> > match.
> >
> >
> > Thus there seem to be two choices:
> >  - client sends A to server
> >  - server folds A to A' (A' := nameprep(A)), looks up A' and 
> responds to
> client
> >  - client verifies that A and A' are the same by checking 
> nameprep(A) = A'
> >    (to prevent being spoofed)
> >
> > OR
> >  - client does A' := nameprep(A), sends A' to server
> >  - server looks up A' and responds to client
> >  - done
> >
> > Thus client might as well do the nameprep before composing the 
> query
> > and save the work in the server.
> >
> >   Erik
> >
> >
> >
> >
> 
>

---

From: "Adam M. Costello" <[email-masked]>
Date: Sat, 11 Aug 2001 19:13:55 +0000

[email-masked] wrote:

> [nameprep] is the place for case folding for Latin, then it should be
> the place for other script folding as well.

That's a valid argument, but there are also some counter-arguments:

Existing domain names are already case-insensitive, so IDNs ought to
be case-insensitive for consistency with the current standard.  This
consistency constraint does not apply to SC/TC equivalence.

With very few exceptions, case mapping is one-to-one.  SC/TC mapping is
more complex more often.

The case mapping rules are already defined in the Unicode standard.
This is not true for SC/TC mapping.

Some people have expressed a desire to be able to register the
simplified and traditional versions of a name as separate domain names.
No one has expressed an analogous desire to be able to register the
all-uppercase and all-lowercase versions of a name as separate domain
names.

AMC

---

From: "Soobok Lee" <[email-masked]>
Date: Sun, 12 Aug 2001 10:33:33 +0900

----- Original Message -----
From: "Adam M. Costello" <[email-masked]>

> consistency constraint does not apply to SC/TC equivalence.

This is a really controversial issue.

NAMEPREP also applies additional equivalence rules in addition to
case-folding:
   1) compatibility decomposition
   2) canonical composition

What is the difference between these equivalences and SC/TC equivalence?

> This is not true for SC/TC mapping.
The Unicord Standard is not the only document we can refer to.
I have no doubt about the accuracy of CNNIC-provided SC/TC mapping tables.

> simplified and traditional versions of a name as separate domain names

If  SC/TC equivalence is like the equivalence between  "humor" and "humour",
registration/dispute resolution policy may be the right path to solve this
issue.

But, if SC/TC equivalence is like the equivalence between "H" and "h",
we should fold them. BTW, in which direction ?    SC->TC or TC->SC?
How can we recover the pre-normalization form of folded TC/SC domains?

--LSB