IDN Variant Labels: Difference between revisions
No edit summary |
No edit summary |
||
| Line 19: | Line 19: | ||
==Variants in IDN ccTLDs== | ==Variants in IDN ccTLDs== | ||
On 22 March 2010, [[ICANN]] released its “Proposed Implementation Plan for Synchronised IDN ccTLDs.” The idea for “synchronised IDN ccTLDs” would allow for labels that are “considered equivalent” to be delegated in cases where the multiple labels would solve significant problems for Internet users, and the operation of the multiple labels would be expected to operate in the same way (i.e. resolve with the same data). A public comment period was held to seek feedback on the idea, with this work ongoing. | On 22 March 2010, [[ICANN]] released its “Proposed Implementation Plan for Synchronised IDN ccTLDs.” The idea for “synchronised IDN ccTLDs” would allow for labels that are “considered equivalent” to be delegated in cases where the multiple labels would solve significant problems for Internet users, and the operation of the multiple labels would be expected to operate in the same way (i.e. resolve with the same data). A public comment period was held to seek feedback on the idea, with this work ongoing. | ||
==References== | |||
Latest revision as of 17:34, 11 July 2022
IDN variant labels are Internationalized Domain Name (IDN) labels that certain script communities have been identified as technically distinct, but visually indistinguishable or linguistically interchangeable. IDNs are domain names that enable the use of scripts encoded by the Unicode standard, instead of ASCII and were introduced by ICANN to promote and develop a multilingual Internet. It is an alternate code point (or sequence of code points) that could be substituted for a code point (or sequence of code points) in a candidate label to create a variant label that is considered the “same” in some measure by a given community of Internet users. There is no general agreement on what that sameness requires.
SAC120[edit | edit source]
In the DNS, two variants are distinct domain names. It is users of specific communities who see variants as equivalent, but they are actually different. The issue is that they need to be transferred and grouped together, and there is no protocol solution. AN IDN and its variants must be treated as a single package from a domain provisioning and life cycle management perspective, which is a policy issue.[1] Questions include should the variants be delegated and the balancing of usability and security. Patrik Fältström explained that the SSAC recommends a cautious, conserved approach, arguing that the Root Zone must use the ICANN Root Zone Label Generation Rule to determine variants for all current and future TLDs.[2]
Types of Variant Labels[edit | edit source]
There are two types of variant labels: within-script and cross-script.
Within-script[edit | edit source]
There are various reasons that particular script communities consider certain strings as variant labels.
- In Chinese, the traditional and simplified characters share meaning but contain slight variations in the characters.
Cross-script[edit | edit source]
Variant labels occur across scripts when different scripts contain visually indistinguishable characters
- Latin and Cyrillic scripts contain several different characters that are nearly identical.
- Example: epic (Latin) and еріс (Cyrillic)
Variants in IDN ccTLDs[edit | edit source]
On 22 March 2010, ICANN released its “Proposed Implementation Plan for Synchronised IDN ccTLDs.” The idea for “synchronised IDN ccTLDs” would allow for labels that are “considered equivalent” to be delegated in cases where the multiple labels would solve significant problems for Internet users, and the operation of the multiple labels would be expected to operate in the same way (i.e. resolve with the same data). A public comment period was held to seek feedback on the idea, with this work ongoing.