Resumen

  • La RFC 3987 dio cabida formal a los identificadores internacionales de recursos (IRI), capaces de contener Unicode, junto a programas que procesan URI. La conversión depende del componente: un host que sea un nombre de dominio puede requerir IDNA; los caracteres Unicode de una ruta o una consulta se representan mediante UTF-8 y codificación porcentual.
  • La RFC 3987 nombra a Martin J. Dürst y Michel Suignard como autores; el CV universitario de Dürst lo considera autor principal de la especificación IRI. El estándar conecta escrituras legibles con software anterior, pero no registra nombres, acredita el control de un dominio ni demuestra que dos cadenas visualmente parecidas identifiquen el mismo recurso.

Seguir la entrada antes de mirar el destino

Imaginemos una dirección web con caracteres japoneses en la ruta y un host escrito en otro alfabeto. Una persona puede verla como una única dirección. Un cliente, en cambio, debe separar esquema, autoridad, ruta, consulta y quizá fragmento. Cada componente encuentra después reglas diferentes. La forma legible y la que recibe un componente que solo acepta URI pueden estar relacionadas sin coincidir carácter por carácter.

Esa es la función de los Internationalized Resource Identifiers, o IRI. La RFC 3986 define la sintaxis general de los identificadores uniformes de recursos (URI), cuyo repertorio de caracteres se limita a un subconjunto de ASCII. Publicada en enero de 2005, la RFC 3987 añade un elemento compatible con Unicode en vez de cambiar de manera silenciosa la definición anterior. Sus autores explican que crear un elemento nuevo preservaba la distinción y evitaba incompatibilidades con el software existente.

Un componente que admita IRI puede conservarlos; cuando el proceso de recuperación solo acepta URI, el IRI debe transformarse en su forma URI correspondiente.

El estándar no prometía que todo componente de red antiguo pasaría a entender cualquier escritura. Su propuesta era de interoperabilidad: mantener una secuencia más amplia donde el software puede procesarla y definir el cruce hacia una interfaz más limitada cuando haga falta. Esto importa porque un identificador puede guardarse, mostrarse, copiarse o servir para recuperar un recurso. No es necesario que esas acciones ocurran en el mismo componente ni en el mismo momento.

El host es solo uno de los componentes

La separación más importante aparece después de //, en la autoridad de una dirección web. Si el host es un nombre de dominio de tipo DNS, la conversión de la RFC 3987 de 2005 aplica la operación ToASCII de IDNA a cada etiqueta separada por puntos. El resultado es una forma compatible con ASCII que pueden procesar programas basados en URI. El ejemplo de la propia RFC transforma el host résumé.example.org en xn--rsum-bpad.example.org.

El ejemplo aclara qué hace Punycode y qué no. Codifica una etiqueta de dominio en una forma compatible con ASCII; no transforma toda la URL ni debe usarse para cada componente no ASCII. El prefijo xn-- tampoco certifica nada por sí solo: la RFC 5890 distingue una etiqueta A válida conforme a IDNA de una cadena que apenas tiene una apariencia similar. La validez depende de la comprobación del protocolo, no de la forma visible.

Las generaciones de estándares también deben mantenerse separadas. Para convertir el host, la RFC 3987 cita la RFC 3490, el protocolo IDNA de 2003. El marco posterior IDNA2008, incluidas las RFC 5890 y 5891, actualizó la terminología y las reglas del protocolo. La RFC 5895, de carácter informativo, describe transformaciones que una aplicación puede aplicar a la entrada antes del protocolo IDNA2008. Reconoce que esa adaptación puede depender del idioma, la aplicación y el método de entrada. Por eso, el ejemplo de la RFC 3987 pertenece al contexto de 2005; no garantiza que todos los navegadores actuales apliquen una transformación universal.

Una ruta no es una etiqueta de dominio

Si esos caracteres aparecen en la ruta, cambia el tratamiento. Un segmento como /研究 puede representarse en la URI como /%E7%A0%94%E7%A9%B6, con sus octetos UTF-8 codificados en porcentajes. Punycode no es el algoritmo de la ruta. Esta puede interpretarla un servidor web, un marco de aplicaciones, un almacén de archivos o un enrutador específico; DNS no resuelve cada segmento.

La consulta y el fragmento también tienen semánticas propias. El signo de porcentaje, la barra, la interrogación o la almohadilla pueden ser delimitadores y no datos corrientes, de modo que importan el análisis y el orden de escape. La RFC 3987 conserva la sintaxis de los componentes URI mientras amplía los caracteres que pueden aparecer directamente en un IRI. Su conversión no consiste en “reemplazar cada carácter Unicode por una grafía ASCII”. El esquema y el componente determinan la operación adecuada.

Por eso la norma recomienda retrasar la conversión hasta llegar a un componente que no pueda manejar IRI. Convertir demasiado pronto puede eliminar la forma legible antes de que la reciba otra aplicación compatible. Si un servidor normaliza o descodifica en un orden diferente, dos sistemas pueden discrepar sobre la ruta solicitada. El diseño de Dürst y Suignard trata de la unión entre sistemas, no solo de mostrar caracteres no latinos en la barra de direcciones.

Una codificación válida no registra un nombre

IDNA responde a una pregunta concreta: ¿se puede representar y validar una etiqueta según las reglas aplicables? La RFC 5891 separa los procesos de registro y consulta DNS. Señala que el trabajo de los registradores antes de que la solicitud llegue al administrador de la zona queda fuera de la definición del protocolo IDNA; el registro o administrador de zona valida la cadena específica presentada. Una A-label sintácticamente válida no prueba que el dominio esté registrado, delegado en DNS o bajo el control del servicio que espera la persona lectora.

Esa separación se olvida fácilmente cuando se copia en un documento un nombre Unicode familiar. Hay varios comprobantes distintos: los caracteres que escribió la persona, la adaptación aplicada por la interfaz, la etiqueta del host presentada al DNS y la respuesta de un servicio web. El registro y la evidencia de control del servicio son datos adicionales; no son simplemente otras grafías de la misma cadena. Una conversión correcta no demuestra ninguno de ellos.

También hay una cuestión de seguridad. La RFC 3987 advierte del engaño visual tanto en el host como en la ruta: caracteres parecidos, expectativas distintas de normalización o un procesamiento diferente entre cliente y servidor pueden hacer que dos direcciones parezcan iguales y, sin embargo, seleccionen recursos distintos. La norma no dice que Unicode sea peligroso. Exige que el sistema sepa qué componente y qué transformación sustentan el resultado. Lo que se muestra informa sobre la presentación; no certifica una identidad.

La contribución de Dürst, sin el mito del autor solitario

La RFC lleva la firma de M. Dürst y M. Suignard. El CV oficial de Dürst en la Universidad Aoyama Gakuin lo describe como autor principal de la especificación IRI y registra su trabajo en internacionalización de la Web, uso de Unicode y normalización de caracteres compuestos. También señala que dirigió la actividad de internacionalización del W3C durante buena parte del periodo en que se preparó la RFC 3987. La universidad lo identifica como profesor de su College of Science and Engineering.

Ese historial respalda una contribución importante, no una autoría exclusiva. La relevancia se aprecia en la decisión técnica: en lugar de obligar a los lectores de URI a adivinar qué significan nuevos caracteres, IRI ofrece una representación propia a los programas que admiten Unicode y define cuándo hace falta convertirla. La labor de Dürst fue parte de un esfuerzo de estandarización más amplio, y la RFC reconoce conjuntamente a Suignard.

La conexión con el “derecho a registros exactos” de Heng Lu es deliberadamente limitada. Su texto se refiere a los Registros Regionales de Internet y a los recursos de numeración IP; no es política DNS ni rige los nombres de dominio. Aquí solo sirve como pregunta analítica: ¿un registro describe realmente el estado que afirma describir? Una grafía Unicode, una A-label, una delegación DNS y la clave de recurso de un servicio web son registros relacionados en capas distintas. Ninguno sustituye a los demás.

Fuentes