Resumen

  • En RFC 5005, una fuente paginada puede perder cambios mientras el cliente avanza; los enlaces visibles no forman por sí solos una instantánea coherente.
  • Una fuente archivada permite reconstruir el conjunto lógico, pero el cliente puede detenerse, encontrar errores o no conservarlo; cada transición necesita su propio recibo.

Una auditoría pide la historia completa de una publicación. El sistema presenta 8.432 filas, una última solicitud exitosa y una cadena de enlaces que llega hacia atrás. La respuesta parece cuantitativa. Sin embargo, no explica qué contrato anunció el editor, qué documentos se visitaron, dónde terminó el recorrido ni qué versión vio el lector.

El RFC 5005 ofrece una taxonomía para no confundir esas capas. Una fuente completa declara que un solo documento contiene todas las entradas de la fuente lógica. Una fuente paginada divide entradas entre documentos temporales que pueden cambiar. Una fuente archivada publica un documento de suscripción con novedades y documentos históricos relativamente estables que pueden combinarse. La especificación no define qué significa mezclar estos tipos.

La fuente paginada es deliberadamente limitada. RFC 5005 la llama lossy: mientras el cliente solicita páginas, el editor puede añadir o modificar entradas sin que el recorrido lo detecte. first, last, previous y next son relaciones de navegación, no barreras de consistencia. Aunque todas respondan, el cliente no debería presentar el conjunto como coherente ni completo.

La fuente archivada cambia la promesa. prev-archive conduce al archivo inmediatamente anterior; next-archive puede apuntar al siguiente y current al documento de suscripción. El documento y la dirección de un archivo deberían permanecer estables. Eso permite que un consumidor trate como procesado un tramo antiguo y se concentre en lo nuevo.

Pero “debería permanecer estable” no significa “se demostró inmutable”. Si el editor cambia un archivo, algunos clientes quizá no lo sepan. Por eso RFC 5005 recomienda volver a publicar en el documento de suscripción una corrección que deba llegar a todos. Una huella local puede demostrar los bytes que observó un recolector; no convierte la recomendación del protocolo en una garantía global.

La reconstrucción requiere recorrer. El cliente toma un prev-archive que todavía no procesó, descarga el documento, incorpora sus entradas y repite hasta llegar a un enlace ya visto, al extremo sin predecesor o a un error. El editor puede no servir todos los archivos: 403, 404 y 410 son posibilidades explícitas. El cliente tampoco está obligado a almacenar o reconstruir siempre todo. Su deber, si queda incompleto, es avisar al usuario.

Ese final tiene cuatro estados distintos: alcanzó el origen; alcanzó una marca previamente validada; se detuvo por error; o se detuvo por política de recursos. Registrarlos todos como “terminado” destruye la información que la auditoría necesitaba.

Los duplicados añaden una decisión. Se debería conservar la entrada con actualización más reciente. Con marcas iguales o ausentes, el consumidor debe decidir. RFC 4287 define la estructura Atom, pero no impone una verdad externa. RFC 6721 añadió avisos explícitos de eliminación porque Atom base no podía comunicar que desapareció una entrada que el cliente ya había procesado.

fh:complete tampoco es un certificado universal. Es la declaración del editor de que ese documento contiene el conjunto lógico. No demuestra que el consumidor obtuvo la representación vigente, sustituyó su estado viejo, interpretó correctamente las eliminaciones, mantuvo el mismo contexto de seguridad o mostró el resultado a una persona.

Por eso una prueba de reconstrucción debería guardar:

  1. identidad, hora y validador del documento de suscripción;
  2. tipo declarado y grafo de relaciones observado;
  3. IRI, redirección, respuesta, autoridad y huella de cada documento;
  4. orden del recorrido, reintentos, límite de recursos y motivo de cierre;
  5. política para duplicados, empates y eliminaciones;
  6. revisión del estado conservado y fecha de corte;
  7. estado de completitud y aviso efectivamente mostrado;
  8. lectura posterior de la vista que recibió el usuario.

Es una recomendación de gobernanza, no una obligación oculta del RFC. Sigue la separación de capas de Heng Lu: la afirmación del editor, el intercambio de red, el estado materializado y la observación humana no deben fusionarse sin evidencia.

El estándar no acredita ningún producto, plataforma, archivo ni incidente real. Los dos errata verificados corrigen un UUID de ejemplo y aclaran que los destinos de enlaces Atom son IRI. No alteran el límite entre posibilidad de reconstrucción y reconstrucción observada.

La pregunta útil no es cuántas páginas existen. Es qué historia exacta puede defender este observador, hasta qué corte y con qué incertidumbre aún visible.

Fuentes