Re: [idn] SC/TC equivalence

["Mark Davis" <mark@macchiato.com>]

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" <Erik.Nordmark@eng.sun.com>
To: "Adam M. Costello" <amc@cs.berkeley.edu>
Cc: <idn@ops.ietf.org>
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
>
>
>
>