Skip to main content

Publicación de recomendaciones para gestionar variantes de nombres de dominio de alto nivel internacionalizados

Esta página está disponible en:

LOS ÁNGELES, 5 de febrero de 2019. En el día de hoy, la Corporación para la Asignación de Nombres y Números en Internet (lCANN) anunció la publicación de un compendio de seis documentos con recomendaciones para la gestión de variantes de nombres de dominio de alto nivel internacionalizados. La organización de la ICANN desarrolló estas recomendaciones sobre la base de la retroalimentación presentada por la comunidad durante el periodo de comentario público correspondiente.

  1. Implementación de TLD con Variantes de IDN: Resumen Ejecutivo [PDF, 70 KB]
  2. Implementación de TLD con Variantes de IDN: Motivación, Premisas y Marco de Trabajo [PDF, 391 KB]
  3. Implementación de TLD con Variantes de IDN: Recomendaciones y Análisis [PDF, 382 KB]
  4. Implementación de TLD con Variantes de IDN: Fundamentos para las RZ-LGR [PDF, 497 KB]
  5. Implementación de TLD con Variantes de IDN: Riesgos y Mitigación [PDF, 230 KB]
  6. Implementación de TLD con Variantes de IDN: Apéndices (A: Definiciones, B: Uso de ROID, C: Limitación de Variantes de TLD Asignadas) [PDF, 530 KB]

Si bien la comunidad de Internet manifestó frecuentemente la necesidad de contar con variantes de nombres de dominio de alto nivel internacionalizados, faltaban los detalles y procedimientos técnicos apropiados para brindarles el soporte correspondiente. El 25 de septiembre de 2010, la Junta Directiva de la ICANN resolvió que "no se delegarán variantes de gTLD...hasta tanto se desarrollen soluciones apropiadas para gestionar variantes". Posteriormente, la organización y la comunidad de la ICANN analizaron cuestiones relativas a los códigos de escritura arábigo [PDF, 1.06 MB], chino [PDF, 2.86 MB], cirílico [PDF, 1 MB], devanagari [PDF, 461 KB], griego [PDF, 354 KB] y latino [PDF, 425 KB] en 2011. El resultado de este trabajo fue el Informe de Cuestiones Integradas (IIR) [PDF, 2.14 MB] (2012), en el cual se plantearon las siguientes dos cuestiones: (i) no hay una definición aceptada de TLD con variantes, y (ii) no hay mecanismos para "gestionar variantes" de TLD.

Con respecto a la primera cuestión, se desarrolló el Procedimiento de Reglas para la Generación de Etiquetas para la Zona Raíz (RZ-LGR) [PDF, 1.39 MB] con el apoyo de la comunidad. La Junta Directiva de la ICANN aprobó el procedimiento el 11 de abril de 2013 para que se proceda a su implementación. El procedimiento se implementó y se desarrollaron RZ-LGR para seis códigos de escritura. Se están incorporando más códigos de escritura a medida que las propuestas correspondientes son finalizadas por sus comunidades de usuarios. De esta manera, se cuenta con un mecanismo transparente y predecible para la futura identificación de etiquetas variantes.

En cuanto a la segunda cuestión, la organización de la ICANN realizó un estudio detallado para desarrollar una serie de recomendaciones en materia de mecanismos de gestión de variantes de TLD, las cuales se concretaron sobre la base de los aportes de la comunidad. A continuación, se presenta un resumen de las recomendaciones:

  1. Las RZ-LGR deben ser el único recurso para los TLD válidos y sus etiquetas variantes.
  2. Los TLD con variantes de IDN {t1, t1v1, …} se deben asignar a la misma entidad.
  3. Las etiquetas iguales bajo un TLD con variantes de IDN s1.{t1, t1v1, …} se deben registrar ante la misma entidad.
  4. Las etiquetas variantes en el segundo nivel de un TLD con variantes de IDN {s1, s1v1, …}.{t1, t1v1, …} se deben registrar ante la misma entidad.
  5. Se deben conciliar las tablas de IDN en el segundo nivel de un TLD con variantes de IDN.
  6. Las etiquetas variantes asignables o activadas dentro de los TLD con variantes de IDN no necesariamente son las mismas.
  7. Los TLD con variantes de IDN deben tener los mismos proveedores de servicios de registro.
  8. Las políticas vigentes y los procedimientos afines en materia de TLD se deben actualizar a fin de incorporar las recomendaciones para TLD con variantes de IDN.
  9. El resto de las políticas vigentes en materia de TLD debe ser aplicable a los TLD con variantes de IDN, salvo que se indique lo contrario.

Estos seis documentos, con sus recomendaciones y correspondiente análisis, se presentarán ante la Junta Directiva de la ICANN para su mayor consideración. La presentación está prevista para marzo de 2019.

Acerca de la ICANN

La misión de la ICANN es ayudar a garantizar una Internet global, unificada, estable y segura. Para contactar a otra persona en Internet, debemos ingresar una dirección –un nombre o un número– en nuestra computadora u otro dispositivo. Esa dirección debe ser única para que las computadoras puedan localizarse unas a otras. La ICANN ayuda a coordinar y brindar soporte a estos identificadores únicos en todo el mundo. La ICANN fue creada en 1998 como una corporación de bien público y sin fines de lucro, con una comunidad integrada por participantes de todo el mundo.


More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."