Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.
Ce contenu est uniquement disponible en
If you selected “no,” Limited Use scripts should not be supported for IDNs at the second level, please explain why? If you selected “yes,” are there any specific script(s) that should be clearly supported? If so, please list them and explain why?
The Unicode Consortium has sometimes used the likelihood of a combination of characters actually appearing in a natural language as a criterion for the safety. DNS names are often fabrications -- abbreviations, strings deliberately formed to be unusual, members of a series sequenced by numbers or other characters, and so on. Consequently, a criterion that considers a change to be safe if it would not be visible in properly-constructed running text is not helpful for DNS purposes: a change that would be safe under that criterion could still be quite problematic for the DNS. ICANN Restricted Code Points are specifically disallowed for IDN registrations. IDNs at Second Level in the scripts identified as "Limited Use" by UNICODE should adhere to the ICANN Restricted Code Points.
If yes, please suggest the changes in the criteria for shortlisting scripts for IDNs at the second level:
Conversion of the domain name into an ASCII-Compatible Encoding (ACE) Homoglyph Bundling Variants
The Variants and Confusables may need Supplementary Panel(s).
Please note that the Unicode Standard provides default algorithms for determining grapheme cluster boundaries, with two variants: legacy grapheme clusters and extended grapheme clusters. To my mind, algorithmic approach may resolve many concerns on the number of variants. It is just that the LGR need to happen in tandem with the algorithms.
With the Unicode 16-bit encoding system, over 65,000 characters can be encoded (216 = 65,536). However, the total number of characters that needs to be encoded has actually exceeded that limit. To find additional place for new characters, developers of the Unicode Standard decided to introduce the notion of surrogate pairs. Three supplementary planes are defined for this purpose.
In the Unicode standard, a plane is a continuous group of 65,536 (216) code points. There are 17 planes, identified by the numbers 0 to 16, Plane 0 is the Basic Multilingual Plane (BMP), which contains most commonly used characters. The higher planes 1 through 16 are called "supplementary planes". The limit of 17 planes is due to UTF-16, which can encode 220 code points (16 planes) as pairs of words, plus the BMP as a single word. UNICODE Planes 4 to 13 are unassigned i.e no characters have yet been assigned, or proposed for assignment.
Can ICANN open supplementary panel(s) for the Generation Panel for IDNs ?
ICANN Restricted Code Points
ASCII-Compatible Encoding (ACE)
Variants - Suggested Use of Supplementary Panel (s)