Résumé

  • Dans Netnews, Supersedes désigne exactement un article antérieur par son Message-ID. La révision demeure un nouvel article, avec sa propre identité.
  • Le retrait du prédécesseur suit les règles du cancel : chaque site authentifie, autorise et agit sur sa copie. Deux sites peuvent accepter la révision sans montrer le même passé.
  • Cancel-Lock et Cancel-Key ont renforcé la preuve du demandeur, mais n’ont jamais constitué une garantie d’effacement global.

Une correction commune, deux archives visibles

Une révision arrive sur deux serveurs. Tous deux la publient. Le premier valide la demande de retrait et cesse de servir l’article erroné. Le second conserve celui-ci, faute de preuve suffisante ou parce que sa politique locale n’exécute pas la demande. Ses lecteurs voient donc les deux versions.

Il ne s’agit pas d’un échec partiel de la révision : elle existe sur les deux sites. C’est le sort du prédécesseur qui diverge. Cette scène suffit à écarter l’image trompeuse d’un bouton capable de réécrire simultanément toutes les archives d’un réseau distribué.

Supersedes organisait une relation entre deux publications et une requête portant sur l’une d’elles. Il ne transformait pas leurs exemplaires dispersés en une ligne modifiable d’une base centrale.

Cancel avait déjà localisé le pouvoir de retrait

La RFC 1036 décrit un article de contrôle cancel qui nomme sa cible par Message-ID. Le système destinataire retire la copie qu’il sait traiter. L’opération appartient ainsi au dépositaire local, non à une autorité capable de supprimer toutes les répliques.

L’autorisation restait fragile. La règle historique comparait Sender ou From entre la demande et l’article visé, tout en reconnaissant le pouvoir de l’administrateur du site. Dans un environnement ouvert, une ressemblance d’en-tête prouvait mal la maîtrise du texte initial. Empêcher une correction abusive était déjà aussi important que permettre une correction légitime.

Cette origine explique pourquoi le retrait ne devait pas être confondu avec la livraison d’un remplacement. Plus le réseau avait copié l’article, plus il existait de décisions locales à prendre.

Une nouvelle identité plutôt qu’une modification sur place

La RFC 5536 limite la valeur Netnews de Supersedes à un seul Message-ID. Son effet est formulé comme une demande de cancel visant ce prédécesseur, immédiatement suivie du traitement normal du nouvel article comme si le champ avait été retiré.

La formulation protège une distinction essentielle : la révision n’emprunte pas l’identité de l’ancienne version et n’en remplace pas le corps dans le stockage. Elle possède son propre Message-ID, ses propres en-têtes et sa propre trajectoire. Supersedes exprime le lien ; il ne fusionne pas les deux objets.

Surtout, le succès de la première opération n’est pas une condition de la seconde. Une correction reste publiable lorsque le nettoyage ne peut pas être certifié partout.

Le site pouvait honorer ou refuser la requête

La RFC 5537 précise que Supersedes n’est pas lui-même un message de contrôle. La demande de retrait qu’il contient doit néanmoins subir la même authentification et la même autorisation qu’un cancel. Si le site l’honore, il effectue localement la même action.

Qu’il l’honore ou non, le nouvel article est traité normalement. Accepter la révision ne certifie donc pas le retrait ; conserver l’original ne signifie pas que la correction a été rejetée.

La RFC rappelle aussi pourquoi de nombreux sites ont historiquement ignoré cancel et supersede : l’authentification était difficile, tandis que l’effacement malveillant offrait un levier puissant. Le logiciel de publication devrait empêcher l’utilisateur de viser l’article d’autrui, mais cette précaution ne remplace pas la décision de chaque site en aval.

Une preuve cryptographique n’est pas un pouvoir universel

La RFC 8315 propose Cancel-Lock et Cancel-Key. L’article d’origine porte une valeur de verrouillage ; la demande ultérieure fournit une clé dont la dérivation peut être comparée à ce verrou. Le site dispose alors d’une preuve de connaissance liée à la publication initiale, plus solide qu’une adresse ressemblante.

Cette amélioration répond à « qui demande ? », non à « où toutes les copies sont-elles conservées ? ». Une clé valide n’efface pas une archive hors ligne, une exportation par passerelle, une citation ni un site qui n’applique pas la procédure. Elle éclaire une décision locale sans créer de souveraineté globale.

Les interfaces devraient donc annoncer « retrait authentifié sur ce service » plutôt que « supprimé d’Internet ».

Le courrier avait un homonyme, pas la même sémantique

La RFC 2156, consacrée au passage entre Internet Mail et X.400, définit aussi un champ Supersedes, capable de citer plusieurs identifiants. La RFC 5536 indique explicitement que la variante Netnews à cible unique n’a pas de lien avec ce champ de courrier.

Le registre IANA des champs de message conserve deux inscriptions distinctes, l’une pour mail, l’autre pour netnews. Un nom commun ne suffit donc pas à transporter une promesse de rappel d’un média à l’autre.

Le registre stabilise la grammaire et la référence normative. Il ne mesure ni l’adoption actuelle, ni la politique d’un fournisseur, ni l’état de toutes les copies.

La correction avançait sans nettoyer tout le passé

L’héritage de Supersedes est moins élégant qu’une histoire unique : certains lecteurs ne verront que la révision, d’autres les deux versions, et une archive pourra conserver ce qu’un serveur ne sert plus. Mais cette pluralité décrit honnêtement un réseau de dépositaires indépendants.

Il faut alors préciser ce que signifie « remplacé » : relation enregistrée, ancienne version masquée, copie retirée d’un magasin déterminé ou absence vérifiée d’un corpus donné. Ces états ne sont pas interchangeables.

Netnews a choisi de faire de la correction un fait nouveau et du retrait une demande bornée. La révision pouvait poursuivre sa route, même lorsque son prédécesseur ne pouvait plus être rappelé de chaque lieu où il avait vécu.