Resumen

  • RFC 3085 propuso un URN calificado por el dominio y la fecha del proveedor para identificar un NewsItem lógico en varias ubicaciones físicas, con una revisión positiva que ordenaba las versiones de ese mismo item.
  • Los sufijos U y A señalaban situaciones distintas de actualización, pero ni la etiqueta de versión ni el registro en IANA demostraban que el recurso existiera o pudiera recuperarse.

Un despacho corregido puede circular a varias redacciones: la agencia conserva su URL, un cliente sirve una copia y el archivo interno guarda otra. El dato editorial sigue siendo el mismo, pero las direcciones no. Para separar esas dos cosas nació el namespace newsml que propuso RFC 3085.

El RFC 3085 apareció en marzo de 2001. Describía un URN para NewsItems de NewsML y partía de que un mismo item lógico podía estar en distintos lugares físicos. El formato permitía asociar varias URL, pero un solo URN, destinado a nombrar el recurso más allá de sus ubicaciones. Su categoría era Informational; el propio documento aclaraba que no establecía un estándar de Internet.

La cadena combinaba el dominio del proveedor, una fecha, el identificador del NewsItem, un número de revisión y, a veces, una letra final. Quien asignaba el URN debía poseer el dominio indicado en la fecha consignada. El identificador del item debía ser único dentro de la pareja proveedor/fecha. Para ese item, la revisión tenía que ser un entero positivo: cero no estaba permitido y un número mayor debía representar una versión más reciente. No era un reloj común para todas las noticias.

La letra final afinaba el significado editorial. U se exigía si el NewsItem incluía uno o más elementos Update. A correspondía a reemplazar únicamente el conjunto de datos NewsManagement. Si no ocurría ninguno de esos casos, no se añadía sufijo. Así, modificar el contenido y sustituir solo los datos de gestión eran operaciones distintas.

La definición de equivalencia léxica enumera ProviderId, DateId, NewsItemId y RevisionId, comparados sin distinguir mayúsculas. No incluye el sufijo opcional en esa lista. Conviene limitarse a lo que dice la frase: la letra no aparece como una clave adicional en esa comparación. El texto no documenta cómo todos los sistemas trataban identificadores que solo diferían en el sufijo.

El nombre, por sí solo, no llevaba al lector hasta el despacho. RFC 3085 responsabilizaba a los proveedores de ofrecer resolución y validación para identificadores válidos «si las hubiera». El registro formal de URN de IANA referencia newsml mediante RFC 3085; confirma la inscripción, no que un resolvedor esté activo. Los ejemplos del RFC también podrían no corresponder a recursos reales.

La página actual de NewsML-G2 de IPTC muestra un ámbito posterior de intercambio de items y paquetes multimedia. No demuestra la adopción de NewsML 1.0 ni la operación de un servicio basado en RFC 3085. La aportación concreta del RFC fue acotar identidad y orden de versiones; dejó aparte la recuperación del contenido.

Análisis

El diseño responde a dos preguntas diferentes: de qué item se habla y qué revisión ocupa un lugar posterior. El dominio y la fecha califican el espacio de asignación; el identificador local selecciona el item; la revisión establece el orden entre sus versiones. Que esas reglas estén escritas no demuestra que todas las copias distribuidas las respeten.

También importa distinguir una actualización del NewsItem de la sustitución de metadatos de gestión. La marca codifica el caso previsto, no la recepción de un aviso ni el hecho de que una redacción tenga la última copia.

Seguimiento

Una auditoría puede comprobar por separado la sintaxis, la propiedad del dominio en la fecha indicada, la unicidad del identificador, la secuencia de revisiones, la relación entre sufijo y contenido, y la respuesta actual del resolvedor. RFC 3085 no ofrece una meta de disponibilidad, frescura o entrega.

La presencia de newsml en IANA no dice cuántos proveedores lo usaron ni si sus servicios siguen accesibles. NewsML-G2 es contexto posterior, no evidencia de continuidad de implementación.

Control e incentivos

El proveedor que asigna el URN controla la unicidad dentro de su espacio proveedor/fecha y responde por el servicio que decida ofrecer. Un agregador puede replicar contenido y mantener un índice propio; eso no lo convierte en autoridad sobre la revisión asignada por otro.

Cada archivo debe decidir si conserva solo los identificadores o si mantiene además rutas de recuperación mediante resolvedores, redirecciones o espejos. Esas medidas pueden sostener el acceso, pero no vienen incluidas en el URN.

El riesgo irreversible es que sobreviva el catálogo mientras se pierden los ficheros. La secuencia de revisión permite reconocer cuál falta; no reconstruye la copia desaparecida. Por eso conviene registrar aparte identidad, versión, URL, validación y entrega efectiva.

Fuentes