Subject: Re: [idn] Prohibit CDN code points

From: [email-masked]
Date: Wed, 23 Jan 2002 11:23:39 EST

In a message dated 2002-01-23 0:21:08 Pacific Standard Time, 
[email-masked] writes:

> Theoretically, 1-1 TC/SC mapping, ASCII uppercase/lowercase mapping or
> any table mapping are all belong to the same computing algorithm. From 
> computer science point of view, they are the same algorithm.

Every Latin uppercase letter maps unambiguously to a single Latin lowercase 
letter, regardless of context or meaning.  My understanding was that this is 
not true for every TC/SC character.  If it is, then please accept my 
apologies, but you will also have to convince the rest of the list.

> Your question should address to the souce of the table (1-1 only), not to 
> the computing algorithm.

If everything is 1-to-1 between TC and SC, the algorithm is trivial.  I was 
talking about the algorithm that would be necessary to do TC/SC conversion in 
the case of 1-to-many or many-to-1 conversions.  But, since you say there are 
none, I guess we can proceed with implementing the tables.

-Doug Ewell
 Fullerton, California

---

From: "Edmon" <[email-masked]>
Date: Wed, 23 Jan 2002 13:35:20 -0500

----- Original Message -----
From: <[email-masked]>
> none, I guess we can proceed with implementing the tables.
It is possible to implement a 1-to-many or many-to-1 conversion.
All it is required is that all "equivalent" characters be matched as
"equivalent" in the authoritative DNS.
For example, a simple rule that says:
A = a = A' = a'  (note that there need not be a "primary" character)
This represents a 1-to-many or many-to-1 situation.
So, if a domain comes in:
aA'.example
it will be matched the same is if a domain:
Aa'.example
comes in.
This is just the matching rule within the DNS server and does not have to
affect any of the IDNA process.
That is, the user wil still see and know and react to whatever they typed in
and believed to be accessing.
It does not take anything away from being able to use multilingual
characters in the DNS.

Edmon

---

From: David Hopwood <[email-masked]>
Date: Wed, 23 Jan 2002 05:22:22 +0000

-----BEGIN PGP SIGNED MESSAGE-----

Edmon wrote:
> > If everything is 1-to-1 between TC and SC, the algorithm is trivial.
> > I was talking about the algorithm that would be necessary to do TC/SC
> > conversion in the case of 1-to-many or many-to-1 conversions.  But,
> > since you say there are none, I guess we can proceed with implementing
> > the tables.
>

This doesn't work for the same reason that folding look-alike characters
doesn't work: you would need to put characters into equivalence classes
according to the transitive closure of the SC->TC and TC->SC mappings, and
that ends up putting completely unrelated characters in the same class.

I.e. start with a single character. Add all its TC/SC variants. For each
of those variants, add all their TC/SC variants, and so on, recursively.
For all I know you may end up with all Han characters in the same
equivalence class; perhaps not, but you certainly end up with very large
classes.

If TC/SC folding is done, it can only be done for the 1-1 subset of
mappings, and any variations in the algorithm must be based only on the
name itself, without making use of any other context (such as language,
etc.) I'm not qualified to judge whether it is useful to do TC/SC
folding under these contraints, but I suggest that those who advocate
it concentrate on that question, rather than making proposals that aren't
implementable.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: "James Seng/Personal" <[email-masked]>
Date: Thu, 24 Jan 2002 21:20:45 +0800

Dear all,

I was offline for 2 days and just finished reading 60+ message on this
thread alone.

While it is very interesting, I would like to remind everyone that in
order to make working group progress, we should focus our discussion on
"core interest".

The "core interest" of the group after SLC:

Requirements of Internationalized Domain Names
(draft-ietf-idn-requirements)
Internationalizing Host Names In Applications (IDNA)
(draft-ietf-idn-idna)
Preparation of Internationalized Host Names (draft-ietf-idn-nameprep)
Proposal for a determining process of ACE identifier
(draft-ietf-idn-aceid)
AMC-ACE-Z version 0.2.1(draft-costello-idn-amc-ace-z) renamed as
    Punycode version 0.3.3 (draft-ietf-idn-punycode-00)

Therefore, it would be better if we bring all discussion outside core
interest offline. We should focus on our current action item, namely:

1. Decision on Requirements Document

   Since there is no further feedback on the issues of dropping the
   requirements, then we should drop it from the pool.

   There is also no volunteer for the replacement doc so we will put
   the idea on hold until we find one.

2. WG Last Call for IDNA, Nameprep, AMC-ACE-Z (aka punycode)

   We should be doing it anytime now, hopefully within this week.

-James Seng

---

From: [email-masked] <[email-masked]>
Date: Sat, 26 Jan 2002 10:39:32 +0800

Dear All:
In the draft ,
http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-06.txt
define the single Unicode code point as follow:

Unicode [UNICODE] is a coded character set containing tens of thousands
of characters. A single Unicode code point is denoted by "U+" followed
by four to six hexadecimal digits, while a range of Unicode code points
is denoted by two hexadecimal numbers separated by "..", with no
prefixes.

My question are:
Q1:   U+hhhh  can be represented as u+hhhh  or not ?
Q2:   Here U+HHHH  is not a hostname , does it MUST be forced to lower
u+hhhh or not  in nameprep ?
Q3:  Puny code  draft  accept  U+hhhh  or  u+hhhh  to let the final encoded
ASCII character (last character of corresponding  encoded code point)  with
case upper or lower.

I   hope draft authors can help to clarify these interconnection point .

L.M.Tseng

---

From: "Adam M. Costello" <[email-masked]>
Date: Sat, 26 Jan 2002 04:15:37 +0000

"tsenglm@????????????.??????.tw" <[email-masked]> wrote:

> by four to six hexadecimal digits...
> 
> My question are:

The Unicode standard always uses U+, never u+, and the same is true of
the IDNA draft.  The Punycode draft always uses U+ in the main spec, but
the sample implementation uses both U+ and u+ in order to represent the
annotation flags, and the examples section likewise uses both U+ and u+
to make it easy to feed the examples into the sample implementation.

> u+hhhh or not in nameprep ?

The case of the U is not part of the code point.  A code point is just
an integer.  For example, U+0391 and u+0391 both represent the integer
913 (decimal) which is the code point for uppercase alpha.  U+03B1
and u+03B1 both represent the integer 945 (decimal) which is the code
point for lowercase alpha.  Nameprep always converts uppercase alpha
to lowercase alpha (so it would always output 945, never 913), but a
nameprep implementation that included support for mixed case annotations
would output not only an array of code points but also a parallel
array of case flags, and the lowercase alpha (945) would be flagged
as "wanting to be uppercase".  The flags could be passed along to the
Punycode encoder and recovered by the Punycode decoder.

The Punycode sample implementation and examples sections use U+03B1
to mean "lowercase alpha with flag set (wants to be uppercase)" and
use u+03B1 to mean "lowercase alpha with flag clear (wants to stay
lowercase)".

The flags have no affect on which ASCII letters and digits are output
by the Punycode encoder.  The flags merely affects the upper/lowercase
property of the ASCII letters.

AMC

---

From: [email-masked] <[email-masked]>
Date: Sun, 27 Jan 2002 08:40:35 +0800

Dear  Adam  & all :
          Thanks your reply ,  It is very clear, Punycode has some optional
features that can be selected by the implementers.  How to input the
information of  annotational flag is an implementation issue.

> to make it easy to feed the examples into the sample implementation.
        To my understand, I descrbe it as:  if the implementation want to
use the feature of  annotation, then the flag of annotation should be passed
from  ToASCII  thru nameprep to Punycode. If a tradition of  IETF RFC
protocol  is followed , input parameter by an ASCII  string  like U+hhhh
will be used ,  so  U+/u+  can be an annotational flags.
> property of the ASCII letters.
              I  think it is very clear,  the annotational flag just let the
Punycode input from an original  U/u+hhhh can output a LDH string with  a
upper/lower  character is set in its corresponding output part.  Punycode do
not change any results from nameprep even  it is work in single case
annotational mode.
            Actually, any  ACE encoder  can  do it the same way, but
Punycode is a special one that  treat basic code point and non-basic-point
as two separate parts, so it can let original flag information  can be
displayed in output string  even the coded ACE string is a lower case code
point .  The displayed case is no effect in DNS query, but it can help to
let user to view an original IDN form without  feeling  the nameprep has do
some strange thing to the ML-domain name.

Thanks  your  careful answers.
Best regards

L.M.Tseng