ietf
[Top] [All Lists]

Re: Update of RFC 2606 based on the recent ICANN changes?

2008-07-02 16:03:25


--On Wednesday, 02 July, 2008 11:52 -0400 Lyman Chapin
<lyman(_at_)acm(_dot_)org> wrote:

With apologies for coming late to this thread -

Any proposal for a new gTLD must satisfy a number of "string
criteria" that will be specified explicitly in the RFP,
including the requirements that the U-label must not:

(a) be identical to an existing TLD;

Is "сом" identical to "com"? (the first of these is U+0441
U+043E U+043C)

(b) be identical to a Reserved Name;

(c) consist of a single character;

I've heard it argued repeatedly that this is an unreasonable
rule for ideographic characters.   I don't have an opinion, but
hope that ICANN has considered that case in full details.

(d) consist of two characters, unless (a) it consists of a
single Letter and a single Digit (in either order), or (b) it
is an IDN string and the two characters are registered as
permitted for two-character labels in the relevant
script/language;

This rule would permit such TLDs as "1F" or "0F", which I'm not
persuaded are good ideas given what some operating systems (as
discussed on this list) think might be "digits".

I also trust that ICANN has obtained an agreement from ISO,
signed in some appropriate medium like blood, that the ISO
3166-1 alpha-2 code list will not be expanded to include
letter-digit combinations when the 50-year rule (new with ISO
3166-1:2007) causes them to run short of codes.

(e) consist entirely of Digits;
(f) be a hexadecimal number consisting of the Digit "0"
followed by the uppercase or lowercase Letter "x||X"
followed by a sequence of one or more characters all of which
belong to the set of uppercase or lowercase Letters "a||A"
through "f||F" and the Digits "0" through "9";

This is, IMO, much too subtle and admits of cases that will
confuse some applications.   It is not an accident that the
statement in 1123 can (and, if my recollection of 1591 is
correct, should) be interpreted as prohibiting TLDs that are
non-alphabetic.   That rule obviously needs to be modified for
IDN A-labels, but should still be treated with care, IMO.

(g) be an octal number consisting of the uppercase or
lowercase Letter "o||O" followed by a sequence of one or
more characters all of which belong to the set of Digits
"0" through "7";

See above.

(h) contain any Unicode code point that is classified as
DISALLOWED or UNASSIGNED by RFC nnnn (currently "The Unicode
Codepoints and IDNA," draft-faltstrom-idnabis-tables-05.txt);
(i.1) [if IDN Language Reference Tables have been defined]
contain any Unicode code point that is not present in the IDN
Language Reference Table to which the Application refers;
(i.2) [if IDN Language Reference Tables have not been defined]
contain any Unicode code point that is classified as
CONTEXTUAL RULE REQUIRED by RFC nnnn (currently "The Unicode
Codepoints and IDNA," draft-faltstrom-idnabis-tables-05.txt);
(j) begin or end with a Hyphen; or
(k) contain Hyphens in both the third and the fourth position.

In addition, the A-label obtained by applying the IDNA
algorithm specified in RFC 3492 to the proposed string must:

(l) be identical to the A-label specified in the Application;
and
(m) consist of no more than 63 characters.

(Note: the capitalized terms will be formally defined in a
Definitions section of the RFP.)

Having read most, but not all, of the postings to this thread,
I believe that these rules cover many (but probably not all)
of the cases that have been discussed. Things will get both
simpler and more complicated when the IDNAbis WG completes its
work, but within ICANN there is a clear intention to track
that work as closely as possible given the timing constraints
of the new gTLD program. Many of the devils that concern the
IETF, of course, are in the details of the Reserved Names
list. If there are problematic cases other than those that
would have to involve the Reserved Names list, I would very
much like to hear about them.

As a rhetorical question relating to several of the other
comments in this thread, has the IETF been formally asked to
review and sign off on these rules?

    john




_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>