Resumen

  • El informe de ICANN del 24 de agosto recoge una corrección concreta: U+A9B4 puede seguir a U+A9BA o U+A9BB, no a U+A9BA o U+A9BC como decía el borrador.
  • La expresión errónea aparece en la propuesta de 40 páginas, en su presentación HTML y en el XML, donde la regla aplicada a U+A9B4 se llama follows-A9BA-A9BC.
  • ICANN afirma que discutirá el cambio con la comunidad javanesa y después lo incorporará a la versión final. Al 1 de septiembre, la página oficial aún no incluía un LGR javanés definitivo.
  • Un LGR de referencia orienta el diseño y la revisión de tablas IDN de registros, pero no es la tabla de un operador ni prueba su despliegue.
  • Un recibo de corrección debe unir la observación, la decisión, el diff y las huellas del paquete final, manteniendo aparte la adopción posterior.

El comentario llegó al lugar correcto

ICANN abrió la consulta el 12 de mayo para dos nuevos LGR de referencia —javanés y UCAS— y seis actualizaciones. Recibió 33 comentarios pertinentes. Treinta y dos respaldaron el conjunto; uno se concentró en una errata y en la relación entre dos reglas del documento javanés.

Arif Budiarto explicó que U+A9B4, JAVANESE VOWEL SIGN TARUNG, debía poder aparecer tras U+A9BA, JAVANESE VOWEL SIGN TALING, o U+A9BB, JAVANESE VOWEL SIGN DIRGA MURE. El proyecto decía U+A9BC, JAVANESE VOWEL SIGN PEPET. Según su comentario, el cambio no inventa una nueva intención ortográfica: corrige la manera en que esa intención quedó escrita.

La revisión no se limita a una frase. En la página 38 del documento de apoyo, la regla 4 contiene A9BA y A9BC. El HTML repite la condición. El XML asigna a U+A9B4 una regla follows-A9BA-A9BC y coloca ambos valores en la clase que mira hacia atrás. Por tanto, el comentario afecta al componente legible por máquinas del paquete sometido a consulta.

La aclaración adicional tiene una función distinta. La regla 3 establece dónde puede ir, en general, una vocal dependiente: después de una consonante, una consonante medial o una vocal independiente. La regla 4 restringe específicamente U+A9B4. El grupo de trabajo anunció que actualizaría el texto y las referencias para que la regla específica no se leyera de forma incompatible con la general.

Nada de esto invalida U+A9BC en el repertorio. El carácter sigue figurando como JAVANESE VOWEL SIGN PEPET. Sólo se corrige su papel como posible predecesor de U+A9B4.

ICANN ha cerrado el sentido, no la publicación

El informe de síntesis adopta una postura clara: el cambio se hablará con la comunidad javanesa y se incorporará a la versión final. Después de considerar los comentarios y realizar las modificaciones necesarias, ICANN publicará los LGR definitivos en su página de referencia de segundo nivel.

Ese texto permite saber hacia dónde va el proceso. No permite descargar el resultado. En la comprobación del 1 de septiembre, la página seguía presentando el 25 de octubre de 2024 como versión vigente y no enumeraba el javanés entre los LGR por escritura. El XML, el HTML y la propuesta de abril seguían siendo los artefactos asociados a la consulta.

No hay motivo para presentar ocho días de trabajo pendiente como una negativa. Confirmar con la comunidad, modificar tres documentos y validar el XML requiere tiempo. Sí hay motivo para preservar el estado exacto: “corrección registrada, versión final pendiente” es más fiel que “regla corregida” o “corrección ignorada”.

Las directrices de ICANN refuerzan esa lectura. Las reglas normativas se expresan en XML conforme a la RFC 7940, y una pregunta de revisión es si ese XML representa con precisión los puntos de código y reglas deseados. La prosa fija el compromiso; los bytes versionados demuestran su cumplimiento.

Del patrón común a cada registro hay otro salto

Los LGR de referencia tienen una función práctica. Los operadores pueden consultarlos al diseñar sus tablas de nombres de dominio internacionalizados, e ICANN los usa al examinar las tablas que los registros gTLD presentan.

Pero “referencia” no significa “actualización remota”. La versión común, la tabla presentada, el resultado de la revisión y la tabla implementada pertenecen a actores y momentos distintos. Una publicación futura no demostrará por sí sola que un registro cambió su configuración.

Esa separación impide exagerar el riesgo actual. Ninguna fuente revisada identifica una tabla vigente que copiara el borrador, un nombre rechazado, un dominio roto o un incidente de seguridad. También impide exagerar el éxito futuro: publicar A9BB en el XML final no equivaldrá a una adopción universal.

El recibo que falta cabe en una página

La cadena pública ya tiene casi todos sus eslabones. El primero debe fijar el paquete observado: fecha del 23 de abril, URL y huellas del XML, HTML y PDF; U+A9B4; identificador de regla; clase A9BA/A9BC; comentario y sustitución solicitada.

El segundo debe fijar la autoridad: fecha de la aportación, estado de la conversación comunitaria, disposición de ICANN y función responsable de autorizar el paquete final. Si la corrección se implementa con otro nombre de regla o con una estructura distinta, el recibo debe demostrar la equivalencia semántica.

El tercero debe fijar la publicación: versión, fecha, enlaces y huellas de los tres documentos. Un diff para máquinas mostraría que A9BC salió y A9BB entró en la condición concreta de U+A9B4. Casos de prueba podrían reflejar las secuencias permitidas y prohibidas. El borrador conservaría valor histórico, pero con una marca inequívoca de reemplazo.

Los pasos de cada registro irían en enlaces separados: versión de referencia citada en la tabla presentada, examen de ICANN y estado de adopción del operador. La ausencia de esos datos significa que la adopción no está acreditada, no que sea imposible.

La regla de Heng Lu ayuda a no convertir el recibo en una nueva burocracia. La capa compartida necesita sólo hechos deterministas y atribuibles —actor, artefacto, regla, versión, estado, fecha y revisión— mientras cada operador conserva su decisión local.

Lo que no se puede concluir

La consulta funcionó como una revisión previa a la finalización. No hay base para acusar negligencia, atribuir daños a dominios activos o afirmar que ICANN rechazó la observación. Tampoco hay base para tratar el resumen como si ya fuera el XML definitivo.

El valor institucional del episodio está justamente en su modestia: una comunidad encontró un error acotado, ICANN lo registró y el próximo objeto verificable será la publicación coherente. La rendición de cuentas consiste en no saltarse ese último objeto.

Fuentes

  1. ICANN — informe de síntesis, 24 de agosto de 2026
  2. ICANN — consulta sobre LGR adicionales
  3. ICANN — aportación de Arif Budiarto
  4. ICANN — índice del paquete del 12 de mayo
  5. ICANN — borrador del LGR javanés en XML
  6. ICANN — borrador del LGR javanés en HTML
  7. Panel de Generación javanés — propuesta de apoyo
  8. ICANN — LGR de referencia de segundo nivel
  9. ICANN — directrices de desarrollo
  10. RFC Editor — RFC 7940
  11. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption