Résumé

  • Le champ Date désigne le moment où le créateur estime le message terminé et prêt à partir, non celui de son transport effectif.
  • Les relais Netnews doivent borner leur historique des Message-ID déjà vus. Confondre ancienneté de rédaction et ancienneté dans le réseau peut faire rejeter un texte tout juste injecté.
  • Injection-Date ajouta l’observation du point d’entrée sans modifier Date. La précision opérationnelle augmenta sans transformer cette heure en preuve d’auteur, d’exactitude ou d’arrivée universelle.

Deux vendredis dans un même lundi

Une personne termine un article en déplacement. Son logiciel inscrit le lundi dans Date, puis conserve le texte faute de connexion. Le vendredi, le posting agent atteint enfin un serveur de news.

Pour l’auteur, lundi est la réponse honnête : c’est le moment où le texte a été déclaré fini. Pour un relais, cette valeur peut ressembler à celle d’un ancien article qui revient après la suppression de sa trace dans l’historique. Le premier veut préserver la chronologie ; le second doit protéger une diffusion en flood-fill contre les répétitions.

Réécrire vendredi faciliterait peut-être le passage, mais falsifierait l’événement initial. Garder lundi peut provoquer un refus « stale » dans un logiciel ancien. Ce conflit n’était pas une querelle de format. Il venait de deux décisions attachées au même nombre.

La réponse de Netnews fut d’ajouter une horloge au lieu de corriger l’autre.

Ce que Date avait promis

Dans la RFC 1036 de 1987, Date, auparavant Posted, désignait la date de publication initiale sur le réseau et devait rester inchangée pendant la propagation. La stabilité empêchait chaque intermédiaire de recommencer l’histoire à son propre passage.

La RFC 5322 distingue ensuite plus nettement achèvement et transport. L’origination date correspond au moment où le créateur indique que le message est complet et prêt à entrer dans la distribution. L’exemple d’un ordinateur portable hors ligne est décisif : l’heure appartient à la mise en file locale, pas à la connexion ultérieure.

Cette sémantique donne une valeur documentaire à Date. Elle révèle aussi sa limite opérationnelle. L’horloge du créateur peut dériver, mentir ou simplement précéder de plusieurs jours la première transmission. Même exact, le champ ne dit pas depuis combien de temps l’article circule dans Netnews.

L’historique ne pouvait croître sans fin

Dans Netnews, plusieurs relaying agents et serving agents échangent les mêmes articles. La RFC 5537 leur impose de mémoriser ce qu’ils ont déjà accepté et de refuser une nouvelle offre du même article. Le Message-ID sert de clé.

Conserver tous les identifiants pour toujours n’est pourtant pas viable. Le protocole autorise un intervalle de coupure. Un article plus ancien peut être refusé ; les entrées d’historique correspondantes peuvent alors disparaître, puisque le contrôle de date arrêtera leur retour. Le texte cite sept jours au moins comme convention Usenet, tout en avertissant qu’une fenêtre plus courte que la propagation normale peut éliminer un article jamais vu.

La date n’établit donc pas qu’il s’agit d’un doublon. Elle borne la durée pendant laquelle le serveur garde la preuve nécessaire pour reconnaître un doublon. Réduire la fenêtre économise des ressources mais augmente le risque de faux refus ; l’allonger protège les chemins lents mais coûte davantage.

Avec la seule date de composition, le délai de l’auteur contaminait ce calcul de réseau.

Une heure d’entrée qui ne corrige pas l’auteur

La RFC 5536 définit Injection-Date comme la date et l’heure auxquelles l’article est injecté dans le réseau. Le but est explicite : pour détecter les articles anciens, un serveur peut employer une heure ajoutée à l’injection plutôt que celle inscrite par le user agent pendant la composition.

Le champ doit être inséré lors de l’injection. Les agents doivent néanmoins accepter son absence, car les logiciels antérieurs ne le connaissaient pas. En pareil cas, les règles retombent sur Date. Cette compatibilité permet une adoption progressive, au prix de décisions parfois différentes entre voisins.

La séparation serait vide si l’entrée en réseau pouvait réécrire l’histoire. La RFC interdit donc de modifier une Date déjà présente lors de l’ajout d’Injection-Date. Elle précise même qu’une horloge mal synchronisée peut rendre la seconde valeur antérieure à la première. Une comparaison négative signale d’abord deux horloges, non un voyage temporel.

Le nouveau nom remplaça NNTP-Posting-Date, utilisé sans spécification et désormais déprécié. La normalisation rendit la fonction commune ; elle ne rendit pas les pendules communes.

Une troisième heure restait locale

Pour l’optimisation courante de l’historique, RFC 5537 appelle « date » de l’article Injection-Date lorsqu’elle existe, sinon Date. Relais et serveurs l’examinent pour les valeurs excessivement futures et pour la fenêtre de coupure qu’ils ont choisie.

Une autre stratégie élimine les traces selon l’instant où le serveur a vu l’article pour la première fois. Dans le schéma décrit, la conservation doit alors dépasser la coupure d’au moins 24 heures afin d’absorber la marge admise pour les dates futures.

La RFC 3977 conserve encore une autre mesure : chaque serveur possède un arrival timestamp et attribue ses numéros d’article dans cet ordre. Ce temps n’appartient qu’au serveur observateur.

Les trois valeurs répondent à trois propriétaires de faits :

  • Date conserve la déclaration d’achèvement du créateur ;
  • Injection-Date situe le passage réglementé vers Netnews ;
  • l’arrivée locale situe l’accueil par un serveur donné.

Les fusionner ferait porter un retard de chemin à l’auteur, ou un délai d’écriture au réseau.

Plusieurs portes, un seul âge

Le même article pouvait être offert à plusieurs injecting agents, par exemple pour relier des réseaux supposés disjoints ou obtenir de la redondance. L’objectif restait un article unique, reconnu par le même Message-ID quand les chemins se rejoignaient.

RFC 5537 exige donc que Message-ID, Date et Injection-Date soient présents et identiques dans toutes les offres. Lorsqu’un article déjà injecté est reconverti en proto-article pour une autre entrée, ces trois champs doivent rester inchangés. Actualiser l’injection à chaque porte donnerait artificiellement une nouvelle jeunesse au même article et affaiblirait la suppression des boucles.

Le champ est ainsi plus qu’un tampon « maintenant ». Il devient une partie stable de l’âge partagé lorsque plusieurs entrées représentent le même acte de publication.

La dette de compatibilité

Les anciens serveurs continuent d’ignorer Injection-Date et de juger l’ancienneté avec Date. RFC 5537 reconnaît qu’un texte composé longtemps avant son envoi peut donc mal se propager malgré la présence du nouveau champ.

Un posting agent devrait ajouter l’heure d’injection avant remise lorsque la composition date de plus d’un jour ; il doit le faire en cas d’injection multiple. L’injecting agent contrôle aussi les valeurs trop futures ou trop anciennes, puis ajoute l’heure courante lorsque les conditions du protocole l’exigent. Proche du poster, il peut encore expliquer utilement un refus.

Mais aucune de ces obligations ne transforme les pairs anciens. La transition transporte deux qualités de preuve dans le même article et accepte qu’elles ne produisent pas partout la même décision.

Une date standard n’est pas une attestation

Injection-Date reste l’affirmation temporelle d’un agent au point d’entrée. Ce n’est ni une signature, ni une preuve d’auteur, ni une garantie de synchronisation. Le champ n’indique pas l’approbation d’un modérateur, l’heure de lecture, toutes les arrivées ultérieures ou la future suppression locale.

Le registre IANA des champs de message classe aujourd’hui Injection-Date comme champ Netnews standard et renvoie à RFC 5536. Le registre stabilise le vocabulaire. Il ne certifie ni une valeur particulière ni le déploiement de chaque serveur.

L’innovation historique tient dans cette retenue. La chronologie du créateur resta visible ; le réseau ajouta l’heure nécessaire à sa propre décision ; chaque serveur garda encore son arrivée. La deuxième date fut utile précisément parce qu’elle refusa de devenir la première.