Re: [idn] SC/TC equivalence

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

Huh?
—————

πάντων μέτρον ἄνθρωπος — Πρωταγόρας
[http://www.macchiato.com]

----- Original Message -----
From: <liana.ydisg@juno.com>
To: <mark@macchiato.com>
Cc: <Erik.Nordmark@eng.sun.com>; <amc@cs.berkeley.edu>; <idn@ops.ietf.org>
Sent: Friday, August 10, 2001 12:48
Subject: Re: [idn] SC/TC equivalence


> 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.
>
> Liana
>
>
> On Fri, 10 Aug 2001 10:28:02 -0700 "Mark Davis" <mark@macchiato.com>
> 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" <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
> > >
> > >
> > >
> > >
> >
> >
>
>