Resumen

  • RFC 3743 convirtió determinadas variantes de caracteres chinos, japoneses y coreanos en un paquete administrativo vinculado a un titular único.
  • Las variantes preferidas normalmente se activaban en la zona; otras quedaban reservadas sin convertirse necesariamente en nombres DNS activos. El documento no prueba que un registro concreto adoptara una tabla ni que un nombre resuelva.

El nombre que era más grande que la etiqueta visible

Registrar un nombre de dominio suele parecer una operación sobre una sola cadena: si está libre, se asigna y puede publicarse. Los nombres internacionalizados complicaron esa idea. En chino, japonés y coreano, distintos puntos de código pueden parecer iguales, compartir una interpretación o tratarse como variantes dentro de una lengua o región. El DNS compara etiquetas codificadas; por sí solo no decide cuándo dos formas Unicode deben corresponder al mismo titular.

Ese límite administrativo es el asunto de RFC 3743, publicado como documento Informational en abril de 2004 por el Joint Engineering Team (JET). Entre sus participantes había representantes de comunidades de información de red de China, Taiwán, Corea y Japón. La nota del IESG elogió que JET conectara una política con un mecanismo de aplicación, pero dejó claro que el IETF no ordenaba una política de zona. Una tabla común podía servir a decisiones locales distintas.

No se trata de convertir Unicode a la forma ASCII compatible con el DNS. Los documentos IDNA anteriores especificaron preparación y codificación. RFC 3743 se ocupó de la administración de formas que una zona puede considerar relacionadas: varias etiquetas no deberían terminar en manos distintas si la política local las agrupa. Un perfil técnico puede comprobar si una cadena es válida; no puede resolver todas las ideas de equivalencia de las comunidades lingüísticas.

La tabla convierte una política lingüística en un proceso

La Language Variant Table (LVT) define, por cada lengua permitida, puntos de código válidos y sus posibles variantes preferidas y de carácter. Son categorías de administración; no representan una clasificación universal de escrituras ni garantizan que cada combinación generada sea una palabra corriente.

Al registrar, primero se procesa la etiqueta solicitada mediante Nameprep, conforme al IDNA de aquella época. Después se valida frente a la tabla de cada lengua asociada a la solicitud. El proceso genera combinaciones de variantes, quita duplicados y compara las candidatas con etiquetas ya registradas o reservadas. La zona puede filtrar formas que no quiera incluir. Unicode no decide estas reglas: las aportan la tabla y los procedimientos locales.

La diferencia importante es entre activar y reservar. La etiqueta de entrada y, normalmente, sus variantes preferidas admisibles se activan y aparecen en el archivo de zona. Las variantes de carácter quedan por lo general reservadas: no puede registrarlas otro solicitante, pero no necesariamente se publican como etiquetas activas. RFC 3743 denomina «IDL Package» al conjunto de la etiqueta original, las lenguas asociadas, las variantes activadas y las reservadas.

El paquete cambia la unidad administrativa. En el modelo tradicional, cada etiqueta se registra, transfiere o elimina por separado. Aquí el paquete es atómico: transferir o eliminar el IDL afecta al conjunto de variantes relacionado. Así se evita que dos titulares obtengan formas que la zona decidió vincular. También implica que una transacción puede abarcar etiquetas que nunca aparecen en el DNS activo.

Los ejemplos del RFC muestran por qué importa la lengua asociada. Una etiqueta puede ser válida en varias tablas y generar formas preferidas distintas; también puede rechazarse si un carácter no es válido en una de las lenguas elegidas. Son ejemplos del algoritmo, no pruebas de que un registro identificado adoptara esa tabla ni de que un dominio comercial se inscribiera de ese modo.

Lo que la reserva no demuestra

RFC 3743 deja a cada zona decisiones clave: tablas, lenguas, conflictos, límites a la cantidad de variantes y reparto de trabajo entre registrador y registro. Algunos ejemplos parten de «primero en llegar, primero en ser atendido», pero el texto permite sustituir esa regla por la política local de derechos o disputas. El RFC no prueba quién posee legalmente un nombre, que un paquete se haya activado, que una etiqueta ASCII se insertara en una zona ni que una consulta DNS tenga éxito.

Los documentos IDNA2008 posteriores ayudan a separar capas: fijan validez y comportamiento técnico, y reconocen que los registros pueden imponer restricciones locales. Esa continuidad no convierte los algoritmos de la época IDNA2003 de RFC 3743 en reglas de protocolo actuales ni hace universal la tabla de JET. Validar, aplicar política de registro, registrar, publicar en zona y resolver son resultados diferentes.

El aporte histórico fue una arquitectura administrativa. JET no intentó codificar toda equivalencia CJK dentro del DNS. Dio a las zonas un mecanismo para expresar sus propias decisiones y vincular variantes a un mismo titular. Eso reduce un tipo de fragmentación entre titulares, pero crea otra dependencia: la tabla lingüística y las reglas de ciclo de vida pasan a formar parte del objeto que se recibe. El nombre visible puede ser una etiqueta; el conjunto reservado es mayor.

Fuentes