Update of RFC 2606 based on the recent ICANN changes?

[Lyman Chapin]

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;
(b) be identical to a Reserved Name;
(c) consist of a single character;
(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;
(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”;
(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”;
(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.

- Lyman

On Jul 1, 2008, at 6:36 PM, John Levine wrote:
>> This does not mean that ICANN won't listen to the IETF; it means
>> that there will be voices more familiar to ICANN saying things
>> different than we are.
>
> One of the few ICANN committees that actually works is the SSAC, the
> Security and Stability Advisory Committee.  It includes a lot of
> people we know, starting with Steve Crocker, the chair.  I cannot ever
> recall a time when ICANN acted contrary to the advice of the SSAC.
>
> So although I agree that there's a lot not to like about ICANN, the
> chances that they will do technically dangerous things are low.
>
> http://www.icann.org/committees/security/
>
> R's,
> John
> _______________________________________________
> Ietf mailing list
> Ietf at ietf.org
> https://www.ietf.org/mailman/listinfo/ietf