Subject: [idn] Namprep-02: ß.com

From: Rick H Wesson <[email-masked]>
Date: Fri, 2 Feb 2001 10:09:52 -0800 (PST)

Nameprep ß.com = ss.com

It's illegal to register ss.com as a ml domains because its only
plain ascii after nameprep.

How can anyone register  ß.com or will it be unavailable?

thanks,

-rick

---

From: John C Klensin <[email-masked]>
Date: Fri, 02 Feb 2001 22:42:24 -0500

> Nameprep ß.com = ss.com

Sorry, this probably flunks the "I see it on a card or screen and
don't know what script it is in" test.

Abcß.com (German script, i.e., Latin-1 subset of 10646) =
Abcss.com but acß.com (Greek script and a few others) = acß.com
(or maybe acb.com :-) ) and we are in huge trouble if it gets
coerced to acss.com.

And, to pick on your example for amusement value, ß.com (Greek)
is significantly more likely to occur in nature than ß.com
(German).

    john

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 04 Feb 2001 06:00:56 -0800

>plain ascii after nameprep.

"this" can mean 2 things, depending on how I interpret what I see.....

Either this is Unicode x00DF:
00DF;LATIN SMALL LETTER SHARP S;Ll;0;L;;;;;N;;German;;;
Or this is Unicode x032B:
03B2;GREEK SMALL LETTER BETA;Ll;0;L;;;;;N;;;0392;;0392

Both of these are lower case letters (Ll).
None have decompositions, canonical or otherwise.

The relevant text from nameprep-02 that produced the "sharp is ss" is:

>3.2 Additional folding mappings
>
>There are some characters that do not have mappings in [UTR21] but still
>need processing. These characters include a few Greek characters and
>many symbols that contain Latin characters. The list of characters to
>add to the mapping table were determined by the following algorithm:
>
>b = Normalize(Fold(a));
>c = Normalize(Fold(b));
>if c is not the same as b, add a mapping for "a to c".
>
>Because Normalize(Fold(c)) always equals c, the table is stable from
>that point on.

(Aside: I don't understand how this produced the entry "00DF; 0073 0073; 
Case map" in the tables, since there is no string that folds to 0x00DF.
It's "logical" in some sense, since 00DF mapped to UPPERCASE is 0073 0073
according to the Special Casing datafile of Unicode. But "Fold" does not 
map to uppercase, it maps to lowercase. And then 00DF maps onto itself.
Specification seems incomplete.)

>How can anyone register  ß.com or will it be unavailable?

According to the current nameprep doc, it cannot be entered into a 
zonefile, so it will be "mechanically unavailable".

The Greek Beta will be available.

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: "Mark Davis" <[email-masked]>
Date: Sun, 4 Feb 2001 09:30:08 -0800

The source documents to look at are:

http://www.unicode.org/Public/3.1-Update/CaseFolding-3d4.beta.txt

http://www.unicode.org/unicode/reports/tr21/

There it explains the treatment of es-zed.

Mark

----- Original Message -----
From: "Harald Alvestrand" <[email-masked]>
To: "Rick H Wesson" <[email-masked]>; "Paul Hoffman / IMC"
<[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, February 04, 2001 06:00
Subject: Re: [idn] Namprep-02: ß.com

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 04 Feb 2001 19:41:01 -0800

>There it explains the treatment of es-zed.

gotcha.

what I missed was that this section:

>3.1 Case mapping
>
>For each character in the input, if there is a lowercase mapping for
>that character, the input character is changed to the mapped lowercase
>character(s). The entries in the mapping table are derived from [UTR21].

could have read:

The input string is case folded according to [UTR21] section 2.3.
For most cases, this is the same thing as changing the input character to a 
lowercase character; however, for some cases more complex things happen.
The mapping table in appendix N is used. This is derived from [UTR21] by 
applying the rules for equivalence classes of section 2.3

This makes it easier to see that this is NOT a simple conversion to lowercase.
(there was no

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 5 Feb 2001 08:42:01 -0800

I agree that the wording in that section needs some cleanup. Just in case it
is not clear, the CaseFolding tables are part of the UCD. They are currently
in beta (although at this point it would require a special letter ballot to
change them); they will be final by the end of March.

> This makes it easier to see that this is NOT a simple conversion to
lowercase.

Looks like this message was cut off.

Mark
----- Original Message -----
From: "Harald Alvestrand" <[email-masked]>
To: "Mark Davis" <[email-masked]>; "Rick H Wesson" <[email-masked]>;
"Paul Hoffman / IMC" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, February 04, 2001 19:41
Subject: Re: [idn] Namprep-02: ß.com

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 6 Feb 2001 07:01:42 +0100

Paul Hoffman and I have created a mailing list for discussions of 
only the IDNA algorithm described in draft-ietf-idn-idna-00.txt. The 
reason for a separate mailing list for this discussion is because it 
otherwise the discussion of IDNA will otherwise get bogged down with 
arguments whether IDNA is the correct way to do IDN. Those discussion 
should instead be on the IDN WG mailing list (although the protocol 
design team report concluded that an ACE-based solution in the 
application is the right way to go for the short term). Paul and I 
have not got many comments, but we feel that the document and 
description, as well as the algorithm, might be made better.

Further, this message is sent to the apps-discuss list aswell as to 
the IDN mailing list as the IDNA algorithm can be used for domain 
name protocol components regardless of what protocol is using it.

The name of the mailing list is [email-masked].
Subscribe by sending request to [email-masked].

    paf

-- 
Patrik Fältström <[email-masked]>                         Cisco Systems
Consulting Engineer                                  Office of the CSO
Phone: (Stockholm) +46-8-4494212            (San Jose) +1-408-525-0940
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC