Résumé

  • Un flux paginé est explicitement susceptible de pertes ; parcourir tous les liens visibles ne produit pas nécessairement un instantané cohérent.
  • Une archive rend la reconstruction possible, mais seul un reçu de parcours, de rapprochement et de restitution permet de soutenir qu’un observateur possède une histoire complète.

Imaginons un registre de mémoire institutionnelle. Le document courant répond, le lien prev-archive mène à une page ancienne et la base locale contient un grand nombre d’entrées. Le rapport d’exploitation conclut : « archives complètes ».

Le RFC 5005 interdit précisément ce raccourci. Il décrit trois formes dont l’apparence technique peut être proche, mais dont la portée diffère. Un flux complet affirme qu’un seul document représente toutes les entrées du flux logique. Un flux paginé distribue un ensemble mouvant dans des documents temporaires. Un flux archivé associe un document d’abonnement récent à des documents d’archive destinés à rendre l’histoire reconstructible. Le texte ne définit pas la sémantique d’un mélange de ces formes.

La pagination est le cas le plus net. Le standard la qualifie de lossy. Pendant le parcours, une entrée peut être ajoutée ou modifiée sur une page déjà lue ou pas encore lue, sans que le client le sache. Les relations first, last, previous et next indiquent des directions dans une série ; elles ne figent pas cette série. Un client ne devrait donc ni présenter le résultat comme cohérent ou complet, ni fonder ses décisions sur cette hypothèse.

L’archive fournit une capacité plus forte. Le document d’abonnement porte les ajouts ou changements récents. La relation prev-archive conduit vers l’archive complète immédiatement antérieure ; next-archive peut conduire dans l’autre sens et current vers le document courant. L’adresse et le contenu d’un document d’archive devraient rester stables. Cette stabilité autorise un client à ne pas recharger sans cesse ce qu’il a déjà traité.

Elle n’est pourtant pas une preuve d’immutabilité. Il s’agit d’un SHOULD, non d’une empreinte cryptographique. Le RFC avertit même qu’une correction appliquée uniquement à une archive peut échapper aux clients qui l’ont déjà récupérée. Si la correction doit être vue de tous, l’éditeur devrait envisager de republier l’entrée dans le document d’abonnement.

La reconstruction demande ensuite une action du client. Celui-ci suit un prev-archive non traité, ajoute les entrées, puis recommence jusqu’à rencontrer un lien déjà traité, l’extrémité sans prédécesseur ou une erreur. Or l’éditeur n’est pas obligé de servir chaque archive : un document peut être refusé par 403 ou 410, ou indisponible avec 404. Le client n’est pas obligé non plus de tout stocker ou reconstruire. S’il n’y parvient pas, il doit avertir l’utilisateur.

L’avertissement est un élément de preuve, pas un détail d’interface. Un registre amputé mais signalé comme tel conserve sa limite. Le même registre présenté sans réserve transforme une absence de données en absence de faits.

Les doublons créent une autre bifurcation. Le client devrait retenir l’entrée la plus récemment mise à jour. Si les horodatages sont identiques ou absents, la préséance reste à déterminer. Le RFC 4287 donne les identifiants et dates Atom ; il ne garantit pas que deux consommateurs feront la même reconstruction dans un cas indéterminé. Le RFC 6721 ajoute plus tard des éléments de suppression, car Atom de base ne permettait pas de dire à un client qu’une entrée déjà reçue avait disparu.

Le marqueur fh:complete appartient encore à une autre couche. Il exprime la déclaration de l’éditeur selon laquelle le document contient l’ensemble du flux logique. Il ne prouve pas que le cache possède la dernière représentation, que les entrées anciennes ont été retirées de l’affichage, que le contexte d’authentification est homogène ou qu’un lecteur a pris connaissance du résultat.

Un reçu de reconstruction défendable devrait donc consigner :

  1. l’identité, la date de lecture et le validateur du document d’abonnement ;
  2. le type de flux déclaré et le graphe exact des relations observées ;
  3. chaque IRI demandé, redirection, réponse, autorité et empreinte de contenu ;
  4. l’ordre de parcours, les reprises, les plafonds de ressources et la raison d’arrêt ;
  5. la règle appliquée aux doublons et aux suppressions ;
  6. la révision de l’état local, la date de coupure et un statut explicite — complet, borné, interrompu ou inconnu ;
  7. l’avertissement effectivement montré ;
  8. une relecture de la vue rendue au lecteur.

Ce reçu est une recommandation éditoriale inspirée par la discipline des couches de réalité de Heng Lu. Le RFC 5005 n’impose pas ce format. Il n’atteste aucun produit, aucun corpus ni aucun comportement d’utilisateur. Ses deux errata vérifiés corrigent un UUID d’exemple et précisent que les cibles de liens Atom sont des IRI ; ils ne modifient pas la frontière probatoire.

La bonne question de direction n’est donc pas « l’archive répond-elle ? », mais « quelle histoire cet observateur peut-il défendre, jusqu’à quelle coupure et avec quelles lacunes visibles ? »

Sources