Re: [idn] SC/TC equivalence

[liana.ydisg@juno.com]

Sorry, I can not read your reply.

Liana 

On Fri, 10 Aug 2001 12:57:04 -0700 "Mark Davis" <mark@macchiato.com>
writes:
> 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
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>