Resumen

  • RFC 3937 creó urn:iptc bajo una autoridad central y ordenó sus identificadores en las ramas std, std-draft y workdoc.
  • Una cadena de ejemplo o una sintaxis correcta no demostraban una asignación real; además, el mapeo a URL y la validación quedaban ligados a un resolvedor futuro.

Un ejemplo no era una entrada del registro

RFC 3937 mostró nombres para una DTD de NewsML, un esquema XML de NITF aún en borrador, un namespace de SportsML, materiales de apoyo y un documento de trabajo. Acto seguido, advirtió que eran ejemplos representativos y que podían no corresponder a recursos reales. Esa cautela es el centro de la historia: un identificador puede parecer perfectamente oficial, seguir la gramática y aparecer dentro de un RFC sin haber sido emitido por la autoridad que controla el espacio.

El registro documental del RFC Editor confirma que se trata de un memo Informational, y la página de erratas permite comprobar correcciones posteriores. IANA mantiene iptc en su registro de namespaces URN. Esas tres superficies acreditan el NID y su documento de referencia. No son un censo de cada nombre descendiente ni un registro de disponibilidad histórica.

La arquitectura anterior ya había separado esas pruebas. RFC 1737 formuló requisitos funcionales para nombres persistentes. RFC 2141 describió la sintaxis URN. RFC 2276 abordó la resolución como un problema arquitectónico, y RFC 3401 explicó el sistema DDDS usado por ciertas aplicaciones para descubrir delegaciones. RFC 3406 aportó la plantilla de definición formal que siguió el IPTC. Registrar, asignar, validar y resolver eran actos relacionados, pero distintos.

La autoridad estaba concentrada

El diseño dividía el espacio en tres ramas. std contenía recursos que especificaban o explicaban una norma aprobada; std-draft, materiales análogos antes de la aprobación; workdoc, documentos del trabajo institucional sin vínculo directo con una norma aprobada. El director general del IPTC debía asegurar la unicidad, y solo el propietario del namespace o sus autoridades podían asignar identificadores.

IANA, por tanto, registró iptc; no examinaba cada urn:iptc:.... La validez semántica dependía de un acto institucional conservado en los registros del IPTC. Un analizador podía decir que la cadena era legal, pero no que había sido emitida. El modelo reducía colisiones mediante control centralizado y, al mismo tiempo, creaba una dependencia duradera de la continuidad administrativa del organismo.

RFC 3085 ya había reservado un namespace para recursos NewsML. RFC 3937 buscó una jerarquía más amplia para estándares de IPTC, documentos accesibles fuera de la membresía, esquemas, estilos, PDF y otros formatos. El alcance creció, pero el nuevo registro no demostraba que todo nombre NewsML previo hubiera migrado ni que los dos espacios fueran intercambiables.

Las ramas std y std-draft incorporaban versión. Un valor explícito podía fijar una edición; current podía conservar el mismo nombre al cambiar la norma vigente. El primer caso era apropiado para reproducibilidad. El segundo ofrecía una puerta estable hacia lo más reciente. Llamar persistentes a ambos no significaba que sirvieran para la misma prueba.

Resolver seguía siendo un verbo en futuro

El IPTC declaró su compromiso de mantener accesibles y persistentes los recursos identificados. Sin embargo, el mismo RFC señaló que desarrollaría un mecanismo para mapear todos los URN asignados a URL y permitir resolución web. En la sección de validación no definió otro método: el futuro resolvedor también debía indicar si un URN era válido.

Ese futuro verbal impide atribuir al año 2004 una infraestructura que el texto solo prometía. El nombre identificaba; el resolvedor debía mapear; la URL localizaría; el servidor entregaría una representación. Cada eslabón podía fallar de forma independiente. Un URN asignado podía no resolver. El resolvedor podía devolver una URL desaparecida. Una URL disponible podía ofrecer otra versión. Y una cadena inventada podía superar una prueba sintáctica sin figurar en el libro de asignaciones.

Existe evidencia posterior de uso. La especificación IPTC Core XMP Schema muestra un URN documental explícito de la familia urn:iptc:std:.... Eso acredita al menos una aplicación concreta, no la población completa del espacio ni una línea de resolución sin interrupciones. La página actual de un namespace externo del IPTC muestra una representación web alcanzable ahora; no prueba que toda representación anterior permaneciera accesible en todo momento.

RFC 8141 revisó después la sintaxis y la semántica generales de los URN. Sirve para comprender el marco posterior, no como registro operativo retrospectivo. Los ensayos de Heng Lu sobre la especificación inicial mínima y la adopción voluntaria posterior y sobre la primacía del código en ejecución ofrecen la disciplina adecuada: no convertir un documento, un ejemplo o una intención en evidencia de despliegue.

RFC 3937 hizo algo importante y limitado. Definió quién podía nombrar, cómo evitar colisiones y cómo distinguir familias de recursos. La persistencia efectiva requería además conservar el libro de asignaciones, operar el resolvedor, mantener las URL y preservar las versiones. El ejemplo mostraba el mapa conceptual; la operación debía aportar el territorio.