Résumé

  • 340 autorisait l’envoi du texte ; seul le verdict 240 ou 441, émis après le dernier point, décidait de la tentative.
  • Une coupure pouvait faire disparaître la réponse positive sans annuler l’injection déjà accomplie.
  • Réemployer le même Message-ID permettait de reconnaître une reprise comme le même article, sans confondre acceptation, modération et disponibilité pour les lecteurs.

La panne la plus gênante arrivait après tout le travail

Le client n’a plus aucun octet à transmettre. De son point de vue, il ne manque qu’une réponse. Du point de vue du serveur, pourtant, l’article a pu être validé, accepté et confié à l’étape suivante. Si 240 s’est perdu sur le chemin du retour, les deux côtés détiennent des histoires différentes mais toutes deux plausibles.

Renvoyer avec un nouveau nom produit peut-être deux articles. Ne rien faire abandonne peut-être le seul. Cette symétrie explique pourquoi un simple bouton « réessayer » était une décision de protocole, non une commodité d’interface.

Deux réponses découpaient POST en deux engagements

Dans le RFC 977, POST commence par une permission. 340 invite le client à fournir l’article ; 440 refuse l’usage. Après les en-têtes, le corps et la ligne terminale, une seconde famille de codes apparaît : 240 pour la réussite, 441 pour l’échec.

Le premier oui ne signifie donc pas « article reçu ». Il signifie « présentez-le ». Le RFC 3977 conserve cette construction, interdit le pipeline de POST et précise que 340/440 répondent à la commande, tandis que 240/441 suivent le transfert complet. La chronologie place l’autorité du verdict après le corps.

Un 240 engage le serveur à rendre l’article disponible localement et/ou à le transférer, selon ce qui convient, éventuellement après d’autres traitements et sous réserve d’erreurs imprévues. Un article indésirable devrait recevoir 441, plutôt qu’être accepté puis jeté silencieusement.

Être accepté ne voulait pas dire être déjà lisible

La norme ajoute aussitôt une limite. Le client ne peut tenir le transfert pour réussi sans réponse affirmative. Même avec cette réponse, il ne doit pas supposer que les lecteurs voient déjà l’article ; il faut le vérifier, par exemple avec STAT.

Cette distinction suit l’architecture décrite par le RFC 5537. L’agent de publication prépare un proto-article. L’agent d’injection le contrôle et l’introduit dans le réseau. Un modérateur peut intervenir. Des agents de relais le propagent et un agent de service le présente aux lecteurs. Un logiciel peut réunir ces fonctions, mais leurs preuves ne deviennent pas interchangeables.

Une absence immédiate dans le service de lecture peut ainsi décrire une file de modération, un traitement encore inachevé ou ce seul serveur. Elle ne reconstitue pas le verdict perdu de la session précédente.

Le protocole préférait l’identité à une recherche trop précoce

Le RFC 3977 envisage exactement la coupure avant réception de la réponse. Une réponse affirmative a pu être envoyée puis perdue. Lors de la session suivante, le client devrait vérifier la publication avant de renvoyer, ou garantir que le serveur attribuera le même Message-ID à la nouvelle tentative.

La seconde méthode est préférée, justement parce que l’article peut ne pas encore être offert à la lecture — la modération fournit l’exemple explicite. La norme refuse donc de transformer « je ne le vois pas » en « il n’existe pas ».

Son annexe recommande que les articles de courrier ou de Netnews portent un champ Message-ID identique à chaque tentative. Le serveur devrait reconnaître les deux soumissions comme identiques et conserver le même identifiant. Le nom devient le point de raccord entre deux épisodes dont le résultat du premier reste inconnu.

Un même nom n’était pas une preuve magique

Le RFC 5536 définit Message-ID comme un identifiant unique et souligne que Netnews dépend particulièrement de l’unicité et de la comparaison rapide. Le RFC 5537 montre la raison opérationnelle : la diffusion par inondation offre souvent le même article par plusieurs voisins ; les serveurs gardent donc un historique des identifiants déjà vus.

Cette mécanique ne signe pas l’auteur et ne garantit pas l’intégrité. Elle ne prouve pas non plus que le premier POST a réussi. Elle dit seulement que la reprise revendique le même article. Si le client fabrique un nouvel identifiant, il transforme une tentative ambiguë en une deuxième entité que les modérateurs, relais et archives peuvent traiter séparément.

La suppression des doublons reste bornée : l’historique ne peut croître éternellement, les politiques locales diffèrent et une panne peut couper plusieurs étapes. L’identité stable ne promet donc pas « exactement une fois ». Elle rend la réparation observable et limite la duplication que le client peut créer lui-même.

Le registre IANA des paramètres NNTP enregistre POST et renvoie au RFC 3977. Il nomme la capacité ; il ne certifie ni l’autorisation de publier sur un serveur précis, ni sa durée d’historique, ni la visibilité actuelle d’un article.

L’héritage de cette règle tient dans une discipline : quand l’engagement peut avoir eu lieu mais que son accusé a disparu, ne pas inventer une nouvelle identité pour le même travail. NNTP ne supprimait pas le doute. Il empêchait le doute de se multiplier.

Sources