Résumé

  • NNTP réunissait distribution, recherche, lecture et publication, sans obliger un serveur à offrir chaque fonction à toute connexion.
  • MODE READER demandait à un serveur commutable de quitter le transit pour la lecture ; la nouvelle réponse CAPABILITIES faisait foi sur les commandes disponibles.
  • La transition pouvait réinitialiser l’état, ne pouvait être ni anticipée dans un pipeline ni répétée, et ne conférait à elle seule ni publication, ni identité, ni confidentialité.

Deux listes vraies à deux instants différents

À l’ouverture, un serveur annonce IHAVE et MODE-READER, mais pas READER. Il se présente comme un interlocuteur de transit capable de changer de rôle. Après MODE READER, une nouvelle liste affiche READER, peut ajouter NEWNEWS ou des variantes de LIST, et peut retirer IHAVE.

Les deux listes sont exactes. Elles ne parlent simplement pas du même état. Conserver la première comme une propriété permanente du nom d’hôte reviendrait à confondre l’identité d’un logiciel avec l’autorité d’une session.

Cette ambiguïté venait de l’ambition initiale de NNTP. Le RFC 977 de 1986 couvrait la distribution, l’interrogation, la récupération et la publication des articles. Un poste de travail pouvait consulter un dépôt central ; deux machines coopérantes pouvaient s’échanger des copies. Un même protocole desservait donc le lecteur et le réseau de diffusion.

La grammaire commune n’abolissait pas les différences de coût et de confiance. Une commande de lecture consulte groupes, index et corps. Un feed de transit injecte des articles selon une relation entre opérateurs. Les deux usages pouvaient partager un port tout en exigeant des politiques différentes.

L’exploitation nomma le rôle avant la norme

Le RFC 2980 ne proposait pas un modèle neuf ; il consignait des extensions courantes. MODE READER, apparu dans INN, permettait au client d’indiquer qu’il était un lecteur et à certains serveurs de se reconfigurer pour mieux répondre aux commandes correspondantes.

Le mécanisme venait ainsi d’une séparation déjà réelle derrière le socket. Les déploiements avaient plusieurs métiers ; il leur manquait une frontière interopérable. La commande n’affirmait pas une identité humaine. Elle demandait un traitement particulier pour cette connexion.

Le même texte oppose cette pratique à SLAVE, peu implémenté depuis le RFC 977. Il ne faut pas transformer cette remarque en symétrie inventée. Elle prouve seulement que le besoin durable fut l’entrée explicite dans le rôle de lecture.

La capacité appartient à l’état courant

Le RFC 3977 distingue serveurs de lecture, de transit et commutables. En transit, le dernier doit annoncer MODE-READER et ne pas annoncer READER. Après une commutation réussie, il fait l’inverse ; il peut aussi cesser d’offrir IHAVE.

Le protocole exige que CAPABILITIES décrive exactement ce qui est utilisable dans l’état présent. Une transition de rôle, une authentification ou TLS peut donc modifier la réponse pendant une seule session. Une cache de capacités n’est sûre que si son propriétaire connaît la frontière qui l’invalide.

Le registre NNTP Parameters de l’IANA fixe le sens de MODE-READER, READER, IHAVE et STREAMING. Il coordonne un vocabulaire ; il ne certifie ni déploiement actuel ni politique locale.

La commutation devait arrêter le pipeline

MODE READER ne peut pas être pipeliné. Le client doit attendre son résultat avant d’envoyer des commandes de lecture. Sinon, un serveur qui purge des octets autour du changement et un client qui associe déjà les réponses à GROUP ou NEXT n’habitent plus la même conversation.

La commande ne peut survenir qu’une fois, et jamais après une commande de sécurité ou de confidentialité. Le serveur peut remettre son état à celui qui suivait immédiatement l’ouverture, puis basculer. La sélection d’un groupe, l’article courant ou d’autres hypothèses ne survivent donc pas par simple continuité de TCP.

Une transition de rôle est une frontière de parseur et de preuve. Les octets suivants doivent être interprétés par le même automate des deux côtés ; les pouvoirs précédents doivent expirer avant que les nouveaux commencent.

Lire ne donnait pas le droit de publier

Deux réponses positives existent : 200 autorise la publication et 201 l’interdit. Toutes deux ouvrent le mode lecture. Un 502 signifie que le service de lecture est durablement indisponible et impose la fermeture de la connexion.

Le rôle, l’écriture et la disponibilité sont ainsi trois décisions. Déduire POST du mot « lecteur » ajouterait un privilège que le serveur n’a pas accordé. La liste courante peut fournir un détail plus précis que le texte général d’un accueil.

La sécurité suivait ses propres transitions

Un exemple du RFC 3977 montre STARTTLS seulement après le passage en lecture. Le RFC 4642 définit séparément TLS et le RFC 4643 l’authentification. Chacun peut à son tour changer les capacités.

MODE READER ne chiffre rien et ne prouve personne. TLS ou une identité authentifiée ne crée pas non plus automatiquement le rôle de lecteur. Le RFC 4644 place STREAMING dans le monde des feeds. Séparer rôle, identité, protection et droit d’écriture rend possible le moindre privilège.

Une frontière plutôt qu’une préférence d’architecture

Un seul point d’entrée facilite la découverte et la migration, mais concentre les erreurs d’état. Des points distincts peuvent rendre les rôles plus visibles, au prix d’un déploiement plus complexe. Les RFC ne mesurent pas la pratique actuelle et ne tranchent pas universellement.

Le legs de MODE READER est plus modeste : quand un canal change de métier, nommer la transition, attendre son résultat, publier les nouvelles capacités et dire quel état peut disparaître. Un socket vivant ne prolonge pas automatiquement une ancienne autorité.

Sources et limites

Ces sources établissent les règles et leur histoire, pas la part de marché, le volume de trafic, l’architecture interne d’un produit ni la politique d’un opérateur. Le registre n’est pas une preuve d’usage, et MODE READER n’est ni authentification, ni chiffrement, ni permission de publier.