Résumé

  • Les premières spécifications qualifiaient Expires de date d’expiration suggérée et laissaient la durée ordinaire à la politique locale, notamment aux contraintes de disque.
  • La RFC 5536 en fait le moment où l’auteur estime que l’article n’est plus pertinent et pourrait utilement être retiré : un jugement d’utilité, pas un bail de stockage.
  • NNTP ne révèle que la disponibilité chez le serveur interrogé. Une absence ne prouve ni la cause du retrait, ni sa date, ni la disparition de toutes les copies.

Deux serveurs, une seule échéance

Une annonce de séminaire arrive sur deux serveurs avec le même Message-ID et une valeur Expires fixée au lendemain de l’événement. Le premier dispose d’une vaste capacité et conserve normalement les annonces jusqu’à l’horizon demandé. Le second, soumis à une forte pression de stockage, applique une durée locale plus courte.

La contradiction n’est qu’apparente. La date exprime ce que l’auteur connaît : le moment où l’annonce cessera d’aider ses lecteurs. Elle ne réserve aucun tiroir sur une machine distante. Chaque serveur connaît, lui, sa capacité, son public, ses obligations et ses exceptions d’archive.

Le mot décisif était « suggérée »

La RFC 850 définit Expires comme une date d’expiration suggérée. En l’absence du champ, la valeur par défaut locale s’applique. Le texte envisage aussi bien une durée courte pour une information éphémère qu’une durée plus longue pour un article important.

L’exemple du séminaire clarifie la sémantique : l’annonce peut perdre son utilité le lendemain. La même section rappelle cependant que les sites ont leurs propres politiques, déterminées entre autres par l’espace disque disponible. Elle déconseille aux auteurs d’ajouter une échéance sans raison naturelle et demande aux logiciels de ne presque jamais fabriquer une valeur par défaut.

Cette retenue protège la provenance. Une échéance ajoutée automatiquement ressemblerait à un jugement éditorial tout en ne reflétant que le réglage d’un client. L’absence du champ laisse parler la politique ordinaire du site ; sa présence signale une information exceptionnelle apportée par l’auteur.

La RFC 1036 conserve ce partage. Le champ reste facultatif, l’échéance reste une suggestion et les ressources locales continuent de borner la décision. Usenet a donc normalisé une indication commune sans centraliser la gestion du stockage.

Une date lointaine ne créait pas de créance

Expires pouvait demander une durée inhabituellement longue. Cela ne signifiait pas qu’un auteur obtenait un droit sur le disque de tous les destinataires. Une échéance lointaine disait seulement que, selon lui, l’article garderait sa valeur.

L’inverse est tout aussi important. Une échéance proche ne garantissait pas l’effacement universel. Un site pouvait conserver l’article dans une archive, un dossier d’incident ou un corpus local. Des relais, des citations et des copies privées pouvaient survivre. Aucun champ ne dressait la liste de ces dépositaires ni ne recueillait leur acquittement.

La frontière utile sépare donc l’horizon informationnel de la décision de garde. Le premier est rédigé une fois et recopié avec l’article. La seconde doit être prise partout où les octets sont réellement contrôlés.

La définition moderne limite soigneusement l’autorité

La RFC 5536 décrit Expires comme le moment où l’auteur estime que l’article n’est plus pertinent et pourrait utilement être retiré. Elle souligne l’intérêt du champ pour une durée exceptionnellement courte ou longue.

Le sujet grammatical compte : c’est l’auteur qui estime. Le texte ne dit pas qu’il réserve du stockage jusqu’à la date, ni que tous les agents doivent supprimer au même instant. Il transporte le jugement que l’auteur est légitime à formuler.

Un article peut donc disparaître avant l’échéance sous l’effet d’une règle locale, ou rester disponible après elle dans une archive. Aucun de ces résultats ne suffit à déclarer la date mensongère. Ils montrent que pertinence et garde sont deux états différents.

NNTP répondait au nom d’un serveur, pas du réseau entier

La RFC 3977 fait de la disponibilité une observation locale. GROUP décrit les articles actuellement disponibles dans un groupe sur le serveur interrogé. ARTICLE peut répondre 423 lorsqu’un numéro local manque, ou 430 lorsque ce serveur ne possède pas le Message-ID demandé.

Ces réponses ne prouvent pas que l’article n’a jamais existé, qu’il a été supprimé partout ou que Expires a déclenché son retrait. Un autre serveur peut encore le fournir. Cette modestie est une qualité : le protocole ne transforme pas une observation locale en certificat mondial d’effacement.

La RFC 5537 formule la limite architecturale pour les demandes de restriction de conservation : leur respect dépend des sites receveurs et le protocole ne peut pas l’imposer. Son passage vise Archive et Distribution, sans redéfinir Expires, mais il confirme que la syntaxe transportée ne prend pas possession des systèmes de garde.

Un nom enregistré, aucun résultat certifié

Le registre IANA des champs de message classe Expires comme champ Netnews standard et renvoie à la RFC 5536. Il stabilise le nom et sa référence, pas les pratiques actuelles des fournisseurs, leurs quotas ni leurs archives.

L’apport historique d’Usenet tient à cette sobriété. Le réseau a permis à celui qui connaît la durée d’utilité d’exprimer son savoir, tout en laissant la conservation à celui qui détient le disque. La date pouvait circuler précisément parce qu’elle ne prétendait pas posséder l’espace où elle arrivait.