Resumen

  • La revisión IDN Fast Track aprobó la cadena en escritura urdu en enero de 2011; eso no colocó por sí solo una zona operativa en la raíz DNS.
  • Pakistán eligió a NTC en 2015, reabrió la solicitud de delegación en 2016 y completó un cambio de servidores de nombres de la raíz en 2017.

Análisis

La etiqueta parece un nombre de país. En DNS también tenía que convertirse en una delegación concreta y verificable. .پاکستان —la palabra en urdu para Pakistán, escrita con caracteres árabes— muestra por qué son actos distintos. La cadena podía superar una evaluación de estabilidad y riesgo de confusión antes de que se aprobara al operador del registro y sus servidores de nombres aparecieran en los datos de la raíz.

El trabajo comenzó con preguntas de lengua e implementación. El Ministerio de Tecnología de la Información de Pakistán organizó en abril de 2008 un taller sobre conjuntos de caracteres para las lenguas locales y otro en mayo de 2009 sobre tablas lingüísticas y detalles de implementación. Un comité con integrantes de la comunidad local de Internet se reunió en octubre de 2009; después hubo subcomités sobre asuntos técnicos, lingüísticos y de política. No eran preparativos cosméticos.

IDNA permite procesar una etiqueta Unicode mediante formas compatibles con DNS, pero no decide la grafía preferida de un país, la política de teclados ni quién administra el registro.

Pakistán presentó .پاکستان al proceso IDN Fast Track de ICANN el 25 de octubre de 2010. En su revisión del 7 de enero de 2011, el panel de estabilidad DNS no encontró amenazas previstas por el plan aplicable y consideró aceptablemente bajo el riesgo de confusión. Después se aprobó la cadena como representación de Pakistán. La decisión contestaba una pregunta acotada sobre la etiqueta. No asignaba al operador de la zona ni publicaba la delegación en la raíz.

Es fácil pasar por alto la diferencia entre escritura y representación DNS. IANA registra la forma Unicode پاکستان y su forma compatible con ASCII xn--mgbai9azgqp6j. RFC 5890 denomina U-label y A-label a estas formas de presentación y compatibles con DNS. RFC 5891 describe IDNA como procesamiento de aplicaciones que permite usar nombres internacionalizados sin modificar DNS; las consultas y respuestas DNS usan A-labels. Punycode es, por tanto, una conversión reversible, no una traducción al inglés ni prueba de que exista un segundo dominio.

La etapa siguiente siguió otra vía. Tras más trabajo sobre contenido local, diseño de teclado y políticas, el Comité Técnico Principal de Pakistán eligió a la National Telecommunication Corporation (NTC) como gestor el 3 de junio de 2015. El Ministerio inició en julio una solicitud de delegación en la raíz. El informe de IANA dice que la petición se cerró temporalmente para corregir deficiencias; NTC presentó un nuevo trámite el 22 de abril de 2016. La auditoría de la raíz de diciembre de 2016 aún mostraba la solicitud pendiente.

El 3 de febrero de 2017, la junta de ICANN examinó si PTI había seguido el procedimiento de evaluación y aprobó crear .پاکستان con NTC como gestor. El expediente recoge apoyo gubernamental, consulta local, competencia técnica y verificaciones de configuración DNS. También dice que no conocía objeciones comunitarias significativas ni riesgos notables para la estabilidad. La junta trató de la delegación y de una operación responsable; no volvió a decidir si la palabra en urdu representaba a Pakistán.

La puesta en marcha dejó más rastro que la votación. La auditoría de IANA de marzo de 2017 registra una transacción de servidores de nombres para .پاکستان, completada el día 30. Eso confirma un cambio en la raíz durante 2017, pero no demuestra que fuera la primera inserción. El registro actual de IANA muestra a NTC y sus servidores. También señala una «fecha de registro» de 2011, que no debe confundirse con los registros fechados de 2017: las fuentes asignan esos campos a hitos distintos.

La distinción importa porque un nombre escrito no se opera por sí solo. Una etiqueta elegida localmente necesita una codificación estable, un gestor responsable, servidores de nombres que respondan y una delegación en la raíz. A la inversa, aparecer en la raíz no demuestra que los sitios adoptaran la escritura, que todos los teclados puedan introducirla ni que haya contenido localizado. El registro prueba una secuencia de decisiones y cambios técnicos, no adopción ni resultados para los usuarios.

Fuentes