Documento Informativo de la
UIT:
Aspectos de Tecnología y Política
******
La
Unión Internacional de Telecomunicaciones (UIT) es una
organización internacional en la que los gobiernos y la industria
colaboran para coordinar el establecimiento y la explotación de redes
y servicios mundiales de telecomunicaciones; su cometido es la
normalización, la coordinación y el desarrollo de las
telecomunicaciones internacionales, incluidas las radiocomunicaciones
y la armonización de políticas nacionales.
En
el marco de su misión, la UIT adopta reglamentos y tratados
internacionales que rigen la utilización del espectro de frecuencias
radioeléctricas para servicios terrenales y espaciales, así como la
utilización de las órbitas de satélite, instrumentos éstos que
sirven para la legislación nacional de los diferentes países.
Asimismo, prepara normas para promover la interconexión de sistemas
de telecomunicaciones a escala mundial, independientemente del tipo de
tecnología utilizada, y promueve el desarrollo de las
telecomunicaciones en los países en desarrollo.
******
Unión
Internacional de Telecomunicaciones
Unidad de Políticas y Estrategias
Gabinete
del Secretario General
Place
des Nations
1211 Ginebra 20
Suiza
Tel. +41 22 730 5809
Fax +41 22 730 6453
spumail@itu.int
******
Agradecimientos
El
presente documento fue preparado por el Sr. Hirofumi Hotta, Director
de planificación de empresa de Japan Registry Service Co. Ltd. (hotta@jprs.jp),
en lo que respecta a la parte correspondiente a la UIT del Simposio
UIT/OMPI sobre Nombres de Dominio Plurilingües que se celebró los
días 6 y 7 de diciembre de 2001 en el Centro Internacional de
Conferencias de Ginebra (véase http://www.itu.int/mdns/).
También contribuyó de mantera importante al documento el Sr. Tan
Tin Wee, Vicepresidente del Multilingual Internet Names Consortium (MINC)
(tinwee@pobox.org.sg),
antiguo Presidente del Asia Pacific Networking Group (APNG), y del
Comité Ejecutivo de Asia Pacific Regional Internet Conference on
Operating Technologies (APRICOT).
También
contribuyeron y formularon comentarios varios editores internos y
externos, a quien damos las gracias. Se trata de Chinyong Chong,
Avita Dodoo, Ivo Essenberg, Daniel Pimienta, Jim Reid, James Seng y
Yoshihisa Takada. Joanna Goodrick supervisó la producción del
documento y lo editó.
Un
equipo de la Unidad de Estrategias y Política de la UIT, dirigido
por el Sr. Tim Kelly, organizó la parte correspondiente a la UIT
del simposio UIT/OMPI. Avita Dodoo, analista en políticas de
Internet, fue la Directora Global del proyecto bajo la supervisión
de Robert Shaw, asesor de la UIT en materia de estrategias y políticas
de Internet.
La
UIT agradece asimismo su contribución a MINC, que con sus
conocimientos y experiencia nos ayudó a preparar este simposio.
Gracias en particular a la Sra. YJ Park, Directora General de MINC,
al Sr. Tan Tin Wee, Vicepresidente de MINC, y al profesor Shigeki
Goto, Presidente de MINC.
Queremos
hacer constar asimismo nuestro agradecimiento al Ministerio de Gestión
Pública, Asuntos Interiores, Correos y Telecomunicaciones de Japón
por sus generosas contribuciones voluntarias al Programa Nuevas
Iniciativas de la UIT y su amable asistencia en la coordinación del
documento informativo.
Las
opiniones expresadas en el presente documento son las de sus autores
y no reflejan necesariamente la opinión de la UIT o de sus Miembros.
ÍNDICE
Introducción.
Demanda
de nombres de dominio plurilingües.
Historia
de la evolución de los nombres de dominio plurilingües.
Dificultades
técnicas de la creación de nombres de dominio plurilingües.
Aspectos
técnicos de la diversificación lingüística de los nombres de
dominio.
Conceptos
básicos del Grupo de Trabajo del IETF..
Códigos
de caracteres de los nombres de dominio plurilingües.
¿Lado
cliente o lado servidor?.
Normalización
para la compatibilidad con el DNS actual
Preparación
de nombres de huésped internacionalizados (Nameprep)
Codificación
compatible
ASCII (ACE)
Internacionalización
de nombres de huésped en aplicaciones (IDNA)
Consecuencias
para la estructura DNS.
Raíces
alternativas.
Solución
de nombres de dominio plurilingües mediante raíces alternativas.
Seudoraíces.
Cuestiones
de política y coordinación planteadas por los nombres de dominio
plurilingües.
Consideración
de nombres de dominio plurilingües en varios TLD..
Posibles
tipos de nombres de dominio plurilingües.
Cuestiones
técnicas y no técnicas.
Nombres
de dominio mixtos plurilingües ASCII
Nombres
de dominio plurilingüe.plurilingüe.
¿Qué
idiomas constituyen los nombres de dominio plurilingües?.
¿Cuál
es la autoridad lingüística de los nombres de dominio plurilingües?.
Estructura
de la autoridad.
Modelos
para la definición de la autoridad.
Resumen.
Anexo
A: Glosario de siglas.
Anexo
B: Utilizaciones de nombres de dominio plurilingües.
Chinese
Domain Name Consortium (CDNC)
China
Internet Network Information Center (CNNIC)
i-DNS.net
Japan
Network Information Center (JPNIC)/Japan Registry Services (JPRS)
Korea
Network Information Center (KRNIC)
NativeNames.
Neteka.
Netpia.
New.net
RealNames.
VeriSign
Global Registry Services (VGRS)
WALID..
1.
Los nombres de dominio se utilizan para identificar entidades
en Internet en un formato fácilmente comprensible por los seres
humanos; es uno de los sistemas de direccionamiento básicos de
Internet desde hace más de 15 años. Dicho de manera muy sencilla,
hace corresponder un nombre comprensible para los humanos, como "www.itu.int",
con una dirección de protocolo Internet (IP) legible por máquinas (por
ejemplo, 156.106.134.92). Actualmente, en los nombres de dominio sólo
se puede utilizar una serie limitada de caracteres ASCII,
es decir, letras, cifras y guiones. Al principio, la idea era disponer
de un sistema de identificadores fácilmente asimilables para ayudar a
los ingenieros de red a adjudicar direcciones a los ordenadores, y no
se consideró necesario en ese momento incluir caracteres no ASCII en
ese conjunto.
2.
Sin embargo, Internet se ha generalizado durante el último
decenio y ha experimentado un crecimiento espectacular gracias a
principios tecnológicos y económicos innovadores. La red telefónica
tardó 74 años en alcanzar la cifra de 50 millones de usuarios,
pero la World Wide Web tardó apenas 4 años en alcanzar esa misma
cifra. Actualmente, Internet es una red mundial que conecta a más de
230 economías y más de 350 millones de usuarios.
3.
Una de las consecuencias de este crecimiento es que todos los días
aumenta el número de usuarios y el contenido generado por sociedades
y culturas que no están familiarizados con los caracteres ASCII. En
vista de ello, diversos programas Internet admiten correos electrónicos
y páginas web en muchos caracteres e idiomas. Sin embargo, los
nombres de dominio, posiblemente uno de los símbolos más visibles de
Internet, todavía están redactados en caracteres ASCII y generan
notables barreras lingüísticas. Aunque los usuarios de idiomas
basados en caracteres latinos, ya sea originalmente (por ejemplo, el
español) o de manera transliterada (por ejemplo, el Malayo), no
tienen problemas lingüísticos con el sistema actual de nombres de
dominio, los que hablan árabe, chino, japonés, coreano, tamil, thai
y otros idiomas que no utilizan caracteres ASCII están desfavorecidos.
A fin de tratar de resolver este problema y de facilitar en general la
utilización de numerosos idiomas y caracteres, se ha emprendido la
"internacionalización" del sistema de nombres de dominio
(DNS, domain name system) de Internet.
4.
Desde 1998 han surgido varias soluciones técnicas a este
problema. Más de una docena de empresas comerciales y varios
administradores de dominios de nivel superior de código de país
(ccTLD) han encontrado diversas soluciones técnicas para los nombres
de dominios plurilingües. En el mercado comercial hay una intensa
competencia y no se destaca ningún claro vencedor con un sistema que
se convierta en la norma de facto.
5.
La demanda por parte de los consumidores ha sido muy fuerte,
particularmente en los países asiáticos. En 2000, se efectuaron en
el mundo varias pruebas de nombres de dominio plurilingües, pero la
mayoría de esas soluciones son técnicamente incompatibles entre sí.
Habida cuenta del problema, a principios de 2000 se creó en el Grupo
Especial sobre Ingeniería de Internet (IETF) un Grupo de Trabajo
sobre los nombres de dominio internacionalizados (IDN, internationalized
domain names) encargado de definir un planteamiento técnico y las
normas correspondientes.
6.
También es cada vez más evidente que el plurilingüismo del
DNS no es ni mucho menos un problema exclusivamente técnico, también
lo es administrativo y político. En 2001 aparecieron organizaciones
tales como el Multilingual Internet Names Consortium (MINC, Consorcio
de nombres Internet plurilingües), el Arabic Internet Names
Consortium (AINC, Consorcio de nombres Internet en árabe), el
Chinese Domain Names Consortium (CDNC, Consorcio de nombres de
dominio en chino), el International Forum for IT in Tamil (INFITT,
Foro internacional para las TI en tamil), y la Japanese Domain
Names Association (JDNA, Asociación de nombres de dominio en japonés),
así como otros grupos lingüísticos, a fin de colmar ese vacío político.
7.
Por otra parte, se han producido varias evoluciones importantes
en materia de administración y política, en lo que respecta a los
nombres de dominio convencionales basados en el código ASCII. En
octubre de 1998 se creó la Corporación de Asignación de Números y
Nombres Internet (ICANN), una corporación no lucrativa que se rige
por las leyes del Estado de California (EE.UU.).
El mes siguiente, el Departamento de Comercio de Estados Unidos y la
ICANN
firmaron un Memorándum de Entendimiento en cuyo marco la ICANN se
pronunció sobre la competencia en el mercado del registro de nombres
de dominio, una política uniforme en materia de solución de
controversias sobre los nombres de dominio (UDRP)
y, algunos nuevos dominios de nivel superior (TLD, top-level
domains).
8.
Más recientemente, en marzo de 2001, la ICANN inauguró
oficialmente varias actividades relacionadas con los nombres de
dominio plurilingües. En una encuesta realizada por un Grupo de
Trabajo interno de la ICANN
se observó la fuerte voluntad de que se utilicen rápidamente nombres
de dominio plurilingües.
9.
Con todo, todavía quedan por resolver numerosas dificultades e
incertidumbres con respecto a cuándo y cómo se utilizarán los
nombres de dominio plurilingües. En la fecha en que se preparaba el
presente documento informativo (noviembre de 2001), el Grupo de
Trabajo IDN del IETF no había alcanzado el consenso necesario para la
normalización técnica de los nombres de dominio plurilingües. De
los debates habidos al respecto se desprende que, incluso si el IETF
define una norma, no es evidente que se acepte universalmente. Tampoco
está claro que las nuevas tecnologías de denominación no basadas en
el DNS, tales como palabras clave (Keywords), acaben siendo la
solución preferida. Incluso cabe la posibilidad de que aparezcan
tecnologías híbridas que fusionen el DNS y las palabras clave. Una
de las consecuencias de esta situación es que los usuarios son presa
de una confusión considerable causada por la multiplicidad de
tecnología, instalaciones de sistemas de prueba y tecnologías
incompatibles.
10.
Por último, se deberá elaborar el modelo apropiado para la
asignación, la administración y la gestión de los dominios
plurilingües y, en particular, los dominios de nivel superior
plurilingües. La ICANN, que sólo ha abordado este problema
recientemente, no se ha pronunciado sobre una orientación clara de
los trabajos. En la práctica, los planteamientos nacionales o
regionales pueden ser muy diferentes en función de las
particularidades lingüísticas locales y quizá resulte difícil
determinar la autoridad responsable de lo que podrían considerarse
cuestiones nacionales, locales o regionales. Por otra parte, los
grupos lingüísticos han proliferado, lo cual exige otro nivel de
coordinación. Todo esto conduce a pensar que la creación de nombres
de dominio plurilingües podría plantear dificultades adicionales en
relación con los aspectos de tecnología, política y gestión del
DNS.
11.
Como Internet tuvo origen en Estados Unidos, no es sorprendente
que la tecnología haya evolucionado principalmente en inglés.
Incluso los que participaron en el desarrollo de Internet fuera de
Estados Unidos solían tener antecedentes técnicos y, por
consiguiente, estaban familiarizados con el inglés. Además, los códigos
ASCII se utilizan desde siempre en la informática e Internet,
especialmente al principio cuando los recursos como las unidades de
procesamiento centrales y la memoria eran limitados. A todo ello se
debe que incluso en los países en los que no se utilizan caracteres
ASCII en el idioma escrito se hayan utilizado esos caracteres para
acceder a servicios en Internet. Además, los primeros usuarios de
Internet eran investigadores y académicos y el inglés no planteaba
demasiadas dificultades para la progresión de Internet.
12.
Sin embargo, en los últimos años Internet se ha propagado en
todo el mundo y lo utilizan empresas y consumidores de todas las
edades y todos los medios culturales. Según las estimaciones, en 2003
las dos terceras partes de los usuarios de Internet no hablarán inglés.
Además, más del 90% de la población del planeta no es de idioma
materno inglés.
Esto significa que el inglés y el
alfabeto inglés dificultarán el acceso a Internet de un número
creciente de personas para los cuales ese idioma resulta muy poco
natural.
13.
Por consiguiente, aumenta la demanda de contenido Internet en
otros idiomas que el inglés, y seguirá aumentando. Poder utilizar
Internet en su propio idioma es muy importante para aprovecharlo al máximo.
Es una etapa más hacia la reducción de la "brecha
digital", expresión que se utiliza habitualmente para referirse
al ritmo de progresión desigual del acceso a las tecnologías de la
información y la comunicación.
14.
Conviene señalar que, además de los inconvenientes que
plantea la utilización de un alfabeto con el cual no están
familiarizados, las personas que no son de lengua materna inglesa
tienen a menudo problemas más complejos. Por ejemplo, el nombre japonés
"博文"
se traduce por "hirofumi" en caracteres latinos. En
Internet, en la cual sólo se utilizan caracteres ASCII, esa persona
se llama "hirofumi", como cualquier otro "hirofumi",
pero ese nombre puede escribirse de distintas maneras en japonés,
como "博史"
o "宏史".
En realidad, puede haber más de 100 representaciones diferentes en
japonés del nombre que acaba escribiéndose sencillamente "hirofumi"
en caracteres ASCII. Por consiguiente, en el mundo ASCII, la persona
que se llama "hirofumi" es como cualquier otro "hirofumi",
aunque al escribir su nombre en japonés se distingue claramente de
los demás.
15.
Este problema también se puede plantear, en menor medida,
cuando se utilizan idiomas latinos, por ejemplo en los nombres con apóstrofos,
acentos u otros caracteres diacríticos. Estos nombres tampoco se
pueden incluir con exactitud en los nombres de dominio, ya que éstos
están limitados a caracteres alfanuméricos latinos y al guión. En
otras palabras, esos nombres se han de adaptar a un espacio en el cual
se dispone de un juego de caracteres mucho más limitado.
16.
Con el tiempo, el contenido de Internet ha evolucionado
considerablemente y ya se utilizan idiomas distintos del inglés. Por
ejemplo, en el caso del correo electrónico, se han producido las
siguientes evoluciones:
·
Etapa 1: Utilización de un idioma
no inglés en los textos de correo electrónico mediante la trascripción
fonética del idioma en alfabeto inglés (transliteración).
·
Etapa 2: Utilización de caracteres
de otros idiomas en textos de correo electrónico.
·
Etapa 3: Utilización de caracteres
de otros idiomas en el campo "asunto" de los correos electrónicos.
¿Cuál
debería ser la próxima etapa? La evolución natural es que el nombre
del remitente y del destinatario de los correos electrónicos aparezca
en su idioma materno.
17.
Todas las máquinas conectadas a Internet reciben direcciones
de Protocolo Internet (IP) únicas, legibles por la máquina (por
ejemplo, 123.4.5.67 en el caso de la Versión 4 del IP). Las
direcciones IP son más fácilmente asimilables gracias al sistema de
nombres de dominio que atribuye una cadena de caracteres simple y fácilmente
memorizable, llamada nombre de dominio, a cada dirección IP. Dado el
número de servicios que aparecen en Internet, se ha vuelto necesario
tener en cuenta algo más que las máquinas. Por ejemplo, con el
correo electrónico nos dirigimos a usuarios de máquinas. En
la World Wide Web, buscamos la ubicación de documentos. Así
pues, para facilitar la comunicación, los objetos en Internet se
bautizan con localizadores uniformes de recursos (URL, uniform
resource locators) tales como http://www.itu.int/mdns/
o direcciones de correo electrónico como itumail@itu.int.
18.
Un nombre de dominio es una cadena de caracteres como "www.itu.int"
o "www.wipo.int",
que en este caso corresponden a ordenadores centrales de Internet.
Teniendo en cuenta que la justificación de los nombres de dominio es
que sean fácilmente memorizables y sustituyan a las direcciones IP,
es indudable que esta capacidad de memorización también se planteará
en otros idiomas, ya que forma parte de la vida cotidiana. Además,
aumentará la demanda de otras palabras importantes como nombres de
empresas y nombres personales. Todo ello significa que, en cierta
medida, los nombres han pasado de ser simples identificadores a
representar identidades de entidades. Actualmente, los nombres de
dominio se consideran equivalentes a nombres registrados, nombres de
productos y nombres de servicios. Desde un punto de vista técnico,
nos hemos apartado mucho del objetivo originalmente previsto.
19.
Además de los nombres de dominio, se pueden utilizar otros métodos
para bautizar entidades en Internet. Se trata, por ejemplo, de motores
de búsqueda y directorios, tales como el protocolo ligero de acceso
al directorio (LDAP, lightweight directory access protocol) y
el protocolo de resolución de nombres comunes (CNRP, common names
resolution protocol).
Sin embargo, sólo se han generalizado y se utilizan comúnmente los
nombres de dominio que, por consiguiente, siguen siendo el sistema de
denominación preferido de Internet.
20.
Las expresiones "nombres de dominio plurilingües" y
"nombres de dominio internacionalizados" se utilizan a
menudo como sinónimos, aunque los ingenieros y operadores de Internet
tienden a preferir "nombres de dominio internacionalizados".
Es posible que esta tendencia refleje su voluntad de evitar la semántica
de los lenguajes naturales en los nombres de dominio y de poder
utilizar sencillamente caracteres de todo el mundo en los nombres de
dominio. No obstante, en este documento se utilizará en general el término
"plurilingüe", salvo cuando "internacionalizado"
figure en un nombre propio.
21.
Uno de los primeros intentos para elaborar nombres de dominio
plurilingües se produjo en Asia a finales de los noventa. Estos
nombres se definieron en la Universidad Nacional de Singapur (NUS).
A continuación en julio de 1998, se creó un Grupo de Trabajo sobre
la internacionalización del DNS en el Asia Pacific Networking Group (APNG),
a fin de coordinar la evolución de los nombres de dominio plurilingües.
Uno de los proyectos del Grupo de Trabajo consistió en definir la
creación experimental de un servicio de nombres de dominio
internacionalizado, plurilingüe y multialfabeto (iDNS).
El Centro de Investigación de Internet de la NUS dirigió la primera
fase de este proyecto cuyo objetivo se podría formular de la manera
siguiente: "¿Por qué no deberían internacionalizarse también
los nombres de dominio si Internet ha llegado a casi todos los
rincones del planeta con idiomas diferentes?" Órganos públicos
y docentes y el sector industrial de China, Hong Kong, Japón, Corea,
Singapur, Taiwán y Tailandia, así como Bioinformatrix Pte. Ltd.,
junto con varias organizaciones interesadas en el idioma Tamil,
participaron en el proyecto. Otro proyecto, llamado iDomain
tenía por objeto la realización de un sistema de prueba iDNS en los
países de la región Asia‑Pacífico. Durante el periodo
1998/1999 se crearon varios sistemas de prueba en países de la región
Asia‑Pacífico con capacidad para admitir, entre otros, los
idiomas chino, japonés, coreano (Hangeul), Tamil y Thai.
22.
Posteriormente ese mismo año, se efectuó una demostración de
un DNS plurilingüe funcional en países asiáticos, que permitió
demostrar su viabilidad técnica. En agosto de 1998, en una reunión
del Foro Internacional sobre el Documento Blanco (IFWP, International
Forum on the White Paper)
en Singapur, se realizó una demostración de sistema de nombres de
dominio plurilingües a delegados internacionales que estaban
debatiendo la creación de una nueva Autoridad de Número Asignado por
Internet (IANA, Internet Assigned Numbers Authority),
que comprendían representantes de InterNIC
y del Grupo Especial sobre Ingeniería de Internet (IETF, Internet
Engineering Task Force).
A finales de 1998, varios países se declararon interesados por la
realización de un sistema de ese tipo, en particular, China, Hong
Kong, Japón, la República de Corea, Singapur y Tailandia. En varias
conferencias internacionales celebradas en 1999, tales como la
Conferencia Regional Asia‑Pacífico sobre tecnologías de
explotación (APRICOT, Asia Pacific Regional Conference on
Operational Technologies)
e INET 99,
varias reuniones de tipo "Birds of a Feather" (BoF) se
celebraron para debatir sobre nombres de dominio plurilingües.
23.
A continuación, en relación con los aspectos exclusivamente técnicos,
durante
la 46ª reunión del IETF de noviembre de 1999 se organizó una reunión
BoF sobre nombres de dominio plurilingües, cuyo objetivo era
determinar si el IETF debía definir normas técnicas relacionadas con
esos nombres de dominio. Después de esa reunión BoF se lanzaron
inmediatamente debates por correo electrónico. Tres meses después,
en una reunión del IETF en enero de 2000 comenzó a trabajar el Grupo
de Trabajo sobre nombres de dominio internacionalizados (IDN, Internationalized
Domain Name).
Desde esa fecha ha habido en el IETF intensos y activos debates sobre
la normalización, principalmente a través del correo electrónico y
en reuniones periódicas.
24.
En relación con la adopción del sistema, a finales de 1999
varias empresas (incluido un vástago comercial de la iniciativa iDNS
Asia‑Pacífico de la Universidad Nacional de Singapur, llamada i‑DNS.net
International Inc.)
comenzaron a comercializar la tecnología que habían creado. Se
realizaron rápidamente varias pruebas de nombres de dominio
internacionalizados y, en particular, una basada en la tecnología
i-DNS.net
(véanse los puntos 86 a 88 infra) y una propuesta por VeriSign
Global Registry Services (véanse los puntos 104 a 108 infra).
25.
El Consorcio sobre Nombres Internet Plurilingües (MINC, multilingual
internet names consortium)
es un actor mundial importante cuyas actividades no se limitan a la
instalación de sistemas. El MINC, creado en julio de 2000 y cuyos 39
miembros fundadores proceden del mundo entero, heredó varias
actividades del APNG. Se dedica principalmente a la promoción de la
diversificación lingüística de los nombres de Internet y, en
particular, los nombres de dominio y palabras clave Internet, la
internacionalización de las normas y los protocolos que rigen los
nombres de Internet, la coordinación técnica y la coordinación con
otros órganos internacionales. La idea es dar a todos los habitantes
del mundo las mejores oportunidades de éxito en el mundo de Internet,
en el cibercomercio y en el futuro de la era del conocimiento digital.
Además, organizaciones que corresponden a un idioma, país o región
trabajan activamente en la utilización de nombres de dominio
plurilingües. Se trata, entre otros, del AINC,
el CDNC,
el INFITT y la JDNA.
26.
En cuanto a los aspectos de política, la ICANN inició
oficialmente sus actividades relacionadas con los nombres de dominio
plurilingües en marzo de 2001. Consideró que la coordinación de políticas
era vital para la introducción de nombres de dominio plurilingües,
fuera cual fuese la norma tecnológica utilizada, y en una reunión
que celebró ese mismo mes, creó un grupo de trabajo IDN integrado
por cuatro miembros de su propia Junta. En esa reunión, el Comité
Asesor Gubernamental (GAC, Governmental Advisory Committee)
de la ICANN publicó un comunicado
en el cual se declaraba a favor en los nombres de dominio plurilingües.
El comunicado rezaba que "en lo que respecta a los nombres de
dominio internacionales (IDN), el GAC confirma la importancia y el
interés de esta evolución en beneficio de los usuarios de Internet
en todo el mundo". El pequeño grupo de trabajo de la ICANN
comenzó sus actividades con una encuesta sobre tres aspectos de los
nombres de dominio plurilingües, a saber: técnica, política y
servicios. Los resultados de la encuesta
se presentaron en un Informe a la reunión de septiembre de 2001 de la
ICANN. En el mismo se indicaba que había una gran demanda de nombres
de dominio plurilingües. Sobre la base de esos resultados, la Junta
de la ICANN decidió crear una comisión integrada por expertos de
varias especialidades cuya misión consistiría en formular
recomendaciones sobre asuntos de política no técnicos y, en
particular, el interfuncionamiento, la solución de ciberocupaciones
ilegales y controversias, dominios de nivel superior, protección del
consumidor y competencia.
27.
El espacio de nombres de dominio DNS tiene una estructura jerárquica
(véase la figura 1 infra) que se utiliza para identificar
entidades en Internet. Cada nodo de la estructura corresponde a una
entidad de Internet. El nombre que se da a un nodo de la estructura se
llama etiqueta de dominio. Todos los nodos reciben etiquetas con
excepción del nodo raíz que, como se ve en la parte superior de la
figura 1, no tiene etiqueta. El nombre de dominio de una entidad (nodo)
es una secuencia de etiquetas de nodo que van del propio nombre de
dominio a la raíz, en la cual las etiquetas están separadas por
puntos. La longitud de la etiqueta de dominio no debe ser superior a
63 octetos
y un nombre de dominio entero no debe tener una extensión superior a
255 octetos.
Figura
1
:
Estructura de los nombres de dominio
28.
En la figura 2 (infra) se indica cómo se identifica en
Internet una entidad a partir de su nombre de dominio. Cada nodo de la
estructura DNS se puede considerar como un cuadro, llamado servidor de
nombre, que mantiene pares de etiquetas de nodo directamente bajo el
nodo y las direcciones IP correspondientes. Los servidores de nombre
corresponden a organizaciones o unidades que están autorizados
a administrar el nombre de dominio correspondiente al nodo. Por
ejemplo, el servidor raíz es la fuente autorizada para los nombres .int
o .com; los servidores de nombre para .int son la fuente autorizada de
los nombres .itu.int y .wipo.int, y los servidores de nombre para .itu.int
están autorizados para www.itu.int. El DNS es, por consiguiente, en
realidad, una amplia base de datos distribuida en todo el mundo tanto
desde el punto de vista de la ingeniería como de la gestión.
Figura
2: ¿Cómo se resuelven los nombres de dominio?
29.
En lo que respecta a la relación entre los usuarios de
Internet y el DNS, los nombres de dominio se tratan como se indica en
la figura 3 (infra). Con los protocolos actuales limitados a
caracteres ASCII, los usuarios deberían limitarse a utilizar los
caracteres ASCII permitidos en las etiquetas de dominio. Esto
significa en realidad que los nombres de dominio ASCII se utilizarían
en todos los puntos, desde el usuario al sitio web. Sin embargo, con
la introducción de nombres de dominio plurilingües, el protocolo
entre el usuario y el ordenador personal no se basaría en caracteres
ASCII, mientras que el DNS actual sí se basa en esos caracteres.
Figura
3: ¿Dónde se reconocen los nombres de dominio plurilingües?
30.
Cuestiones técnicas fundamentales:
·
¿Cómo deben representarse los códigos
no ASCII?
·
¿Dónde se deben reconocer los códigos
no ASCII, en la aplicación cliente o en el servidor DNS?
·
¿Cuál es el mecanismo técnico
que hace corresponder los nombres de dominio plurilingües con la
tecnología DNS actual?
Los
conceptos básicos de la labor del IETF con respecto a este problema
se describen en los puntos 31 a 33 siguientes. La primera cuestión se
examina en los puntos 34 a 37, la segunda en los puntos 38 a 42 y la
tercera en los puntos 43 a 52.
31.
Como el DNS es una de las tecnologías fundamentales utilizadas
en Internet, la compatibilidad y el interfuncionamiento de nombres de
dominio plurilingües es esencial. Cualquier nueva tecnología debería
entrañar un número mínimo de cambios en Internet, coexistir con los
nombres de dominio actuales y permitir que un nombre designe de manera
coherente a la misma entidad en toda Internet. Para ello, es necesaria
una normalización apropiada y el respeto de las normas por los
sistemas de Internet. La normalización entraña la creación de un
protocolo común que promueva la interacción entre entidades dentro
de Internet; en el caso del DNS, es el IETF el que se encarga de ello.
32.
En enero de 2000, el IETF creó el Grupo de Trabajo IDN para la
normalización de la tecnología de los nombres de dominio plurilingües.
Su mandato se puede resumir como sigue:
·
El objetivo del grupo es
especificar las necesidades de acceso internacional a los nombres de
dominio y especificar un protocolo de seguimiento de normas con relación
a esas necesidades.
·
Un criterio fundamental de esta
labor es no perturbar en modo alguno la utilización y explotación
actual del sistema de nombres de dominio para resolver un nombre de
dominio.
·
El grupo no abordará la cuestión
del órgano, en su caso, que debería administrar o controlar la
utilización de nombres que recurran a esa funcionalidad.
33.
Al tratar la normalización de la tecnología de los nombres de
dominio plurilingües, la IAB (Internet Architecture Board)
definió las exigencias básicas siguientes:
·
RFC 2825: Mantenimiento de la
compatibilidad con los nombres de dominio actuales;
·
RFC 2826: Mantenimiento de la
exclusividad del espacio de nombres de dominio;
·
Internet no debe quedar dividida en
islas.
34.
En los nombres de dominio sólo se admiten las letras del
alfabeto latino básico (indistintamente mayúsculas y minúsculas, de
A a Z), las cifras decimales (0-9) y el guión (RFC 1034
y RFC 1035).
La adopción de nombres de dominio en varios idiomas obliga a adoptar
caracteres no ASCII. A fin de que las aplicaciones reconozcan sin
dificultades y traten los nombres de dominio plurilingües, la
codificación y las representaciones de esos caracteres no ASCII se ha
de determinar de forma unívoca. Para ello, conviene adoptar un código
común para los nombres de dominio plurilingües, a fin de que todas
las aplicaciones y los sistemas relacionados con los nombres de
dominio en toda Internet sean técnicamente compatibles.
35.
No obstante, por diversos motivos, muchos de los caracteres
utilizados actualmente en los sistemas de información corresponden a
normas nacionales o patentadas. Por ejemplo, el conjunto de caracteres
que más se utilizan en Japón se basa en las normas industriales
japonesas (JIS, japanese industrial standards) X 0208 y X 0201.
Por consiguiente, muchos ordenadores personales, asistentes digitales
personales y teléfonos móviles capaces de comunicar por Internet en
ese país sólo admiten caracteres JIS y ASCII, con el
consiguiente solapamiento de puntos de código y la imposibilidad de
definir de forma unívoca el tipo de codificación utilizado, lo cual
entraña problemas de compatibilidad.
36.
La solución más prometedora es la adopción del Unicode
(ISO/CEI 10646), que especifica los juegos de códigos de muchos
caracteres y, por consiguiente, idiomas. Aunque el Unicode sea quizá
la mejor solución actual, es probable que haya que perfeccionarlo
algo más para tener en cuenta la utilización real. Además, cuando
las aplicaciones no utilizan directamente el Unicode para la
representación de caracteres locales, será necesario efectuar la
conversión en ambos sentidos de los juegos de códigos comúnmente
utilizados a nivel local en algún punto de la cadena (por ejemplo, en
el caso del japonés, JIS).
37.
También cabe la posibilidad de que la simple adopción del
Unicode no convenga a los nombres de dominio. Por ejemplo, algunos
caracteres chinos tienen dos representaciones, un carácter
tradicional y un carácter simplificado. El hecho de que los
caracteres tradicionales no correspondan siempre con sus homólogos
simplificados complica mucho más la situación. Además, aunque se
utilizan habitualmente en China en lugar de los caracteres
tradicionales, los caracteres simplificados no se utilizan mucho en
Taiwán o en Hong Kong. Se ha planteado la cuestión de que estos dos
juegos de caracteres se puedan considerar o no como uno solo.
Se ha dicho que se deberían tratar como caracteres diferentes si los
nombres de dominio son simples identificadores. También se ha dicho
que deberían considerarse como los mismos caracteres si, en realidad,
los nombres de dominio corresponden a la identidad de las entidades.
Incluso si se consideran como los mismos caracteres, podría
plantearse la cuestión de si se trata meramente de una cuestión de código
local o de protocolo universal y si debería distinguirse entre esos
caracteres si se utilizan en el chino tradicional o simplificado.
38.
En lo que respecta al lugar en el cual se deben reconocer los códigos
no ASCII en la figura 3 de la página 15, las soluciones a este
problema se suelen basar en una de las posibilidades siguientes:
En
el lado cliente
39.
Si la solución está en el lado cliente, la traducción entre
el carácter plurilingüe y la representación compatible ASCII se
efectúa en las aplicaciones de usuario (por ejemplo, un navegador
web). La aplicación cliente traduce los caracteres plurilingües en
cadenas ASCII que, a continuación, se procesan en Internet, es decir
que los nombres de dominio se tratan a continuación como nombres de
dominio ASCII en toda Internet. En esta categoría se incluye también
el caso de una aplicación compuesta por un programa compartido entre
el lado cliente y el lado servidor pero, por motivos de comodidad, se
utiliza la expresión "lado cliente" en aras de la
coherencia con el Informe de la encuesta de la ICANN.
40.
Desde un punto de vista técnico, se necesita una solución en
el lado cliente, independientemente del planteamiento que se elija. Es
improbable que aplicaciones sólo ASCII funcionen inmediatamente con
nombres de dominio plurilingües. Será necesario actualizarlas de algún
modo, ya sea añadiendo caracteres, adoptando nuevos métodos de
introducción de la información o añadiendo funcionalidades técnicas
que admitan la internacionalización.
En
el lado servidor
41.
En este caso, la aplicación cliente envía por Internet los
nombres de dominio en su formato original codificado localmente, como
UTF-8,
GB o BIG5,
o Unicode. Los servicios y aplicaciones comunican entre sí mediante
nombres de dominio no ASCII a lo largo de todo el trayecto de
comunicación (a menudo llamado "en la línea"). Conviene señalar
que las primeras realizaciones de IDN eran en realidad soluciones de
servidor intermediario que interceptaban la codificación local de las
aplicaciones clientes y convertían la codificación en otra
compatible con ASCII a fin de que no debieran modificarse los
servidores DNS.
42.
Algunos de los servicios,
experimentos y pruebas actuales emplean soluciones en el lado cliente
y otros en el lado servidor. Hay un debate permanente entre los
expertos técnicos en relación con la viabilidad práctica de la
utilización de caracteres no ASCII
desde el principio en el DNS y sobre cómo interfuncionaría o
interferiría con otros protocolos Internet. Actualmente, el IETF se
está orientando hacia la normalización de una solución
exclusivamente en el lado cliente. Abogan en su favor los argumentos
siguientes:
·
En primer lugar, el DNS es una
inmensa base de datos, sólida y distribuida, pero que funciona sobre
la base de un delicado equilibrio. Demasiadas partes de los programas
y protocolos de Internet utilizan el DNS en su forma actual. De no
realizarse pruebas exhaustivas, la modificación del DNS a un nivel
tan fundamental podría conducir al colapso de todo el sistema y, por
ese motivo, muchos ingenieros especializados en Internet desaconsejan
modificar el núcleo del DNS, ya que podría tener consecuencias
catastróficas para Internet. Se considera que una solución en el
lado del cliente que no exija cambios notables del DNS sería mucho más
segura para la estabilidad y prosperidad de Internet.
·
En segundo lugar, teniendo en
cuenta el rápido aumento de la demanda, debería disponerse lo antes
posible de la posibilidad de utilizar nombres de dominio plurilingües.
En general, la instalación de servidores exigiría mucho más tiempo
que la de aplicaciones de cliente. En las soluciones en el lado del
cliente, sólo será necesario adaptar las entidades que tengan
intención de comunicar mediante nombres de dominio plurilingües para
que admitan ese tipo de nombres. Por el contrario, las soluciones en
el lado del servidor exigen que se preparen para los nombres de
dominio plurilingües todos los componentes de la ruta de comunicación
y, en particular, el cliente, el servidor y cualquier otro que se
encuentre entre los dos. La adopción de una solución en el lado del
servidor exigiría una nueva configuración de todos los servidores de
Internet para que admitieran caracteres plurilingües, y ello tomaría
un tiempo considerable.
·
En tercer lugar, dado el plazo
relativamente largo necesario para transformar los servidores, este
planteamiento podría limitar la adaptación de determinadas zonas de
Internet a los nombres de dominio plurilingües. Todo ello podría
entrañar la separación de Internet en "islas" y, quizá,
la aparición de raíces alternativas,
con la consiguiente confusión e incoherencia para los usuarios. El
GAC expresó su inquietud al respecto en un comunicado de marzo de
2001 en el cual apoyaba el concepto de los nombres de dominio
plurilingües y declaraba que "conservar las capacidades de
conexión y acceso universales en el sistema de nombres de dominio es
fundamental para que Internet siga siendo una red mundial".
43.
En la normalización técnica, lo ideal sería tener en cuenta
todos los idiomas y alfabetos que podrían utilizarse en los nombres
de dominio plurilingües. Sin embargo, muchas cuestiones relacionadas
con determinados idiomas sólo las pueden identificar los que utilizan
los idiomas y alfabetos en la práctica. Por consiguiente, la
normalización será evolutiva, ya que todos los aspectos no se pueden
identificar y resolver en una sola vez.
44.
El IETF trabaja actualmente sobre una normalización basada en
la solución en el lado del cliente descrita anteriormente. Se han de
normalizar, entre otros, los elementos técnicos siguientes:
·
preparación de nombres de huésped
internacionalizados (Nameprep);
·
codificación compatible ASCII
(ACE, ASCII compatible encoding);
·
internacionalización de nombres de
huésped en aplicaciones (IDNA, internationalizing host names in
applications).
45.
En Nameprep, las representaciones de múltiples cadenas
plurilingües, que técnicamente se deberían considerar como la misma
cadena, se combinan en una sola cadena. Después de Nameprep, ACE
convierte la representación plurilingüe en un nombre de dominio
ASCII apropiado. Los cometidos del Nameprep y ACE se indican en la
figura 4 (infra). La arquitectura del programa informativo
necesario para aplicar estas dos traducciones a los nombres de dominio
plurilingües originales a fin de que se incorporen de forma adecuada
en la Internet actual, se llama IDNA.
FIGURA
4: Funciones de Nameprep y ACE
46.
Las principales funciones de Nameprep son:
·
Plegado de caja - Como no hay
diferencia entre mayúsculas y minúsculas en la constitución de
nombres de dominio basados en ASCII, las cajas se fusionan o pliegan
en una sola forma. Esto es necesario para las letras ASCII y para las
que no lo son. Se pueden necesitar otros tipos de plegado de caja para
caracteres no ASCII. El plegado de caja también se llama "correspondencia"
porque hace corresponder uno o varios caracteres con otro u otros
caracteres que se considera o consideran equivalente. Las
especificaciones del plegado de caja se basan en el Informe Técnico
Unicode #21.
·
Normalización - Muchos caracteres
tienen varias representaciones incluso si el ojo humano no distingue
la diferencia. En los nombres de dominio, esos caracteres se han de normalizar
en una representación, a fin de que se consideren como el mismo carácter.
·
Por ejemplo:
o
las ligaduras "ä" y
"a +¨" son canónicamente equivalentes;
o
"A"
de anchura total y "A" de media anchura son equivalentes.
Las
especificaciones de la normalización se basan en el anexo a la norma
Unicode #15.
·
Prohibición - Muchos caracteres
del conjunto Unicode son secuencias de control, secuencias de
formatación o caracteres de separación, que no son apropiados y están
prohibidos en los nombres de dominio.
Lo
antedicho demuestra que Nameprep traduce varias representaciones que
se consideran como la misma cadena original en una sola representación
en el espacio de cadena plurilingüe. Si los resultados del Nameprep
son los mismos, las cadenas introducidas se consideran como el mismo
nombre de dominio. Si los resultados son diferentes, se consideran
como nombres de dominio diferentes. Para satisfacer esta necesidad,
Nameprep debe preceder a ACE. El IETF está acercándose a la conclusión
de la normalización de Nameprep.
47.
ACE codifica una cadena no ASCII representada en Unicode en una
cadena ASCII, conforme al formato de nombre de dominio ASCII existente.
De este modo, los nombres de dominio plurilingües se pueden tratar de
manera adecuada como los nombres de dominio ASCII correspondientes. En
la 49ª reunión del EITF de noviembre de 2000, se orientó al
Grupo de Trabajo IDN para que eligiera el ACE, aunque en los debates
por correo electrónico se presentaron argumentos sobre la necesidad
de utilizar en origen el UTF‑8. El IETF está alcanzando las
etapas finales de normalización de la ACE.
48.
RACE (Row-based ASCII Compatible Encoding)
fue uno de los primeros candidatos entre los algoritmos ACE propuestos.
Se utilizó en los servicios de registro y solución proporcionados
por, entre otros, VeriSign Global Registry Services (VGRS)
y Japan Network Information Center (JPNIC)/Japan
Registry Service (JPRS).
Después del RACE, ingenieros propusieron y evaluaron otros algoritmos
para determinar sus ventajas e inconvenientes en la utilización real
de nombres de dominio plurilingües registrados en varios sistemas de
prueba.
49.
En la reunión de agosto de 2001 del IETF, se apoyó
notablemente un sistema ACE llamado AMC-ACE-Z,
debido a su eficacia de compresión. Por ejemplo, AMC‑ACE‑Z
puede representar por lo menos 18 caracteres japoneses como una
etiqueta de dominio, mientras que el RACE puede representar hasta 17
de esos caracteres. Por ejemplo, las cadenas generadas en ASCII para
"日本語ドメイン名例.JP"
(que significa "ejemplo de nombre de dominio japonés"), dan
respectivamente los resultados siguientes en RACE y AMC-ACE-Z:
–
RACE:
BQ--3BS6KZZMRKPDBSJQ4EYKIMHTKQGU7CY
–
AMC-ACE-Z: ZQ--ECKWD4C7CU47R2WFQW7A0ECL32K
50.
La codificación ACE hace corresponder un espacio de nombres de
dominio plurilingües con un subespacio de nombres de dominio ASCII.
En el sentido contrario, utilizando el ACE debe ser posible hacer
corresponder de nuevo de manera unívoca un nombre de dominio ASCII
con un nombre de dominio plurilingüe. Por consiguiente, se debería
reservar un subespacio para nombres de dominio plurilingües en el
espacio de nombres de dominio ASCII existente, como se indica en la
figura 5 (infra). Para ello, se ha de definir un prefijo,
sufijo o "etiqueta" para una cadena ACE resultante. Todas
las cadenas con esa etiqueta ACE constituirán un subespacio que
define nombres de dominio plurilingües. La etiqueta ACE se ha de
elegir teniendo en cuenta las condiciones siguientes: debe haber una
posibilidad de 0 por ciento de que existan nombres de dominio ASCII
con ese prefijo o sufijo, y la longitud del prefijo o sufijo debe ser
lo más reducida posible para dejar el máximo espacio para los
nombres de dominio plurilingües. En esas condiciones, el prefijo o
sufijo debe ser una cadena simple como, por ejemplo, "??--",
o "--??", donde ? es un carácter alfanumérico. Por ejemplo,
si se elige el RACE, los nombres de dominio que comienzan con el
prefijo "bq--" indicarían un nombre de dominio plurilingüe.
Figura
5: Correspondencia entre el espacio de nombres de dominio plurilingüe
y el subespacio del espacio de dominio ASCII
51.
Si bien el ACE es prometedor, todavía se han de resolver
varias cuestiones. En primer lugar, los nombres de domino ASCII no
deberían registrarse en el subespacio reservado para los nombres de
dominio plurilingües. Por ejemplo, el registro de nombres de dominio
ASCII que comienzan por "bq--" debe bloquearse si se elige
el RACE. En segundo lugar, como la extensión de una etiqueta de
dominio no debe ser superior a 63 caracteres ASCII, sólo se admite un
número limitado de caracteres plurilingües, por ejemplo, 18
caracteres japoneses. Esto limita las etiquetas de dominio plurilingües
a extensiones inferiores a las etiquetas de domino ASCII. Además, no
se pueden obtener jerarquías de domino inferiores, ya que la longitud
de un nombre de domino completo no puede ser superior a 255 caracteres.
52.
Para utilizar Internet en su estado actual, las traducciones
por Nameprep y ACE se han de llevar a cabo antes de enviar el nombre
de dominio "por la línea" al DNS o al servidor de aplicación.
Esta arquitectura de aplicación en la cual Nameprep y ACE se llevan a
cabo de acuerdo con la correspondencia del código local con el
Unicode se llama IDNA, como se indica en la figura 6 (infra).
En la reunión de agosto de 2001 del IETF, muchos de los
presentes apoyaron la solución IDNA en el lado del cliente.
Figura
6: Arquitectura de IDNA
53.
Un requisito básico del DNS es su capacidad para identificar
entidades en Internet. Para ello, la estructura del espacio de nombres
de dominio jerárquico debe estar coordinada administrativamente. La
ICANN se encarga actualmente de esta coordinación, con la supervisión
final del Departamento de Comercio de EE.UU..
Esto significa que la autoridad de la raíz jerárquica DNS indicada
en la figura 1 de la página 13 reside generalmente en la ICANN.
Esta raíz se llama a veces raíz autorizada.
54.
En un número creciente de soluciones informáticas se ofrecen
actualmente los llamados sistemas de raíz alternativa. Éstos
comprenden el DNS público y lo amplían ofreciendo dominios de nivel
superior adicionales, lo cual permite a los usurarios de Internet
visualizar más nombres de dominio que los reconocidos por la ICANN.
De no haber una especie de coordinación administrativa mundial de los
dominios de nivel superior,
se podría producir una fragmentación de Internet en espacios de
nombre dispares.
55.
Habida cuenta de lo antedicho, la ICANN publicó recientemente
documentos de opinión
en los cuales argumentaba la necesidad de una raíz DNS pública
autorizada única, que debería administrarse como un fondo público,
y afirmaba que la ICANN ha asumido este cometido de fe pública. Los
expertos técnicos convienen en general en que es necesario un solo
espacio de nombres público a fin de mantener la integridad y las
posibilidades de conexión mundial del DNS. Conviene citar al respecto
una declaración conexa de la Internet Architecture Board (IAB), que
se recoge en RFC 2826:
"Para
seguir siendo una red mundial, Internet necesita un espacio mundial único
de nombres públicos. El espacio de nombres DNS es un espacio nominal
jerárquico derivado de una raíz mundial única. Es una limitación técnica
inherente al diseño del DNS. Por consiguiente, no es técnicamente
viable que haya más de una raíz en el DNS público. Esa raíz debe
ser admitida por una serie de servidores raíz coordinados
administrados por una autoridad de denominación única."
56.
Si bien los argumentos se basan en diversas perspectivas y en
intereses económicos divergentes, parece haber un consenso general
sobre la necesidad de que el espacio de nombres DNS sea visible para
el mayor número posible de usuarios de Internet: un espacio de
nombres demasiado fragmentado no es útil para nadie. Prueba de ello
es que los administradores de dominios de nivel superior "no
sancionados" en sistemas raíz alternativos han pedido a) su
inclusión en la "raíz autorizada" y b) que la ICANN no
introduzca TLD idénticos a sus TLD utilizados en raíces alternativas.
También aducen que es posible disponer de una función raíz
administrativamente coordinada que evite conflictos entre dominios de
nivel superior diferentes basados en varios sistemas raíz. Por
consiguiente, el debate es más bien sobre quién es la raíz
o la autoridad de denominación coordinadora, que sobre las
ventajas de un espacio de denominación coordinado único.
57.
Las especificaciones normalizadas actuales no admiten nombres
de dominio plurilingües. La adopción de dominios plurilingües con
tecnologías patentadas podría propiciar la aparición de raíces
alternativas. Desde el punto de vista del usuario, un nombre de
dominio podría referirse a entidades completamente diferentes en
espacios nominales diferentes y estructuras raíz diferentes. En
particular, dado que la introducción de nuevos dominios de nivel
superior es un proceso sumamente largo, se trata de determinar si el
mercado prescindirá sencillamente de los acuerdos administrativos
actuales
58.
Uno de los argumentos aducidos por los que proponen raíces
alternativas para solucionar el problema de los nombres de dominio
plurilingües es que la autoridad de la ICANN se deriva principalmente
de Estados Unidos, ya que ese país se considera desde siempre la cuna
de los nombres de domino Internet basados en el código ASCII. Algunos
dicen que, dado que los nombres de dominio plurilingües se originaron
fuera de Estados Unidos, las raíces alternativas que admiten dominios
de nivel superior plurilingües podrían ser más aceptables de lo que
se pretende. Otros apoyan el concepto de una raíz "inclusiva"
que permitiría utilizar a nivel nacional o comercial dominios de
nivel superior que no están bajo la autoridad de la ICANN. En este
caso, mientras los usuarios dirijan sus aplicaciones a la raíz
inclusiva, podrán resolver nombres de dominio de la ICANN y de otro
tipo que les darán acceso directo a nuevos dominios de nivel superior
plurilingües. Algunos consideran que este modelo también plantea
problemas en la medida en que más de una entidad podría aducir que
gestiona la "raíz inclusiva". Esto podría conducir a
incompatibilidades de espacios de nombres que deberían resolverse
mediante negociaciones, arbitraje o, incluso, juicios. En el peor de
los casos, podría conducir a la fragmentación del espacio de nombres
de Internet prevista por la IAB en RFC 2826.
59.
Queda la posibilidad algo más sutil de crear un espacio de
nombres de dominio plurilingües. Se trata de crear un "dominio
de nivel superior no ASCII imaginario" en el espacio de nombres
de dominio autorizado. Este método, llamado dominio de nivel cero,
ya fue sugerido en 1997 en proyectos de documentos del IETF. Oculta la
parte superior del espacio de nombres de dominio, suponiendo que un
nodo superior del espacio no oculto es un dominio de nivel superior
virtual, y utilizando el subespacio regido por el dominio de nivel
superior virtual como el espacio de nombre de dominio entero. Por
ejemplo, después de crear un espacio {cadena no ASCII}. TLD en el
dominio de nivel superior autorizado, los usuarios ".TLD"
pueden acceder a Internet utilizando nombres de dominio como
xxx.{cadena no ASCII} si la aplicación cliente de los usuarios separa
y/o une ".TLD" automáticamente en cada acceso a Internet.
De este modo se obtiene un dominio de nivel superior plurilingüe
(virtual) para los usuarios de esas aplicaciones cliente. A pesar de
que los dominios de nivel cero sean algo más aceptables que las raíces
alternativas, los usuarios deben ser conscientes de que entidades
diferentes podrían designarse aparentemente con el mismo nombre de
dominio si se utilizan aplicaciones cliente diferentes.
60.
No son los nombres de dominio plurilingües los que de por sí
conducen a la creación de raíces alternativas o de seudoraíces. Más
bien al contrario, se trata de la combinación de intereses
comerciales y de la demanda privada de rápida creación de nuevos TLD,
ya sean en inglés o en otros idiomas. Si las políticas de creación
de nuevos TLD pueden satisfacer la demanda privada y comercial, se
limitará considerablemente el riesgo de fragmentación. Puede decirse,
pues, que es muy importante que la ICANN halle métodos para
satisfacer eficazmente esta demanda.
61.
La tecnología siempre es el comienzo de un proceso, no el
final. Para aprovechar plenamente una tecnología se necesita el apoyo
de los sectores político y comercial. En este apartado se examinan
las principales cuestiones de política relacionadas con los nombres
de dominio plurilingües.
62.
En el actual DNS basado en ASCII hay dos tipos de dominios de
nivel superior: los dominios de nivel superior genéricos (gTLD) tales
como .com y .info, y los dominios de nivel superior de código de país
(ccTLD), tales como .uk y .jp. Hay menos de 15 gTLD, en su mayoría
controlados por la ICANN. Hay actualmente unos 245 ccTLD,
en su mayoría controlados por una organización de gestión de ccTLD,
normalmente en los respectivos países o regiones.
63.
Podrían aparecer varios tipos de nombres del dominio plurilingües,
en función del tipo de TLD que representen o del cual dependan. Los
nombres de dominio plurilingües podrían escribirse en el mismo
idioma, el mismo alfabeto, o en varios idiomas y alfabetos. Podrían
representarse como sigue:
·
{cadena no ASCII}.{ccTLD ASCII};
·
{cadena no ASCII}.{gTLD ASCII};
·
{cualquier cadena}.{ccTLD no
ASCII};
·
{cualquier cadena}.{gTLD no ASCII}.
64.
Esta notación no se define formalmente aquí, ya que basta con
una idea de los principios subyacentes. Además, podrían aparecer
otros tipos de TLD plurilingües tales como, por ejemplo, TLD en
distintos idiomas que indiquen el idioma de los nombres de dominio
asociados: {cadena china}.{CHINO} o {cadena japonesa}.{JAPONÉS},
donde "CHINO" y "JAPONÉS" representan el nombre
del idioma en caracteres chino o japonés.
65.
Si bien la mayoría de las dificultades que plantea la
utilización de estos nombres de dominio plurilingües no son técnicas,
una posible dificultad técnica es la sobrecarga del DNS. Esto se debe
a que una {cadena no ASCII} es inhabitualmente larga cuando se
codifica a un formato ACE. Otra dificultad técnica es, entre otras,
la necesidad de que sean plurilingües los sistemas conexos tales como
el Whois, una aplicación que presenta los atributos asociados
de los nombres de dominio (por ejemplo, información sobre el que lo
ha registrado). También hay obstáculos no técnicos tales como, por
ejemplo:
·
responsabilidad del registro de
nombres de dominio;
·
cuestiones que se han de resolver
en el proceso de registro y utilización.
El
segundo de estos obstáculos se examinará más adelante en el
documento. El primero se describe en este punto con una clasificación
de los temas sobre la base del tipo de dominios de nivel superior de
que se trate.
66.
Varias organizaciones ya trabajan con nombres de tipo {cadena
no ASCII}.{ccTLD ASCII} y {cadena no ASCII}.{gTLD ASCII}. Por ejemplo,
el VGRS registra
{cadena china}.com y JPNIC/JPRS propone {cadena japonesa}.jp. Estos
servicios se proporcionan a condición de que la organización en
cuestión tenga "autoridad" sobre un ccTDL o gTLD y, si el
DNS está internacionalizado, que la autoridad sea suficiente para
delegar nombres de dominio plurilingües {no ASCII}.{ASCII} en el TLD
correspondiente.
67.
Un ejemplo de {ccDLD no ASCII} es ".日本"
("日本"
representa "Japón" en Kanji japonés). Si un {ccTLD no
ASCII} y su organización de gestión son coordinados por la ICANN, es
probable que no planteen problemas las decisiones de la autoridad,
siempre y cuando no haya controversias sobre qué organización es la
autoridad legítima. Por consiguiente, en el caso del japonés, dado
que la cuna del idioma es Japón y que ningún otro país ha designado
al japonés como idioma oficial, esa decisión parece evidente. Sin
embargo, conviene señalar que los caracteres japoneses “日本”
también se utilizan en chino y se
escriben de manera idéntica. Estos caracteres en particular también
podrían no designarse como un TLD chino y asignarse a otra organización.
El japonés también utiliza otros dos conjuntos de caracteres, a
saber, Katakana e Hiragana, pero como ningún otro país utiliza esos
caracteres, es poco probable que planteen complicaciones.
68.
En lo que respecta a los demás idiomas, los problemas serán
mucho más complejos. Si un país o región correspondiente a un código
de país tiene dos o varios idiomas oficiales, es probable que deba
tomar una decisión sobre el idioma que se utilizará para representar
a su "código" de país {ccTLD no ASCII}, suponiendo que el
"código de país" tenga un equivalente en ese idioma.
Incluso si se define la regla de que dos o varios {ccTLD no ASCII} se
pueden asignar a un país o región, se trata de determinar el número
de {ccTLD no ASCII} que se han de asignar al país o región en función
de los idiomas oficiales o utilizados en esa jurisdicción. Por
ejemplo, en la India se hablan comúnmente más de 20 idiomas que se
escriben de manera diferente.
69.
Un ejemplo de {gTLD no ASCII} es .企業"
("企業"
es una cadena de caracteres chinos tradicionales que significa "una
empresa"). El problema es que muchos idiomas pueden compartir
caracteres y, por consiguiente, cadenas idénticas pueden tener
significados idénticos o diferentes en varios idiomas. Asimismo,
idiomas diferentes tienen caracteres similares. Por ejemplo, China y
Japón utilizan la palabra "企業",
y no se puede distinguir si el dominio de nivel superior "企業"
está en chino o japonés. En otras palabras los nombres de dominio
plurilingües pueden resultar confusos a pesar del objetivo declarado
de que los nombres de domino sean más fáciles de recordar. Es muy
difícil decidir a quién se ha de designar para administrar este tipo
de dominios de nivel superior (y en qué país). Dadas las
dificultades que plantea la simple introducción de nuevos dominios de
nivel superior ASCII, es fácil imaginar las dificultades que planteará
la introducción de dominios de nivel superior plurilingües.
70.
Una de las cuestiones que se ha de abordar es la definición de
los idiomas desde el punto de vista de los nombres de dominio
plurilingües. Algunos idiomas tienen dos o varios tipos de caracteres,
y algunos otros mezclan caracteres diferentes en el idioma escrito.
Por ejemplo, los documentos escritos en japonés mezclan caracteres
Han chinos, Katakana e Hiragana japoneses, números arábigos y el
alfabeto inglés. En este caso, ¿pueden ser nombres de dominio
plurilingües todas las cadenas de caracteres de un documento escrito
en japonés? ¿En qué idioma están los caracteres Han chinos cuando
se utilizan como nombres de dominio plurilingües en un documento en
japonés?
71.
Además, deberán examinarse reglas locales como la unificación
de los caracteres chinos tradicionales y los caracteres chinos
simplificados, como se describe en el punto 37, incluso desde la
perspectiva de "si son el mismo idioma o idiomas diferentes".
Por ejemplo, ¿afectaría el "plegado" (véase el punto 46)
de los caracteres Han chinos tradicionales y simplificados la
utilización de caracteres Han en otros idiomas que el chino?
72.
También se ha de determinar si las cuestiones descritas en los
puntos 70 y 71 son locales o internacionales. A fin de suprimir los
riegos de confusión para los usuarios, algunos proponen que las
reglas que rijan los nombres de dominio plurilingües sean las mismas
incluso si se refieren a dominios de nivel superior diferentes. Por
consiguiente, un registrador
de un solo nombre de dominio no debería
ser la autoridad suprema en lo que respecta a las reglas relativas a
los nombres de dominio plurilingües. Por ejemplo, ¿deben regirse por
las mismas reglas la representación y la conversión de los nombres
de dominios chinos en .com y .cn?
En este ejemplo, la definición de las reglas para los nombres de
dominio plurilingües chinos sería de por sí un asunto internacional.
Sin embargo, ¿sería capaz la comunidad internacional que no utiliza
el chino de definir las cuestiones de localización para los
chinoparlantes? Por otra parte, teniendo en cuenta la diáspora china
y que ese idioma se utiliza en jurisdicciones, países y economías
diferentes, ¿hasta qué punto se han de adoptar esas decisiones a
nivel local?
73.
Es muy difícil o incluso imposible que los que no hablan estos
idiomas comprendan lo que está en juego. Es muy difícil comprender
si los temas tratados en los puntos 70 y 71 son problemas de código o
de protocolo, pero es necesario comprenderlos para llegar a una decisión
aceptable sobre el grado de normalización internacional de estas
cuestiones. Alguien debe determinar cuáles son las problemáticas y cómo
se han de resolver. Quizá una primera etapa pragmática consista en
determinar cuál es la autoridad decisoria pertinente más probable.
74.
Por ahora, hay diversas combinaciones de países/economías,
idiomas, alfabetos y sistemas de codificación, y en el cuadro 1 se
dan varios ejemplos. En el cuadro se considera improbable que el método
de "un sistema para todos" tenga éxito.
Cuadro
1
|
Caracteres
|
Idioma
|
Codificación
|
País/Economía
|
Comentarios
sobre el modelo administrativo
|
|
Chino
Tradicional
y
Simplificado
|
Chino
|
GB
BIG5
HW
|
China,
Hong Kong,
Taiwán,
Macao,
Malasia,
Singapur,
EE.UU.,
Canadá,
Reino
Unido, etc.
|
Idioma
diaspórico
Idioma
oficial de varias economías
Chinese
Domain Name Consortium (CDNC)?
|
|
Hiragana
Katakana
Kanji
|
Japonés
|
JIS
SJIS
EUCS
|
Japón
|
>90%
de hablantes en Japón
JDNA/JPRS/JPNIC
son candidatos evidentes
El
Kanji necesita coordinación con países que utilizan los
caracteres CJK
|
|
Hangeul
|
Coreano
|
KSC
|
República
Popular de Corea (Sur)
República
Democrática Popular de Corea (Norte)
|
>80%
de hablantes en ambas Coreas
KRNIC
es un posible candidato
Hanji
se ha de coordinar con los países que utilizan caracteres CJK
|
|
Árabe
|
Árabe
Urdu
Farsi
Jawi
|
|
Argelia,
Bahrein,
Djibouti,
Dubai,
Egipto,
Francia,
Jordania,
India, Irak,
Irán,
Kuwait,
Líbano,
Libia,
Marruecos,
Malasia,
Mauritania,
Omán,
Palestina,
Pakistán,
Qatar,
Arabia Saudita,
España,
Somalia,
Sudán,
Siria,
Túnez,
Turquía,
EAU,
Yemen
y
otros
|
Idioma
diaspórico
Idioma
oficial de varios países
Arabic
Internet Names Consortium (AINC)
Arabic
Languages WG, MINC
Urdu
Language WG, MINC
|
|
Tamil
|
Tamil
|
TAM
TAB
TSCII
Muchos
otros caracteres patentados
|
India
(Estado Tamil de Nadu), Mauricio,
Sri
Lanka,
Malasia,
Singapur,
EE.UU.
Canadá,
Reino Unido,
etc.
|
Idioma
diaspórico
minoritario
en todos los países
Idioma
oficial en unos pocos
El
Estado Tamil de Nadu en la India se reconoce como la cuna del
idioma Tamil
International
Forum for IT in Tamil (INFITT) Working Group WG02
|
|
Thai
|
Thai
|
TSC
|
Tailandia
|
>90%
de hablantes en Tailandia
|
|
Khmer
|
Khmer
|
Muchos
caracteres registrados
|
Reino
de Camboya
Tailandia
(Surin)
Viet
Nam
|
>90%
de hablantes en Camboya
Idioma
Oficial en un país
|
|
Lao
|
Lao
|
Varios
caracteres registrados
|
RDP
Lao
Tailandia
|
10
veces más hablantes en Tailandia
|
|
Cirílico
|
Ruso
|
|
Rusia
y unas doce repúblicas de la antigua URSS
|
>90%
en Rusia
Rusia
está reconocida como la cuna del ruso
|
|
Hebreo
|
Hebreo
|
|
Israel
|
>95%
en Israel
|
75.
Del cuadro anterior se desprende que es importante la
coordinación lingüística. En caso necesario, organizaciones
regionales o internacionales podrían constituir foros apropiados. En
general, como principio de base y siempre que sea posible, parece
conveniente que sean los propios hablantes los que tomen las
decisiones que afectan a su idioma. En el cuadro 2 se sugieren varios
de los modelos que se podrían examinar.
Cuadro
2
|
Modelo
|
Idioma
|
|
Un
idioma - un alfabeto - un país
|
Hebreo,
thai, ruso
|
|
Un
idioma - un alfabeto - ningún país
|
Tamil
|
|
Un
idioma - un alfabeto - muchos países
|
Árabe,
lao
|
|
Un
idioma - muchos alfabetos - muchos países
|
Sistema
árabe-urdu-farsi-jawi, Han
|
|
Un
idioma - muchos alfabetos - un país
|
Japonés,
coreano
|
|
Un
idioma - muchos alfabetos - muchos países
|
Chino
(tradicional-simplificado), urdu (árabe-hindú)
|
|
Un
país - muchos alfabetos - muchos idiomas
|
Muchos
países
|
Resumen
76.
Para que se puedan utilizar plenamente los nombres de dominio
plurilingües en Internet, la normalización técnica no será sino la
punta del iceberg. Para atender las necesidades de los usuarios, también
se habrán de seguir las etapas siguientes:
·
normalización tecnológica;
·
política y coordinación de reglas
de registro y gestión;
·
instalación de servidores de
aplicaciones y de nombre.
La
relación entre esas etapas, necesarias para empezar a utilizar
nombres de dominio plurilingües, se ilustra a continuación en la
figura 7.
Figura
7: Base del aumento del número de nombres de dominio plurilingües
77.
En lo que respecta a la normalización técnica, de acuerdo con
las fechas propuestas por el Grupo de Trabajo IDN se ha previsto
terminar en el primer semestre de 2002 la normalización de Nameprep,
ACE y de IDNA (véanse los puntos 43 a 52). Sin embargo, como todavía
se han de examinar todos los idiomas del mundo, las especificaciones
de la norma deberán ser evolutivas. Además, como el propio DNS está
evolucionando, podrían aparecer a plazo más largo soluciones tales
como las basadas en servidores o en capas de programa adicionales (por
ejemplo, palabras clave) que podrían ofrecer soluciones más
interesantes.
78.
Se han de resolver muy rápidamente las cuestiones de política
y coordinación planteadas en los puntos 61 a 75, pero gracias a la
cooperación nacional, regional e internacional se pueden encontrar
soluciones.
79.
La instalación de servidores de aplicaciones y de nombre debe
apoyarse en la dinámica del sector comercial. Para obtener una
utilización satisfactoria, es importante promover la instalación de
servidores y aplicaciones. Es fundamental fomentar y promover
ampliamente el desarrollo de aplicaciones. Un ejemplo práctico de
ello es la Japanese Domain Names Association (JDNA), creada en julio
de 2001, que tiene miembros instalados en Japón tales como vendedores
de aplicaciones, proveedores de servicios de red y registradores de
nombres de dominio. En la JDNA, se pueden determinar especificaciones
necesarias a nivel local tales como la representación detallada de
las URL y las direcciones de correo electrónico.
80.
En resumen, hay una demanda considerable de nombres de dominio
plurilingües por parte del mercado y de los usuarios. Para atender
esta demanda, todo el entorno debe evolucionar para tener en cuenta la
normalización tecnológica, los acuerdos políticos y administrativos
y las nuevas aplicaciones. El futuro de los nombres Internet plurilingües
es inminente. No debemos subestimar la importancia de esta actividad,
ya que forma parte de un objetivo mucho más noble: la
internacionalización progresiva de Internet.
Anexo
A: Glosario de siglas
|
ACE
|
Codificación
compatible ASCII
|
|
AINC
|
Arabic
Internet Names Consortium
|
|
AMC-ACE-Z
|
Adam
M. Costello-ASCII Compatible Encoding-Z (versión 26)
|
|
APNG
|
Asia
Pacific Networking Group
|
|
APRICOT
|
Conferencia
Regional Asia-Pacífico sobre Tecnologías de Explotación
|
|
ASCII
|
American
Standard Code for Information Interchange
|
|
BoF
|
Reunión
"Birds of a Feather"
|
|
ccTLD
|
Dominio
de nivel superior de código de país
|
|
CDNC
|
Chinese
Domain Name Consortium
|
|
CNNIC
|
China
Internet Network Information Center
|
|
CNRP
|
Protocolo
de resolución de nombres comunes
|
|
DNS
|
Sistema
de nombres de dominio
|
|
GAC
|
Comité
asesor gubernamental
|
|
gTLD
|
Dominio
de nivel superior genérico
|
|
HKNIC
|
Hong
Kong Network Information Center
|
|
HTTP
|
Hypertext
Text Transfer Protocol
|
|
IAB
|
Internet
Architecture Board
|
|
IANA
|
Internet
Assigned Numbers Authority, parte de la ICANN
|
|
IC
|
Código
de identificación
|
|
ICANN
|
Corporación
de Asignación de Números y Nombres Internet
|
|
IDN
|
Nombre
de dominio internacionalizado
|
|
IDNA
|
Nombres
huésped internacionalizados en aplicaciones
|
|
iDNS
|
Servicio
de nombres de dominio internacionalizados
|
|
IETF
|
Grupo
Especial sobre Ingeniería de Internet
|
|
IFWP
|
International
Forum on the White Paper
|
|
INET
|
Conexiones
Internet
|
|
INFITT
|
International
Forum for IT in Tamil
|
|
IP
|
Protocolo
Internet
|
|
ISOC
|
Internet
Society
|
|
UIT
|
Unión
Internacional de Telecomunicaciones
|
|
JDNA
|
Japanese
Domain Names Association
|
|
JIS
|
Norma
industrial japonesa (japanese industrial standard)
|
|
JPNIC
|
Japan
Network Information Center
|
|
JPRS
|
Servicio
de registro japonés (Japan register service)
|
|
KRNIC
|
Korea
Network Information Center
|
|
LDAP
|
Protocolo
ligero de acceso al protocolo
|
|
LDH
|
Sistema
de letras-cifras-guiones sin distinción de mayúsculas y minúsculas
utilizado en el DNS
|
|
MPHPT
|
Ministerio
de gestión pública, asuntos internos, correos y
telecomunicaciones
|
|
MINC
|
Multilingual
Internet Names Consortium
|
|
MONIC
|
Macau
Network Information Center
|
|
MoU
|
Memorándum
de Entendimiento
|
|
NIC
|
Centro
de información de red (network information centre)
|
|
NUS
|
National
University of Singapore
|
|
PC
|
Ordenador
personal
|
|
RACE
|
Codificación
compatible ASCII basada en líneas
|
|
TLD
|
Dominio
de nivel superior (top level domain)
|
|
TWNIC
|
Taiwan
Network Information Center
|
|
UDRP
|
Política
uniforme de solución de controversias
|
|
URL
|
Localizador
uniforme de recursos (uniform resource locator)
|
|
VGRS
|
VeriSign
Global Registry Services
|
|
WIPO
|
Organización
Mundial de la Propiedad Intelectual
|
******
Anexo
B: Utilizaciones de nombres de dominio plurilingües
81.
La demanda del mercado a menudo no espera disponer de las
soluciones técnicamente perfectas y a ello se debe que ya se utilicen
nombres de dominio plurilingües. Actualmente, se depende principalmente
de tecnología patentada o de especificaciones de normas incompletas.
Sin embargo, muchos proveedores de soluciones han declarado que cumplirán
las futuras normas cuando éstas estén terminadas. A continuación se
indican por orden alfabético algunas de las utilizaciones conocidas en
el mercado. Como muchos proveedores de soluciones de nombres de dominio
plurilingües utilizan tecnologías de palabra clave de Internet para
servicios de resolución, también se enumeran las empresas que trabajan
en este campo. En la mayoría de los casos, la información proviene del
proveedor de la solución. Como este sector evoluciona muy rápidamente,
esta lista es, por definición, incompleta. Se solicita información
adicional o aclaraciones sobre las soluciones ofrecidas en el mercado.
82.
El 19 de mayo de 2000, cuatro centros de información de redes (NIC,
network information centers) situados cerca del estrecho de
Formosa, a saber, el China Internet Network Information Center (CNNIC),
el Taiwan Network Information Center (TWNIC), el Hong Kong Network
Information Center (HKNIC) y el Macau Network Information Center (MONIC),
crearon en Beijing el Chinese domain name consortium (CDNC). Esta
organización independiente no lucrativa se ocupará principalmente de
la coordinación y reglamentación en todo el mundo de los nombres de
dominio en chino. Como los nombres de dominio en lengua nacional son
cada vez más importantes en China, muchas organizaciones y empresas se
han interesado en el tema y están participando activamente en las
actividades de investigación y la popularización de los nombres de
dominio en chino. Sin embargo, por falta de comunicación y coordinación
entre ellas, hay muchos planteamientos y tecnologías diferentes para el
sistema de nombres de dominio en chino, lo cual retrasaría
considerablemente su difusión. Para evitar esos problemas, los cuatro
NIC propusieron y, finalmente crearon el CDNC, que mejorará la
coordinación y la cooperación sobre los nombres de dominio en chino.
83.
El CDNC evaluará todas las cuestiones de resolución de nombres
de dominio en chino, respetando escrupulosamente los criterios
internacionales, y elaborará las normas técnicas para los nombres de
dominio en ese idioma y los reglamentos correspondientes para su
registro. También coordina su utilización en los demás países o
regiones, y comunica y coopera con todas las organizaciones
internacionales pertinentes a fin de poder elaborar normas
internacionales en un futuro próximo.
84.
El CNNIC
registra nombres de dominio en chino de prueba por medio de soluciones técnicas
basadas en los requisitos técnicos de los nombres de dominio
internacionalizados y las necesidades de los usuarios de nombres de
dominio en chino.
85.
La resolución se lleva a cabo en el "lado servidor"
con reenvío de HTTP. También se proporcionan palabras clave a los
clientes para la resolución.
86.
i-DNS.net
es un proveedor de soluciones de nombres de dominio internacionalizados
(IDN, Internationalized Domain Name) y registrador de nombres de
dominio {carácter nativo}.{carácter nativo}. Los dominios de nivel
superior genéricos (gTLD) admitidos por IDNS.net son versiones en
idioma local de .com, .net y .org, seleccionados en consulta con los
centros de información de red (NIC) locales y expertos lingüísticos
de los países.
87.
Todos los nombres registrados y contenidos en la base de datos de
registro de i‑DNS.net son compatibles con el DNS existente y gozan
de una delegación completa y total en el mismo. Estos nombres se pueden
resolver globalmente con numerosos métodos de resolución y, en
particular, el popular programa iClient, un módulo de extensión para
la resolución en el lado cliente, basado en Windows.
88.
Las propuestas de IDN de i-DNS.net son conformes a las
recomendaciones y normas promulgadas por el Grupo de Trabajo IDN del
Grupo Especial sobre Ingeniería de Internet (IETF), es decir, en el
lado cliente, preparadas para Nameprepped y basadas en ACE. A través de
su registrador y sus asociados estratégicos, i-DNS.net ha lanzado sus
servicios de registro en todo el mundo en más de 30 idiomas.
89.
JPNIC/JPRS
ofrece servicios de registro y resolución para nombres de dominio en
japonés
con una solución en el lado cliente que utiliza casi la misma tecnología
que VGRS (véanse los puntos 104 a 108 siguientes). JPNIC/JPRS acepta
nombres de dominio plurilingües en caracteres japoneses en su dominio
ccTLD.jp y factura el mismo importe por el registro de nombres de
dominio plurilingües que por el de nombres de dominio ASCII.
90.
Ofrece las siguientes funciones:
·
Utiliza RACE (y próximamente ACE-AMC-Z)
para codificar nombres de dominio en japonés en cadenas ASCII.
·
Pone las cadenas ASCII en los
servidores de nombre DNS ordinarios como nombres de dominio.
·
Proporciona paquetes de desarrollo
para aplicaciones como los navegadores web para que éstos puedan
referirse al DNS con nombres de dominio en japonés.
·
Se han registrado y se pueden
utilizar más de 60 000 nombres de dominio. Además, se utiliza la
tecnología de resolución de palabra clave RealNames, de modo similar a
VGRS.
·
Antes de efectuar el registro por
orden cronológico de recepción de las solicitudes, JPNIC/JPRS adoptó
varias medidas preventivas como el bloqueo de prefijo, palabras
reservadas y un periodo de espera a fin de evitar los problemas
relacionados con la propiedad intelectual y los fracasos iniciales.
91.
El KRNIC
ha comenzado registros experimentales de {cadena en coreano}.test.kr y {cadena
en coreano}.실험.kr
entre el 16 de marzo de 2001 y el 25 de abril de 2001 a fin de probar la
viabilidad de la utilización de nombres de dominio en Hangeul.
92.
KRNIC tomó las disposiciones siguientes con respecto a los
servicios:
·
utilización de BIND 8.2.3 con
algunas modificaciones;
·
telecarga de ficheros de zona en
formato EUC-KR, UTF-8 y RACE;
·
respuesta a preguntas con direcciones
IP directamente;
·
definición de varias normas en RFC-KR
tales como dominios de segundo nivel;
·
elaboración de varias normas
adicionales en RFC-KR;
·
comienzo de pruebas de TLD plurilingües;
·
desarrollo de Nameprep para
caracteres coreanos.
KRNIC
realizará pruebas adicionales y decidirá cuándo comenzar el registro
oficial de nombres de dominio en Hangeul.
93.
NativeNames
ofrece equivalentes en árabe, farsi, urdu y cirílico de los gTLD .com,
.net y .org, existentes, y ofrece asimismo el equivalente de nuevos TLD
en esos idiomas.
Según Pyramid Research, NativeNames es el líder de un mercado rápidamente
creciente del DNS internacionalizado en los países árabes del Oriente
Medio,
y la "presencia creciente de nombres de dominio en caracteres arábigos
fomentará la difusión de Internet en todo el Oriente Medio y el norte
de África".
94.
Neteka
no es un registro ni un registrador
propiamente dicho, pero proporciona una solución para nombres de
dominio plurilingües que consiste en una combinación de soluciones en
el lado servidor y en el lado cliente. Esta solución permite el
registro de
{cadena no-ASCII}.gTLD, {cadena no-ASCII }.ccTLD, y {cadena no-ASCII }.SLD,
donde SLD significa dominio de segundo nivel (second level domain).
95.
Netpia es un proveedor de servicios de palabra clave Internet. La
base del servicio de palabra clave Internet de Netpia es que se puede
acceder a sitios web en el propio idioma sin tener que recordar el
complicado nombre de dominio en inglés.
96.
El nombre de palabra clave de Internet plurilingüe (multilingual
Internet keyword name) es un sistema de nombres de dominio de la próxima
generación, una solución patentada elaborada por Netpia.com en 1997.
La principal ventaja del nuevo sistema es que admite el sistema de
dirección Internet actual (DNS) y el sistema de reconocimiento
plurilingüe (MSS, multilingual scan system). Esta versatilidad
constituye un nuevo paradigma en el entorno de Internet rápidamente
cambiante. Las barreras tradicionales entre países están cayendo rápidamente
gracias a la revolución digital y Netpia proyecta extender sus
actividades de dominios Internet plurilingües y basados en palabras
clave a otros países en los cuales el inglés no es un idioma oficial y
que ofrecerán nuevas oportunidades comerciales a la empresa.
97.
Netpia normalizará en principio contraseñas Internet plurilingües.
Según vayan apareciendo ccTLD en idiomas nativos también aparecerán
ccTLD de palabra clave Internet. Por consiguiente, ya no se necesitarán
.kr, .jp y .cn para navegar por Internet. La idea de Netpia es que se
pueda navegar por la web en el idioma materno localizando el sistema de
dirección de Internet.
98.
New.net es un registro y registrador de nombres de dominio
basados en el mercado que explota nombres de dominio más significativos
y descriptivos en diversos idiomas. En 8 meses, New.net ha creado
una red voluntaria de 73 millones de usuario de Internet que pueden
acceder a nombres de dominio y resolverlos en 6 idiomas diferentes.
New.net ha creado 30 extensiones en inglés tales como .shop, .family,
.mp3 y .club, y extensiones traducidas para las comunidades de habla
española, portuguesa, francesa, italiana y alemana, tales como .tienda,
.reise y .amor.
99.
A fin de que los usuarios puedan acceder a esos nombres de
dominio, New.net crea asociaciones con proveedores de servicio Internet
(PSI) que efectúan pequeños cambios de su programa de servidor de
nombres. Todos los clientes del PSI asociados con New.net pueden ver
entonces los nombres de dominio de New.net. Para los que no se conectan
a Internet a través de un PSI asociado a New.net hay un pequeño módulo
de extensión telecargable para los ordenadores personales.
100.
New.net publicará durante el primer trimestre de 2002 una solución
IDNA conforme a las normas editadas por el Grupo de Trabajo IDN del
Grupo Especial sobre Ingeniería de Internet para la resolución de
nombres de dominio IDN.IDN. New.net también se encargará de los
registros y de la acreditación de registradores para fomentar el
registro y utilización de esos nombres de dominio.
101.
La intención de New.net es "seguir trabajando con el DNS
existente para ofrecer soluciones prácticas de dominación de Internet
a los usuarios de todo el mundo. Se trata, en particular, de investigar
soluciones en el lado servidor a plazo más largo para la cuestión de
la resolución de IDN".
102.
RealNames Corporation es un proveedor de infraestructura mundial
de palabras clave, una plataforma superior de denominación y navegación
web que mejora el sistema de nombres de dominio existente. Las palabras
clave sustituyen a los URL complicados por nombres y marcas sencillos y
trabajan en el idioma nativo del consumidor, lo cual facilita la
utilización de Internet. RealNames, fundado en 1996, tiene su sede en
Redwood City (California, EE.UU.) y oficinas en Londres, Tokio y Seúl.
103.
El servicio de resolución de palabras clave de RealNames
funciona en todos los dispositivos que trabajan con Internet, y con
muchos servicios y aplicaciones. Ha sido integrado en el navegador
Internet Explorer de Microsoft y en la cabecera de acceso móvil de
Openwave Systems, así como en importantes sitios de búsqueda y
portales.
104.
VGRS
propone actualmente un sistema de prueba de nombres de dominios
internacionalizados (IDN, internationalized domain name) que
ofrece servicios de registro y resolución de nombres de dominio
plurilingües mediante la utilización de una solución en el lado
cliente. En la prueba de VGRS, sólo está internacionalizado el dominio
de nivel secundario; el dominio en idioma nativo va seguido por los TLD
autorizados por la ICANN, a saber, .com, .net o .org, y se crea un
nombre de dominio en lenguaje mixto. VGRS acepta más de 39 caracteres
Unicode para los IDN. Factura el mismo importe para el registro de
nombres de dominio plurilingües que para el de nombres de dominio
ASCII, aunque recientemente todos los registros de IDN efectuados
durante el primer año de la prueba se extendieron sin costo adicional
para un periodo adicional de 6 meses.
105.
En el sistema de prueba IDN del VGRS se utiliza la codificación
compatible ASCII (ACE) propuesta actualmente por el Grupo de Trabajo IDN
del IETF para codificar los IDN en cadenas ASCII. La ACE original
utilizada era la codificación compatible ASCII basada en líneas (RACE)
y recientemente la ACE-AMC-Z (Z). Los IDN todavía no se han introducido
en las zonas .com, .net y .org; la resolución se ha efectuado al tercer
nivel. Casi un millón de nombres de dominio han sido registrados. Además,
se emplea la tecnología de palabras clave de RealNames que permite a
los usuarios del navegador Internet Explorer de Microsoft acceder a
sitios web con URL que contienen nombres de dominio plurilingües.
106.
El IETF publicó el proyecto del algoritmo RACE en marzo de 2000.
VGRS lanzó el servicio de registro de prueba de nombres de dominio
internacionalizados basado en el RACE en noviembre de 2000. Antes del
lanzamiento del servicio de registro, se codificaron algunos nombres de
dominio plurilingües en nombres de dominio ASCII que comenzaban por
"bq--" y se registraron como nombres de dominio ASCII. La
consecuencia fue que se registraron nombres de dominio ASCII que
correspondían a la versión RACE de los IDN antes de que comenzara el
servicio de registro, lo cual quiere decir que se bloqueó el registro
IDN correspondiente. Recientemente, para tener en cuenta el cambio del
RACE a Z, el prefijo se sustituyó por "zq--".
107.
En el futuro, se prevé que se propondrá un algoritmo ACE
definitivo como norma con un nuevo prefijo. Todos los prefijos de cuatro
caracteres no utilizados que terminen con dos guiones han quedado
reservados para .com, .net y .org y se elimina así el problema
planteado por los nombres RACE al principio de la prueba.
108.
Desde el principio de la prueba, VGRS se comprometió a cooperar
en el proceso de elaboración de normas y mantiene ese compromiso.
Cuando se proponga una norma se aplicará y la prueba terminará.
Entretanto, a fin de reducir al mínimo los múltiples trabajos de
conversión de los registradores IDN, éstos siguen sometiendo registros
IDN en formato RACE y VGRS se los convierte a nombres en formato Z.
109.
WALID
ofrece un servicio de registro {cadena no ASCII}.{cadena no ASCII} junto
con un programa informático de cliente para resolver los nombres de
dominio plurilingües registrados. La tecnología WALID se basa en la
recomendación IDNA/ACE apoyada por el Grupo de Trabajo IDN del IETF, y
admite todos los idiomas basados en el Unicode para el registro y la
resolución. WALID propone asimismo soluciones totalmente adaptables con
capacidades plurilingües para registros y registradores de todo el
mundo. La tecnología WALID forma parte de la prueba plurilingüe de
VeriSign (véanse los puntos 104 a 108 anteriores).
******
|