Subject: [idn] Using draft-jseng-idn-admin-01.txt

From: Hilde Margrethe Thunem <[email-masked]>
Date: Thu, 06 Feb 2003 09:04:59 +0100

I've been looking at the "Internationalized Domain Names Registration 
and Administration Guideline for Chinese, Japanese and Korean" 
(draft-jseng-idn-admin-01.txt)

It looked rather interesting as a language to express a policy in if 
there is characters that could be seen as variants of each other. As I'm 
from a Norwegian background I've looked at using the guidelines in the 
draft to describe an administrative domain name policy for the Norwegian
language, with a language character variant table. In Norwegian there
are few (if any) characters that may be said to be variants of each 
others in all instances where they are used. The closest we get is 
perhaps by dropping the accents (using o as a predominant variant of ó 
and ò) but as e.g. "for", "fór" and "fòr" has three different meanings 
(for, travelled and furrow) it is not immideately given that they should 
be stuck together in one IDL package. There is also certain characters 
that is imported fom neighbouring languages and used in Norwegian names, 
that sound similar in speech to already existing Norwegian characters 
(e.g ø and ö). These may be considered variants of each others. (And even 
if in the end the administrative policy is that all characthers has no
variants, the draft does give a way of easily expressing both that fact, 
and expressing which characters are within the set of valid code points.)

Having tried to use it, I have a few questions concerning the interpretation 
of the different groups in the language character variant table. As far as I 
can see the recommended variants must also be valid codepoints, and result 
in domain names that are in the zonefile, while character variants are merely 
reserved when a valid combination is registered and are not in themselves 
added to the zonefile. In addition, character variants that aren't valid 
codepoints can't be the "starting point" for an IDL package.

In other words, given a language character variant table where the letters 
a-z is among the valid codepoints, but does not have any recommended variants 
or character variants (except the letter itself), and the following lines in 
addition:

00F8; 00F8; 00F6;
00F6; 00F8; 00F8;

(ø; ø; ö;
 o; ø; ø;)

If I've understood correctly an application for the domain name bjørn.no 
will result in an IDL package consisting of bjørn.no and björn.no, where 
bjørn.no is added to the zonefile and björn.no is reserved. (As the ø is the 
recommended variant, while the poor ö is just a character variant). What
happens according to this policy if the domain name applied for is björn.no?
Will the registered name still be bjørn.no while björn.no is reserved?

And if the language table only had a-z and 

00F8; 00F8; 00F6;
(ø; ø; ö;)

would that mean that while one could still apply for bjørn.no (and get 
björn.no as a reserved name), someone applying for björn.no would get
rejected as that name contains a character that is not part of the valid
codepoints?

Sorry for asking the basic questions :-) but as the draft states, the 
quality of the language table is critical for the result... which means that
the logic behind how the table is built is important.

And while I'm asking questions, has any of you in the WG used the draft for 
creating a draft policy for a language?

- Hilde Thunem

---

From: Roozbeh Pournader <[email-masked]>
Date: Sun, 9 Feb 2003 22:02:51 +0330 (IRT)

> creating a draft policy for a language?

I am writing an I-D based on draft-jseng-idn-admin for policies for
Arabic, Persian, Urdu, and Pashto. I will post it here when I finished it.

roozbeh

---

From: "James Seng" <[email-masked]>
Date: Mon, 10 Feb 2003 09:44:17 +0800

Hi Hilde,

> language, with a language character variant table.

To be exact, you can break the document into two sections:

a) How to generate variants of an IDN?
b) How do you handle all these variants?

For (a), the document describe a mechanism using language variants tables
and also an aglorithm to generate variants. This designed specifically for
CJK so I am not sure much Norwegian can use the same concept.

For (b), the document describe a mechanism of an IDN Package (IDL), how this
is registered, transferred, deleted, activiated, de-activated etc. I believe
this would be more or less consistent across different languages.

> in domain names that are in the zonefile, while character variants are
merely > reserved when a valid combination is registered and are not in
themselves
> codepoints can't be the "starting point" for an IDL package.

Yes, recommended variants usually are also valid codepoint.

> a-z is among the valid codepoints, but does not have any recommended
variants > or character variants (except the letter itself), and the
following lines in
>  o; ø; ø;)

Yes.

> recommended variant, while the poor ö is just a character variant).

Yes.

> What

If björn.no is registered, then the zone file {ZV} will have two entry,
björn.no and bjørn.no. The first is because the registered names always get
into the zone file. The latter is because it is the recommended variant.

> rejected as that name contains a character that is not part of the valid

Yes. Since ö is not in the entry of the first column (valid code point), it
björn.no will not be allowed to be registered.

> the logic behind how the table is built is important.

Not a problem at all. But having said all these, I like to reminded you
again that the algorithm is designed for CJK. If it works for Norwegian, it
occurs not by design. If there is another algorithm to generate variants
which is more suitable for Norwegina, I am very interested to know.

> creating a draft policy for a language?

Yes. The JET (CNNIC, TWNIC, KRNIC, JPNIC) are using this document as a
base-line for registration of CJK.

-James Seng