looking up domain names with unassigned code points

Vint Cerf vint at google.com
Mon May 12 02:35:19 CEST 2008


Jefsey, I think what John meant is that the RFCs did not impose the  
restriction, ICANN did.

vint


On May 11, 2008, at 4:17 PM, JFC Morfin wrote:

> At 21:10 11/05/2008, John C Klensin wrote:
>> Of course, there is no such requirement or restriction in either
>> IDNA2003 or proposed for IDNA2008, nor are there strong
>> guidelines that prohibit such registrations.  Some serious
>> confusion and/or FUD going on here.
>
> Dear John,
> I do not know then how to read ICANN Guidelines :
>
>> 1. Domain registries that implement internationalized domain name  
>> capabilities
>> at any level, including their own top-level designations, will do  
>> so in strict
>> compliance with the technical requirements described in RFCs 3454,
>> 3490, 3491, and 3492 (collectively, the "IDN standards").
>
>> 2. In implementing the IDN standards, domain registries will  
>> employ an
>> "inclusion-based" approach (meaning that code points which are not  
>> explicitly
>> permitted by the registry are prohibited) for identifying  
>> permissible sets of code
>> points from among the full Unicode repertoire, as described below.  
>> A registry
>> may not even by exception permit code points that are prohibited  
>> by the IDN
>> standards.
>
>> 3. In implementing the IDN standards, domain registries will  
>> associate each label
>> in a registered internationalized domain name, as it appears in  
>> their registry, with
>> a single script as defined by the block division of the Unicode  
>> code chart. A more
>> specific association may be made by combining descriptors for both  
>> language
>> and script. Alternatively, a label may be associated with a set of  
>> languages, or
>> with more than one designator under the conditions described below.
>
>> 3.1 A domain registry will publish the aggregate set of code  
>> points that it
>> makes available in clearly identified IDN-specific character  
>> tables, and will
>> define equivalent character variants if registration policies are  
>> established
>> on their basis. Any such table will be designated in a manner that
>> indicates the script(s) and/or language(s) it is intended to support.
>
>> 3.2 All code points in a single label will be taken from the same  
>> script as
>> determined by the Unicode Standard Annex #24: Script Names
>> < http://www.unicode.org/reports/tr24>. Exceptions to this  
>> guideline are
>> permissible for languages with established orthographies and  
>> conventions
>> that require the commingled use of multiple scripts. Even in the  
>> case of
>> this exception, visually confusable characters from different  
>> scripts will not
>> be allowed to co-exist in a single set of permissible codepoints  
>> unless a
>> corresponding policy and character table is clearly defined.
>
> ".su" is just favoring a WSIS people centric vision of the Internet  
> over the network centric vision of the IETF. It seems that  
> currently 40 ccTLDs over more than 250 have signed an agreement  
> with ICANN.
>
> I do not think this creates any problem as long as users can filter  
> in the point-code they do not want to accept in their private  
> environment ?
> jfc
>
>
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080511/e68e2183/attachment.html


More information about the Idna-update mailing list