[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> >
> >
> >
> >
>
>