Resumen
- RFC 3490 mantuvo DNS en ASCII y ejecutó IDNA dentro de las aplicaciones.
ToASCIIpodía rechazar una etiqueta;ToUnicodeno fallaba y, ante cualquier error, devolvía la entrada original. - Por eso una cadena visible no demostraba validez, aceptación registral, inserción en zona, resolución, autenticación DNSSEC ni control. Eran comprobaciones distintas.
Una interfaz necesita mostrar algo incluso cuando no puede interpretar lo que recibe. RFC 3490 convirtió esa necesidad práctica en una regla precisa: ToUnicode nunca fallaba. Si alguna etapa no se podía completar, la operación devolvía inmediatamente la secuencia original. El usuario conservaba un objeto visible. El protocolo no declaraba válido ese objeto.
La diferencia era central para la arquitectura de 2003. IDNA no pedía cambiar servidores DNS, resolutores ni mensajes en la red. Era una cuña dentro de la aplicación. Hacia la persona admitía Unicode; hacia los componentes heredados emitía ASCII. El sistema internacionalizó la experiencia en el borde sin convertir al DNS en un intérprete de lenguas.
La norma delimitó ese borde mediante el concepto de «ranura de nombre de dominio»: QNAME, un argumento de resolución, el dominio de una dirección de correo o el host de un URI. Una mención en texto libre no era una ranura. El contexto de uso, no la mera apariencia, determinaba qué reglas se aplicaban.
En dirección al DNS, ToASCII era una operación con derecho a decir no. Procesaba cada etiqueta por separado. Para datos no ASCII ejecutaba Nameprep, podía exigir las reglas tradicionales de letras, dígitos y guion, impedía que una secuencia no ASCII empezara con el prefijo reservado, aplicaba Punycode, añadía xn-- y comprobaba una longitud final de uno a 63 puntos de código. Si fallaba un paso, fallaba la operación. Si fallaba una etiqueta, el nombre completo no debía usarse como IDN.
La dirección de presentación tenía un objetivo distinto. ToUnicode reconocía el prefijo ACE, lo retiraba, decodificaba Punycode y guardaba el resultado. Después aplicaba ToASCII a esa forma Unicode. Solo si la representación reconstruida coincidía con la entrada ASCII guardada, comparada sin distinguir mayúsculas, devolvía la forma decodificada. La vuelta completa era la prueba de equivalencia.
Si la prueba no cerraba, la operación no inventaba una equivalencia ni ocultaba el dato: devolvía el original. RFC 3490 añadía una señal útil. Si, tras ToUnicode, la etiqueta seguía empezando por el prefijo ACE, no era una ACE válida ni equivalía a las formas Unicode intermedias. El resultado pertenecía al camino de visualización, no al de aceptación.
De ahí surge una cadena de recibos. Poder representar una secuencia no prueba que pase ToASCII. Superar ToASCII no obliga a un registro a aceptarla. La aceptación no prueba que ya esté insertada en una zona. Una respuesta DNS puede incluso venir de un comodín. DNSSEC autentica datos asociados al nombre ASCII firmado, no el significado que una persona atribuye a la forma Unicode. Y ninguna de esas etapas demuestra por sí sola quién controla o merece el nombre.
La propia RFC limitó su ambición lingüística. DNS continuaba siendo coincidencia exacta. Caracteres de apariencia semejante, grafías alternativas, chino simplificado y tradicional o equivalencias propias de una lengua no se volvían automáticamente iguales. Las zonas podían imponer políticas adicionales. IDNA ofrecía transporte interoperable, no una autoridad mundial sobre identidad y lenguaje.
La revisión de 2006 en RFC 4690 mostró el coste de mezclar esas capas: caracteres confundibles, políticas registrales, evolución de Unicode y transiciones no cabían en una sola función. En 2010, RFC 5890 y RFC 5891 reorganizaron IDNA alrededor de A-label y U-label y separaron explícitamente registro y consulta. El registro podía exigir coincidencia exacta y rechazar la solicitud; la consulta, aunque más tolerante, seguía validando. Comparar con éxito no implicaba validez.
RFC 5895 situó las transformaciones de interfaz como decisiones locales previas. Ahí aparece el vínculo con la especificación inicial mínima de Heng Lu: el acuerdo global define el paso indispensable, mientras que la lengua, la presentación y la política permanecen donde existe contexto para decidirlas. La coordinación no necesita apropiarse de toda la realidad que conecta.
RFC 3490 quedó obsoleta como mecanismo completo, pero su asimetría conserva valor histórico. Una función total puede proteger la continuidad de una interfaz precisamente porque no convierte cada retorno en aprobación. ToUnicode daba una representación. ToASCII decidía si había una representación admisible para el canal heredado. Registro, zona, respuesta e identidad seguían esperando pruebas propias.
Fuentes
- RFC 3490
- Texto de RFC 3490
- Ficha del RFC Editor
- Ficha del IETF Datatracker
- Historia en IETF
- Erratas de RFC 3490
- RFC 3491
- RFC 3492
- RFC 3454
- RFC 1034
- RFC 1035
- RFC 4690
- RFC 5890
- RFC 5891
- RFC 5892
- RFC 5893
- RFC 5894
- RFC 5895
- Repositorio IANA de prácticas IDN
- Heng Lu sobre la especificación inicial mínima
- Heng Lu sobre las capas de realidad
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
