[idn] SC/TC equivalence

[liana.ydisg@juno.com]

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" <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
> >
> >
> >
> >
> 
>