Résumé

  • IHAVE présente d’abord un Message-ID. Le serveur destinataire peut connaître déjà l’article, demander un nouvel essai ou réclamer seulement alors le texte complet.
  • La réponse qui réclame le corps n’est pas une acceptation finale. Après lecture des en-têtes et du contenu, le serveur peut accepter, différer ou refuser selon ses ressources et sa politique locale.
  • L’extension de diffusion en continu a réparti ces décisions entre CHECK et TAKETHIS. Elle a supprimé de l’attente sur le réseau, sans retirer au destinataire la maîtrise de son stockage.

Le prix d’une question

Les premiers réseaux de nouvelles n’avaient aucune raison de payer deux fois pour le même article. Une liaison pouvait être intermittente, facturée ou simplement trop lente pour recevoir chaque corps avant de découvrir qu’une copie existait déjà. Le remède consistait à envoyer une empreinte nominale très courte, puis à attendre que le voisin exprime un besoin.

RFC 1036 décrit ainsi les anciens messages de contrôle ihave et sendme. Un site annonçait une liste de Message-IDs ; l’autre réclamait ceux qui manquaient à sa collection. Plusieurs identifiants pouvaient être réunis, car l’offre d’un seul identifiant risquait de coûter presque autant que le transport d’un article bref.

Cette arithmétique explique la forme du protocole, mais pas toute sa portée. L’identifiant suffisait pour consulter l’historique des doublons. Il ne permettait pas d’évaluer des groupes, une distribution, des en-têtes défectueux ou la taille réelle. Économiser le corps exigeait donc une décision préliminaire ; juger l’article exigeait une seconde décision.

Le premier oui voulait dire « montrez-le »

RFC 977 a transformé le principe en commande IHAVE. Le client propose un Message-ID. Le serveur répond 335 s’il veut recevoir le corps, 435 s’il n’en veut pas, ou 436 si une nouvelle tentative ultérieure reste justifiée.

Le code 335 ressemble à un accord, mais son objet est limité : il autorise l’étape coûteuse. Une fois le texte transmis, un second code apparaît. 235 constate la réussite du transfert, 436 une difficulté temporaire, et 437 un refus définitif pour cette tentative. Le serveur peut alors invoquer des groupes ou une distribution non désirés, un manque de place, une longueur excessive ou des en-têtes illisibles.

Autrement dit, le destinataire peut honnêtement demander à voir un article et honnêtement le refuser après l’avoir vu. Le protocole ne considère pas cette séquence comme une contradiction. Il la rend observable.

Trois identifiants, un seul corps

Prenons trois offres successives. Pour la première, l’historique local indique une copie : 435 évite tout transfert. Pour la deuxième, une saturation provisoire conduit à 436 : le corps ne part pas, mais l’offre peut revenir. Pour la troisième, 335 ouvre le passage.

Le corps du troisième article arrive alors avec des informations absentes de l’offre. Un filtre détecte une distribution exclue ; le verdict final devient 437. Ce résultat n’annule pas la logique du premier échange. Le premier seuil répondait à la question « cela vaut-il la peine d’envoyer les octets ? ». Le second répond à « ces octets peuvent-ils entrer ici ? ».

Un tableau de bord qui n’enregistre que le dernier code perd le gain de déduplication. Celui qui n’enregistre que le premier invente une acceptation qui n’a jamais eu lieu. La preuve correcte relie l’identifiant, les deux réponses et les octets effectivement reçus.

La nouvelle norme a refusé les succès supposés

RFC 3977 maintient cette conversation en deux temps. IHAVE ne se prête pas au pipelinage : le client attend la première réponse avant d’envoyer l’article, puis la seconde avant de clore l’opération. L’absence de réponse doit être traitée comme un échec temporaire, non comme un succès implicite.

Le texte sépare aussi le transit de l’injection. IHAVE transporte entre pairs un article déjà formé ; POST remet un nouvel article au système. Cette différence situe l’autorité. Le pair récepteur ne valide pas l’auteur pour le monde entier : il décide si cet objet de transit convient à son propre service et à l’accord de diffusion qui le lie à l’émetteur.

La reconnaissance des offres répétées réduit les doublons, mais elle ne garantit pas que deux corps différents portant le même Message-ID seront équivalents. Le suivi doit donc conserver à la fois l’identité annoncée et une empreinte des octets reçus.

Un code positif n’était pas un reçu d’archive

La nuance la plus sévère figure déjà dans RFC 977 : après avoir répondu 235, un serveur peut découvrir ultérieurement que l’article ne convient pas et l’éliminer sans autre signal. Le succès clôt l’échange NNTP défini ; il ne promet pas une conservation éternelle.

RFC 4644 conserve cette limite pour la diffusion en continu. Même un 239 positif après TAKETHIS peut être suivi d’un rejet silencieux pendant un traitement ultérieur. Les codes de succès attestent donc une frontière transactionnelle, non une chaîne complète de garde.

Pour prouver une présence durable, il faut une observation supplémentaire : article dans le spool, article accessible au lecteur, ou nouvelle offre vers un autre pair. Aucun de ces faits ne découle automatiquement du seul verdict de transfert.

CHECK a raccourci l’attente

Sur une liaison à grande latence, attendre deux réponses pour chaque article sous-utilisait le canal. RFC 4644 a introduit CHECK, qui demande si un Message-ID est souhaité, et TAKETHIS, qui envoie le corps et recueille le verdict final. Plusieurs commandes peuvent ainsi avancer sans rester bloquées l’une derrière l’autre.

La première réponse reste toutefois indicative. Le destinataire ne doit pas supposer que l’émetteur respectera chaque réponse à CHECK. Selon une politique de site ou une stratégie adaptative, TAKETHIS peut même arriver sans CHECK préalable. Le récepteur conserve alors la capacité de refuser le corps.

La diffusion en continu modifie donc le coût temporel, pas la répartition des pouvoirs. Elle amortit la latence et remplit mieux la liaison. Elle ne transforme ni l’offre en ordre, ni l’accusé en titre de propriété.

L’accord de pair à pair restait ailleurs

RFC 5537 replace le mécanisme dans l’architecture Netnews. Les vieux messages de contrôle ihave et sendme étaient devenus largement obsolètes sur Internet, même s’ils survivaient dans certains environnements UUCP. Les sites modernes organisaient leurs échanges par des accords de diffusion et choisissaient les transports adaptés.

Ces accords définissaient les hiérarchies, distributions ou catégories d’articles qu’un pair souhaitait recevoir. La grammaire de IHAVE ne les remplaçait pas. Elle exécutait une petite négociation à l’intérieur d’une relation opérationnelle plus large.

L’histoire de IHAVE est donc celle d’une discipline des limites. Poser une question légère avant de déplacer un objet coûteux fut une optimisation. Maintenir un second verdict après l’arrivée de l’objet fut une règle de gouvernance. Refuser d’assimiler un succès de transfert à une garde perpétuelle fut une règle de preuve.

Sources