Résumé

  • LIST ACTIVE répondait à la question immédiate — quels groupes ce lecteur peut-il sélectionner ici ? — tandis que LIST ACTIVE.TIMES exposait une mémoire locale facultative.
  • L’archive pouvait oublier un groupe encore actif et garder la trace d’un groupe retiré ; une ligne présente ou absente n’avait donc jamais valeur de registre universel.
  • L’heure concernait la création sur ce serveur et le créateur n’était qu’un texte descriptif, non une identité authentifiée ou un titre de propriété.

Le groupe vivant et l’archive orpheline

Deux réponses suffisent pour comprendre la séparation. Dans la première, LIST ACTIVE montre un groupe disponible, ses bornes locales d’articles et son statut de publication. Dans la seconde, le même nom manque. Plus loin apparaît pourtant un groupe ancien, avec une heure et un créateur, alors que le catalogue courant ne le propose plus.

RFC 3977 exige que LIST ACTIVE, pour un serveur offrant le service de lecture, contienne tous les groupes que le client peut sélectionner. LIST ACTIVE.TIMES reste facultatif. Il associe un nom à l’heure où ce serveur a créé le groupe et à un texte censé décrire l’entité créatrice.

Le document interdit précisément de confondre ces surfaces. L’archive peut omettre les renseignements indisponibles, perdre toute sa partie la plus ancienne et contenir des groupes que le serveur ne propose plus. Le client ne doit supposer ni son exhaustivité ni sa concordance avec le catalogue actif.

Le présent avait son propre contrat

Dans RFC 977, la commande LIST renvoyait les groupes valides du serveur. Chaque ligne donnait le nom, les premier et dernier numéros d’article connus et l’autorisation habituelle de publier. Une liste vide signifiait qu’aucun groupe valide n’était actuellement annoncé.

Cette réponse servait à agir. Le lecteur devait savoir où GROUP pouvait le conduire, et non reconstituer l’histoire institutionnelle du nom. Un groupe supprimé cessait de faire partie du catalogue même si un ancien fichier se souvenait de lui. Inversement, un groupe restauré après migration pouvait fonctionner sans que son heure de création d’origine ait suivi.

La disponibilité était déjà locale. Les numéros d’article, les droits du client et le contenu du catalogue pouvaient diverger d’un serveur à l’autre.

Une pratique UNIX devint vocabulaire commun

RFC 2980 documenta LIST ACTIVE.TIMES parmi les extensions courantes. Certains systèmes de transport conservaient un fichier active.times : nom du groupe, instant de création sur ce serveur, description du créateur. L’extension venait de l’implémentation UNIX de référence et pouvait échouer lorsque l’information n’existait pas.

Ce parcours est essentiel. Le protocole n’a pas inventé une autorité mondiale des groupes. Il a rendu interrogeable un fichier d’exploitation local, puis lui a donné une sémantique transportable.

RFC 3977 resserra encore cette sémantique. L’instant n’était pas « la naissance mondiale » du nom, mais sa création ici. Le troisième champ était du texte libre, souvent présenté comme une boîte aux lettres, pas un justificatif cryptographique. La normalisation transforma une pratique en interface ; elle ne transforma pas la mémoire locale en souveraineté.

Une trace positive ne promettait aucun service

Un enregistrement historique peut survivre à son objet opérationnel. Le groupe peut avoir été retiré, le flux interrompu, le stockage vidé ou l’accès refusé à ce lecteur. La ligne ancienne peut néanmoins rester dans ACTIVE.TIMES.

Elle prouve alors quelque chose de limité : le serveur conserve une association entre ce nom, une heure locale et une description. Elle ne garantit ni que GROUP réussira, ni que des articles existent encore, ni qu’un autre serveur partage l’information. Elle n’accorde surtout pas un droit perpétuel à l’entité décrite.

Pour connaître l’état courant, il faut joindre cette trace à une interrogation fraîche de LIST ACTIVE. Lire l’archive seule reviendrait à prendre la mémoire pour une promesse de service.

Une absence ne supprimait pas le passé

L’erreur inverse consiste à faire d’un vide une réfutation. RFC 3977 autorise l’omission des groupes dont les données manquent. L’archive peut commencer à une date récente et ignorer tous les groupes plus anciens. Une migration peut transporter le catalogue exploitable sans transporter le fichier d’origine.

L’absence d’une ligne signifie donc seulement que la réponse ne contient pas cette ligne. Elle ne démontre pas que le groupe n’a jamais existé, que son nom est invalide ou qu’un pair ne possède pas une autre trace.

La preuve négative exige une promesse de couverture. Ici, le protocole publie au contraire la limite : la mémoire est partielle. Cette franchise empêche l’automatisation de convertir une lacune documentaire en ordre de suppression.

NEWGROUPS révélait la fenêtre retenue

NEWGROUPS permettait de demander les groupes créés depuis un instant donné. RFC 3977 le présente comme une voie parfois meilleure et attend une cohérence générale avec ACTIVE.TIMES. Mais une requête antérieure à la plus vieille ligne conservée peut ramener des groupes supplémentaires.

Comparer les deux résultats aide donc à observer la fenêtre de rétention. Cela ne crée pas une horloge globale. Le nom du serveur, l’instant d’observation, l’identité du lecteur, le motif demandé et le catalogue actif voisin restent indispensables à toute conclusion.

Deux serveurs peuvent associer au même nom des heures différentes parce qu’ils l’ont créé localement à des moments différents. Cette divergence raconte la propagation et l’adoption ; elle n’identifie pas automatiquement une faute.

Le créateur décrit n’était pas l’autorité créatrice

Le dernier champ semble humain et invite à lui attribuer trop de pouvoir. Le texte de RFC 3977 reste prudent : il est destiné à décrire une entité. Il ne vérifie pas la boîte indiquée, ne signe pas l’événement et ne confère aucune propriété.

RFC 5537 place la décision ailleurs. Un message newgroup demande une création ; chaque agent serveur authentifie la commande selon sa politique et peut refuser. La ligne historique qui en résulte peut garder une étiquette, mais elle ne rejoue pas l’authentification ni n’oblige les autres sites.

La provenance aide à enquêter. Elle ne remplace pas l’autorité qui a effectivement pris et exécuté la décision locale.

Un nom normalisé, pas un registre mondial

Le registre IANA des paramètres NNTP inscrit LIST comme capacité regroupant ses variantes et renvoie aux normes. Cette inscription permet à deux logiciels de parler du même mécanisme.

Elle ne certifie ni la présence de ACTIVE.TIMES sur un serveur, ni la longueur de son passé, ni l’authenticité de ses descriptions. IANA coordonne le vocabulaire ; les serveurs conservent les faits locaux.

La modestie de cette architecture est une discipline. Le serveur dit ce qu’il offre maintenant et ce qu’il se rappelle de sa propre histoire. Il n’utilise pas l’un pour réécrire l’autre.

Quand le désaccord protège la vérité

Les systèmes contemporains aiment fusionner l’inventaire et l’audit. Ils obtiennent alors une table plus propre, mais une preuve moins honnête. Un objet actif sans ancienne trace devient suspect sans raison ; une trace ancienne continue d’être lue comme un droit actuel.

NNTP conservait la couture. Le présent, le passé retenu et l’identité descriptive formaient trois catégories séparées. L’opérateur pouvait perdre une partie de l’histoire sans nier le service courant. Il pouvait retirer un groupe sans effacer le fait qu’il l’avait créé.

Les deux listes avaient le droit de ne pas coïncider parce que leur coïncidence forcée aurait menti.

Sources