Subject: Re: [idn] SC/TC equivalence

From: [email-masked]
Date: Sat, 11 Aug 2001 09:47:00 -0700

Sorry, I can not read your reply.

Liana 

On Fri, 10 Aug 2001 12:57:04 -0700 "Mark Davis" <[email-masked]>
writes:
> Huh?
> ————�?
> 
> πάντων μέτρον ἄνθρωπος �?Πρωταγόρας
> [http://www.macchiato.com]
> 
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>
> 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" 
> <[email-masked]>
> > 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" <[email-masked]>
> > > To: "Adam M. Costello" <[email-masked]>
> > > Cc: <[email-masked]>
> > > 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
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>

---

From: "Adam M. Costello" <[email-masked]>
Date: Sun, 12 Aug 2001 03:38:35 +0000

Soobok Lee <[email-masked]> wrote:

>    1) compatibility decomposition
>    2) canonical composition
>
> What is the difference between these equivalences and SC/TC
equivalence?

That's a good question.  I consulted the Unicode standard for the
answer.  Canonically equivalent sequences are defined to be fully
equivalent.  Conformant processes are required to interpret canonically
equivalent sequences as the same (section 3.1 Conformance Requirements
--> Interpretation --> C9).  Compatibility characters are characters
that have compatibility decompositions.  They only reason they are
included in Unicode is for compatibility with other standards (to
allow lossless round-trip conversions).  Performing compatibility
decomposition removes only formatting information (which shouldn't
really be present in plain text in the first place).  (See section 3.6
Decomposition, and section 2.2 Unicode Design Principles --> Unification
--> Compatibility Characters.)

Apparently the Unicode folks judged that the difference between
simplified Chinese characters and traditional Chinese characters is
more significant than just formatting information, because they are not
compatible equivalents.

I think users understand that a simplified character and a traditional
character are two distinguishable things, even though some users might
wish for them to be interchangeable.  If they're not interchangeable,
some users might be a little annoyed, but at least they won't be
mystified.

Compatible equivalents, on the other hand, are things like ligature
fi versus separate fi.  Most people have never noticed that f and
i sometimes get joined.  People would be completely mystified if
ligature fi were not treated the same as separate fi.  Other compatible
equivalents are roman numeral IV versus letters IV, and fullwidth
A versus halfwidth A.  These are not merely characters with the
same meaning, they are really the same characters, just formatted
differently.

> If SC/TC equivalence is like the equivalence between "humor" and
> "humour",
>
> But, if SC/TC equivalence is like the equivalence between "H" and "h",

It's not exactly like either of those, but to me it looks closer to
humor/humour.

AMC

---

From: [email-masked]
Date: Sun, 12 Aug 2001 05:14:07 -0700

All the counter-arguments are valid.

1. SC/TC equivalence is similar to case folding for Latin, only 
it is a lot more larger.  When it is large, there comes with a variety
cases of equivalence.  All the examples mentioned exist for CJK,
but it is not deter the primary characteristics of a case folding.

2. From a user's viewpoint, the requirement is multitude.  
SC is a simpler set of CJK then TC. But users in China want 
TC in their names for artistic, special appealing, and specific
semantics in the TC.  Users outside of China, want SC for 
marketing to China, and simpler names (especial  the 
younger generations) for themselves to master.  Hong Kong 
is a good place to observe both of these users' wish-lists. 

3. To be handled reasonably for the above requirements, it is
reasonable to treat SC/TC as case-insensitive identifiers, 
consistent with DNS tradition, and only provide simple and
portable communication functionality to users from this 
standard body, and let applications deal with secondary 
equivalence issues. 

4. Unicode is large, so [nameprep] is large too.  However,
Unicode is a database.  It is up to us to use it efficiently.   
SC/TC case folding is large too,  but it is just a large table
sitting inside or next to Unicode for a look up search.  If we 
are  thinking [nameprep] in term of database lookup, then 
we can exclude many possible ACE leaks.  For example,
a string of whatever bit-stream comes in.  [nameprep]
trys to interpret it in, say, as 16-bits unit, and limits the 
range of searching say to Hindi script.   Anything outside
this Hindi script range, the input  becomes illegal and is 
kicked back as bad input.   Everything inside Hindi script 
range is filtered out for case folding and etc.  It is unlikely, 
we will have any script look alike confusion with this 
exclusion method. 

5.  If the above input is a CJK string, then we have a huge
range to worry about, it is another C[nameprep], J[nameprep]
and K[nameprep].  CNNIC have plenty of experts in 
handling this indivadually and very efficient too.  It is just an 
AI oriented code table search.

6. Though, [nameprep] becomes at least four [nameprep]s, 
which sounds a lot more complex,  by treating
[nameprep] as a database, and treating [nameprep] 
processing as a switch box,   a divide and conquer scheme
shall handle the problem and each section of the problem 
becomes minimal.

7. As to SC/TC case folding, I am proposing to fold to muemonic
ACE.  The ACE can be recovered to either SC or TC at the 
mercy of the application, or the presentation layer.  It is likely
that servers in the Mainland display everything in SC, and servers
in Taiwan display everything TC, regardless where the original
e-mail comes from.   I would be happy to see either regardless
where the e-mail comes from.   

If someone wants both versions then he can ask for a feature
 from the application to display 
either.   If he wants two different hostnames, he can do 1) what is
available now, by registering one in China, another one in Taiwan.  
2) By using the second step of StepCode to specify particular 
parts of its character, to get a different mnemonic ACE from the
first registered hostname, which shall force the application to
either interprate the ACE differently, or get the original registered
copy.
 If  the application does a good job to make its user happy, then 
there is no need to ask for the pre-folded case.  If someone 
demand the original copy, then the application shall request one
 from the original registrar, (not from [nameprep]) and keep that 
copy in its cache. 

Liana 

On Sat, 11 Aug 2001 19:13:55 +0000 "Adam M. Costello"
<[email-masked]> writes:
> [email-masked] wrote:
> 
> > [nameprep] is the place for case folding for Latin, then it should 
> be
> > the place for other script folding as well.
> 
> That's a valid argument, but there are also some counter-arguments:
> 
> Existing domain names are already case-insensitive, so IDNs ought to
> be case-insensitive for consistency with the current standard.  This
> consistency constraint does not apply to SC/TC equivalence.
> 
> With very few exceptions, case mapping is one-to-one.  SC/TC mapping 
> is
> more complex more often.
> 
> The case mapping rules are already defined in the Unicode standard.
> This is not true for SC/TC mapping.
> 
> Some people have expressed a desire to be able to register the
> simplified and traditional versions of a name as separate domain 
> names.
> No one has expressed an analogous desire to be able to register the
> all-uppercase and all-lowercase versions of a name as separate 
> domain
> names.
> 
> AMC
>