IDN Variant Labels: Difference between revisions

(4 intermediate revisions by 2 users not shown)

Line 2:

by a given community of Internet users. There is no general agreement on what that sameness requires.

==SAC120==

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.<ref>[https://www.icann.org/en/system/files/files/sac-120-en.pdf SAC120, ICANN Files]</ref> Questions include should the variants be delegated and the balancing of usability and security. ~~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

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.<ref>[https://www.icann.org/en/system/files/files/sac-120-en.pdf SAC120, ICANN Files]</ref> 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.<ref>[https://74.schedule.icann.org/ SSAC/ALAC Joint Session, ICANN 74]</ref>

Line 19:

==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.

== References ==

[[Category:IDN]]

[[Category:Glossary]]

@@ Line 2: / Line 2: @@
 by a given community of Internet users. There is no general agreement on what that sameness requires.
 ==SAC120==
-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.<ref>[https://www.icann.org/en/system/files/files/sac-120-en.pdf SAC120, ICANN Files]</ref> Questions include should the variants be delegated and the balancing of usability and security. 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
+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.<ref>[https://www.icann.org/en/system/files/files/sac-120-en.pdf SAC120, ICANN Files]</ref> 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.<ref>[https://74.schedule.icann.org/ SSAC/ALAC Joint Session, ICANN 74]</ref>
@@ Line 19: / Line 19: @@
 ==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.
+== References ==
+{{reflist}}
+[[Category:IDN]]
+[[Category:Glossary]]