Résumé

  • NNTP distingue le Message-ID, unique à l’échelle mondiale, de la clé locale formée par un groupe et un numéro d’article. Un article multiposté peut donc avoir plusieurs numéros sans devenir plusieurs articles.
  • Xref rassemble les emplacements attribués par le dernier serveur afin qu’un logiciel de lecture ne traite pas plusieurs fois le même multipostage.
  • Un serveur de consultation retire normalement le Xref reçu et inscrit le sien. Ce remplacement modifie une fiche de rangement locale, non l’identité ni le corps de l’article.

Le même texte, un autre numéro

Une lectrice termine un article dans un groupe de discussion. Elle ouvre ensuite un second groupe auquel elle est abonnée et retrouve le même titre, le même corps, mais un autre numéro. L’interface doit-elle y voir une copie, une republication ou un nouvel article ?

Dans Netnews, l’explication la plus juste peut être un multipostage : un seul article a été adressé à plusieurs groupes. Le serveur en conserve généralement un exemplaire et l’indexe à une position propre à chacun des groupes. Si le lecteur mémorise seulement le premier numéro, la seconde coordonnée ressemble à tort à une seconde œuvre.

Xref transforme cette ambiguïté en information exploitable. Le champ nomme le serveur qui l’a produit, puis énumère les groupes et les emplacements où ce serveur a classé l’article. Il ne crée pas une nouvelle identité. Il donne la carte locale qui ramène plusieurs rayonnages au même article.

Cette séparation est structurante. L’identité répond à la question « quel article a traversé le réseau ? ». L’emplacement répond à « où ce serveur le présente-t-il maintenant ? ». Un système distribué fiable conserve ces deux réponses sans donner à l’une l’autorité de l’autre.

Trois clés pour trois questions

Le protocole NNTP décrit dans le RFC 3977 utilise trois familles de clés. Le Message-ID identifie l’article de manière globale. Une deuxième clé associe le nom d’un groupe à un numéro d’article dans ce groupe. La troisième est l’horodatage d’arrivée tenu par le serveur.

La clé groupe-numéro est rigoureuse dans son domaine. Sur un serveur donné, un numéro ne peut désigner qu’un article dans un groupe, et un article ne peut recevoir deux numéros dans ce même groupe. Mais un article multiposté appartient à plusieurs groupes : il peut donc avoir plusieurs clés et un numéro différent dans chacun.

La portée s’arrête au serveur. Le RFC précise que la même paire groupe-numéro peut désigner des articles différents sur deux serveurs. Les numéros suivent l’ordre d’arrivée local. Changer de serveur, c’est changer de repère, même si le Message-ID reste inchangé.

La commande GROUP renvoie des marques d’eau basse et haute ainsi qu’une estimation du nombre d’articles. Elle ne garantit pas que chaque numéro intermédiaire soit occupé. Un article peut être retiré ; un article antérieur peut aussi être rétabli sous son ancien numéro dans les limites du protocole. Une lacune n’atteste donc pas une disparition mondiale, et un grand numéro n’est pas une chronologie universelle.

Un article, plusieurs rayons

Le RFC 5536 distingue expressément le multipostage d’un article vers plusieurs groupes de la publication de plusieurs articles ayant le même texte. Dans le premier cas, le Message-ID reste celui d’un article unique, entouré de plusieurs entrées d’index.

La syntaxe de Xref épouse cette architecture. Après l’identité du serveur viennent une ou plusieurs localisations, chacune associant un groupe à un localisateur. Le localisateur NNTP traditionnel est un numéro décimal, mais le format exact peut dépendre de l’implémentation.

Le nom du serveur fixe le système de coordonnées. Sans lui, une position qui paraît identique peut mener ailleurs sur un autre service. Avec lui, le logiciel sait que plusieurs emplacements dans la vue d’un même serveur convergent vers un article.

Le RFC explique que les agents utilisateurs emploient souvent Xref pour ne pas traiter plusieurs fois un article multiposté. Après une lecture dans un groupe, l’application peut aligner l’état des autres positions reliées. Elle respecte ainsi l’intention du multipostage : une intervention atteint plusieurs publics, mais ne devient pas pour autant plusieurs interventions indépendantes.

La destination déclarée n’est pas le classement constaté

Le champ Newsgroups déclare les groupes auxquels l’article a été envoyé. Xref décrit les groupes et positions où le dernier serveur l’a effectivement classé. Le RFC 5536 admet explicitement que ces listes diffèrent.

La différence donne de la visibilité à la politique locale. Un serveur peut ne pas transporter tous les groupes, refuser un classement selon ses règles ou modifier ce qui reste disponible avec la conservation et la modération. Copier la déclaration du posteur dans la fiche locale masquerait ces choix.

Les deux champs ont donc des autorités complémentaires : l’un transporte la distribution déclarée ; l’autre matérialise la vue de stockage. Une constatation locale ne doit pas être présentée comme l’intention de l’auteur, ni l’intention comme une preuve de stockage.

Une fiche conçue pour être réécrite

Le RFC 1036, publié en 1987, décrivait déjà Xref comme le nom de l’hôte suivi de couples groupe-numéro issus du répertoire de stockage. Il disait que l’information n’avait de valeur que pour le système local et ne devait pas être transmise. Son exemple plaçait un seul message à deux numéros différents dans deux groupes.

L’architecture ultérieure a organisé le passage du champ entre composants sans en faire une identité permanente. Le RFC 5537 autorise un relais à supprimer un Xref existant et à en ajouter un pour son propre usage. Un serveur de consultation doit normalement enlever le champ entrant — sauf configuration spéciale de conservation des localisateurs du site émetteur — puis peut, et le fait habituellement, inscrire sa propre vue avant le stockage.

Cette mutation n’est pas une altération de l’article. Le même texte normatif interdit aux relais et serveurs de modifier l’article, à l’exception étroite de Path et Xref, et interdit toute modification du corps. La fiche de rangement change ; l’article qu’elle décrit demeure.

La possibilité de réécrire le champ à une frontière de garde révèle donc son véritable sujet : la décision de classement du serveur, et non la création durable de l’auteur.

Une portée, pas un sceau

Le nom du serveur pourrait être pris pour une preuve d’origine. Les spécifications ne lui attribuent pas ce pouvoir. Il indique dans quel repère lire les localisateurs ; il n’est ni signature cryptographique, ni vérification de l’auteur, ni certificat du premier point d’entrée.

Le droit accordé aux relais et serveurs de régénérer le champ interdit de le traiter comme une provenance immuable. Dire qu’il n’authentifie pas est ici une conclusion prudente tirée des règles de réécriture et de l’absence de contrat d’authentification. Xref témoigne utilement d’une vue de service, dans le contexte de confiance de ce service seulement.

Le registre IANA des champs d’en-tête classe toujours Xref comme champ standard Netnews et renvoie au RFC 5536. Message-ID et Newsgroups disposent de leurs propres entrées. Le registre stabilise le vocabulaire ; il ne fusionne pas identité, distribution déclarée et emplacement local.

Ce que signifiait vraiment le numéro

Xref n’a pas inventé un identifiant plus fort. Il a donné à Usenet une manière d’assumer qu’un article possède plusieurs coordonnées et que le prochain serveur peut remplacer ces coordonnées sans remplacer l’article.

Confondre emplacement et identité fabrique des doublons dès qu’un article touche plusieurs groupes. Confondre identité et emplacement suppose, à l’inverse, qu’un nom mondial fournit une adresse universelle. NNTP ne l’a jamais promis.

Les sources officielles n’établissent ni la diffusion actuelle de Xref dans les clients, ni les pratiques d’un fournisseur particulier. Elles ne révèlent pas pourquoi un numéro local précis a disparu. Elles établissent la frontière : Message-ID dit de quel article il s’agit ; Xref dit où ce serveur l’a classé. Sa force vient de cette retenue.