Resumen

  • El borrador que sustituiría al RFC 7451 pide a los expertos designados una actitud permisiva si una extensión EPP ha sido implementada y desplegada por al menos una pareja registro/registrador o servidor/cliente. También acepta que se registren varias extensiones con funciones iguales o parecidas.
  • Figurar en el registro acredita una referencia permanente, una identidad técnica y una revisión reconocible. No acredita que el diseño sea preferido, que pertenezca al Standards Track, que esté extendido en el mercado ni que pueda sustituir a otro sin pruebas locales.
  • El registro de IANA ya contiene coexistencia explícita: sus notas dicen que las extensiones IDN y de privacidad de CORE son sintáctica y funcionalmente idénticas a sus equivalentes de TANGO, aunque usan espacios de nombres XML diferentes. La operación necesita un mapa que conserve ambas verdades.

Una tabla oficial ejerce una fuerza psicológica mayor de la que parece. Si una extensión EPP tiene nombre, referencia y estado en IANA, el lector tiende a verla como una solución aprobada. Si otra fila cubre una función similar, la pregunta aparece enseguida: ¿cuál es la auténtica?

La arquitectura institucional ofrece otra respuesta. El registro no es un podio; es memoria coordinada. EPP permite añadir funciones a sus comandos y objetos básicos, y esas funciones nacen en comunidades, empresas y relaciones operativas distintas. El catálogo asigna un lugar estable a sus identificadores para que no se conviertan en dialectos indocumentados. No borra la multiplicidad que ya existe.

La revisión 10 de draft-ietf-regext-ext-registry-epp, publicada el 17 de agosto de 2026, lo dice expresamente. Puede haber más de una extensión con la misma función o con una función semejante. Esa semejanza, por sí sola, no justifica rechazar una solicitud válida. Si al menos una pareja registro/registrador —o servidor/cliente— la ha puesto en producción, los expertos deberían inclinarse por permitir la inscripción.

La regla confirma existencia operativa. No celebra unas elecciones.

Un mínimo bilateral, no una cuota de mercado

EPP funciona entre contrapartes. Una extensión escrita por un servidor y desconocida para todos los clientes no completa el circuito; tampoco una función de cliente que ningún servidor acepta. La pareja desplegada es, por tanto, una unidad de prueba bien elegida: demuestra que la especificación ha sobrevivido al encuentro entre dos implementaciones.

Pero solo demuestra eso. No informa de cuántos registradores pueden usarla, de cuántos TLD dependen de ella ni del volumen de transacciones. No garantiza que un mismo cliente trate igual las versiones ofrecidas por diferentes registros. Tampoco asegura que los campos opcionales, los errores y las políticas comerciales se comporten de forma uniforme.

El estado «Active» es igualmente limitado. Según el borrador, significa que la extensión está implementada y en uso. «Inactive» significa que no se implementa o utiliza, o que la especificación ya no está disponible. Ninguna etiqueta es una estadística de penetración. Entre una pareja activa y un ecosistema entero hay un espacio que el registro no pretende medir.

Incluso la lista de TLD debe leerse como alcance declarado, no como certificado de compatibilidad. Falta saber qué versión de servidor responde, qué clientes la negocian, si la función es obligatoria, si hay pasarelas y qué transformaciones aplican. Esas preguntas pertenecen a la operación, no a la asignación del identificador.

La revisión protege el espacio común

La política «Specification Required» del RFC 8126 exige una especificación permanente y de acceso público, sometida a expertos designados. El borrador acepta RFC y especificaciones propietarias que permanezcan disponibles, con versión en inglés. Un Internet-Draft ordinario no sirve como referencia permanente para futuros registros y el mecanismo de asignación temprana del RFC 7120 no se aplica.

El propósito es evitar nombres huérfanos. Años después, un desarrollador debe poder averiguar qué significaba un espacio XML encontrado en un mensaje. Por eso la tabla conserva nombre, estado documental, referencia, solicitante, TLD, propiedad intelectual, estado activo o inactivo y notas.

Los expertos revisan la coherencia arquitectónica, la documentación de privacidad, la sintaxis y semántica de los URI, y el empleo correcto de espacios de nombres IETF o no IETF. Un experto principal conduce el examen. Si no está disponible, un grupo suplente decide mediante consenso de mayoría simple. Quien perciba un conflicto de interés debe apartarse, y la lista de correo REGEXT puede servir para discusión pública.

Es una revisión material, pero acotada. No pregunta qué proveedor merece dominar el mercado. Tampoco convierte una especificación privada en consenso del IETF. Responde si la entrada es estable, inteligible y suficientemente fundada para compartir el espacio de nombres.

El propio texto de reforma aún no es definitivo. Es un Internet-Draft activo, con destino propuesto de Best Current Practice, remitido al IESG y en la cola del RFC Editor a la espera de editor. Si culmina el proceso, dejará obsoleto al RFC 7451. Mientras tanto, atribuirle el rango de RFC publicado sería ocultar una transición institucional relevante.

Dos familias, dos espacios de nombres

El registro vigente de IANA, actualizado el 4 de septiembre de 2026, contiene entradas Standards Track y «Other», activas e inactivas. Sus notas sobre CORE y TANGO convierten el solapamiento en un hecho observable.

En IDN, la extensión de CORE aparece como sintáctica y funcionalmente idéntica a la de TANGO, pero con un espacio de nombres XML diferente. La misma relación se consigna para sus extensiones de privacidad. El catálogo no intenta esconder la duplicidad ni declara que una fila deba absorber a la otra.

«Funcionalmente idéntica» es una afirmación importante, aunque no ilimitada. El espacio de nombres sigue formando parte del mensaje. Un cliente que genera elementos TANGO no puede suponer que el servidor que anuncia CORE los aceptará. Los dos pueden compartir esquema conceptual y, sin embargo, diferir en soporte instalado, pruebas, calendarios, gobierno de cambios y tratamiento de versiones futuras.

Tampoco conocemos, por la nota sola, todas las razones de la bifurcación. Puede haber historia, despliegues previos, comunidades distintas, costes de migración o control institucional. Mantener las dos coordenadas permite interpretar sistemas antiguos y construir puentes conscientes. Convertir el registro en una lista sin aparente redundancia podría destruir precisamente la información que una migración necesita.

El mapa de coexistencia

Para escoger una implementación hace falta añadir una capa analítica al registro. Propongo llamarla mapa de coexistencia. No sería un requisito de IANA ni una propuesta normativa del borrador, sino una herramienta de decisión construida con evidencia atribuida.

Primero agruparía las extensiones por clase funcional —IDN, privacidad, lanzamiento, tarifas u otra— manteniendo cada espacio de nombres visible. Después registraría la especificación permanente, versión, estado documental, comandos y respuestas afectados. Una tercera sección preservaría procedencia: solicitante, fecha, tipo de revisión y eventuales deliberaciones en REGEXT.

El despliegue se documentaría con precisión: pareja servidor/cliente, software, TLD, versión y fecha. La expresión «una pareja» nunca se traduciría en «adopción del sector». Para cada solapamiento se indicaría quién afirma la equivalencia y sobre qué base: nota IANA, comparación de esquemas, ensayo de conformidad, declaración de los autores u observación real.

El mapa tendría además una matriz de soporte actual. Mostraría qué servidores y clientes hablan cada espacio de nombres, si existe traducción y qué campos o errores se pierden en el camino. Finalmente conservaría instantáneas históricas de estados, referencias y notas.

Así quedarían separadas cuatro frases: está registrada; se desplegó en algún lugar; nuestro sistema la admite; puede reemplazar a otra en este caso. Un registro plano solo prueba la primera y ofrece indicios parciales sobre la segunda.

La limpieza también puede borrar memoria

El borrador ordena los procedimientos de alta, modificación, desactivación y eliminación. Los cambios de estado necesitan justificación. Para retirar una entrada surgida del consenso IETF se requiere la aprobación del IESG. Las entradas no IETF pueden ser retiradas o desactivadas por el IESG o por el solicitante original junto con los expertos.

Sin embargo, el texto reconoce que el registro no mantiene historial. Una entrada eliminada deja de ser rastreable dentro de él. Esta carencia transforma una decisión administrativa en un riesgo probatorio.

Desactivar y eliminar no son sinónimos. La desactivación avisa de que no conviene iniciar nuevas dependencias, pero conserva el identificador para leer tráfico, software y contratos antiguos. La eliminación puede hacer que un fallo histórico parezca un dato desconocido. Si además desaparece la especificación, se pierde la posibilidad de reconstruir la intención original.

El registro actual coordina el presente; las instantáneas coordinan la memoria. Sin ambas cosas, la simplificación visual de hoy se paga con ambigüedad operativa mañana.

Fuentes