Du bon usage de...

Le rfc 1036 : Standard for interchange of Usenet messages

Statut de ce document

Ce document définit le format standard pour les échanges de messages de news sur les serveurs usenet. C'est une mise à jour de la rfc-850, reprenant la version b2.11 du programme de news. il est distribué comme une rfc pour rendre ces informations facilement accessibles aux internautes. il ne spécifie pas un standard internet. la distribution de ce document est illimitée.

1 introduction

2 format des messages

2.1 champs d'en-têtes obligatoires

2.2 en-têtes facultatifs

3 articles de contrôle

4 méthodes de transmission

5 l'algorithme de propagation des news

1. introduction

Ce document définit le format standard pour les échanges de messages de news sur les serveurs usenet. il décrit le format des messages en eux-mêmes et donne les normes de transmission sur les news. la transmission des news ne permet pas beaucoup de souplesse aux serveurs pour le choix du matériel et des logiciels de transmission, de propagation des news par paquets, etc.

Il y a cinq parties dans ce document. la deuxième partie décrit le format des messages. la troisième partie décrit les messages de contrôle valides. la quatrième partie spécifie des méthodes de transmission valides. la quatrième partie décrit l'algorithme de propopagation des news dans le monde.

2. format de message

Il faut avant tout que le format de message convienne au maximum d'outils existants. les outils existants contiennent à la fois des fonctions pour le courrier et les news (le système de fichiers de notes de l'université de l'illinois est considéré comme une fonction de news). une norme pour les courriers électroniques existe depuis de nombreuses années sur internet, et ce format correspond à beaucoup d'exigences d'usenet. depuis que le format internet est extensible, les extensions pour remplir les exigences supplémentaires d'usenet sont facilement trouvables dans la norme internet. en conséquence, il est d'usage que tous les messages de news sur usenet soient formatés comme les courriers électroniques d'internet, format défini dans la rfc-822. la norme sur usenet est plus restrictive que la norme sur internet, ajoutant des contraintes supplémentaires sur chaque message et interdisant l'utilisation de certaines caractéristiques des messages sur internet. cependant, il est toujours possible d'utiliser des outils de traitement internet pour traiter un message de news. dans les situations où cette norme rentre en conflit avec la norme internet, la rfc-822 doit être condidérée comme correcte et la présente norme comme fausse.

Voici un exemple de message usenet pour illustrer cela :

           from: jerry@eagle.att.com (jerry schwarz)
           path: cbosgd!mhuxj!mhuxt!eagle!jerry
           newsgroups: news.announce
           subject: usenet etiquette -- please read
           message-id: <642@eagle.att.com>
           date: fri, 19 nov 82 16:14:55 gmt
           followup-to: news.misc
           expires: sat, 1 jan 83 00:00:00 -0500
           organization: at&t bell laboratories, murray hill
           le corps du message vient ensuite, après une ligne vide.

Voici un exemple de message dans un format ancien (avant l'existence de cette norme). il est recommandé que les outils acceptent également les messages dans ce format pour faciliter la transcription.

            from: cbosgd!mhuxj!mhuxt!eagle!jerry (jerry schwarz)
            newsgroups: news.misc
            title: usenet etiquette -- please read
            article-i.d.: eagle.642
            posted: fri nov 19 16:14:55 1982
            received: fri nov 19 16:59:30 1982
            expires: mon jan 1 00:00:00 1990
            the body of the message comes here, after a blank line.

Certains systèmes de news transmettent les news selon le format a, qui ressemble à cela :

             aeagle.642
             news.misc
             cbosgd!mhuxj!mhuxt!eagle!jerry
             fri nov 19 16:14:55 1982
             usenet etiquette - please read
             le corps du message vient ensuite, sans ligne vide.

Un message standard sur usenet consiste en plusieurs champs d'en-têtes, suivis par une ligne vide, suivie par le corps du message. chaque champ d'en-tête se compose d'un mot-clé, de deux-points, d'un espace, et d'informations complémentaires. ceci est une sous-partie de la norme internet, simplifiée pour permettre aux logiciels les plus simples de les manier. le champ "from" peut éventuellement contenir un nom complet, dans le format ci-dessus, ou utiliser la convention internet avec les signes "<" et ">". pour que les fonctions restent simples, les autres formats (par exemple, avec une partie de l'adresse de la machine après fermeture de la parenthèse) ne sont pas autorisés. la convention internet pour les champs d'en-têtes (commençant par un espace ou une tabulation) est autorisée.

Certains en-têtes sont requis, et certains autres sont facultatifs. tous les en-têtes non reconnaissables sont autorisés, et resteront inchangés. les champs d'en-têtes obligatoires sont "from", "date", "newsgroups", "subject", "message-id", et "path". les champs d'en-têtes facultatifs sont "followup-to", "expires", "reply-to", "sender", "references", "control", "distribution", "keywords", "summary", "approved", "lines", "xref", et "organization". tous ces champs d'en-têtes seront décrits plus bas.

2.1. champs d'en-têtes obligatoires

2.1.1. From

Le champ "From" contient l'adresse e-mail de la personne qui a envoyé le message, dans la convention d'écriture internet. elle peut éventuellement contenir aussi le nom de la personne, entre parenthèses, après l'adresse e-mail. l'adresse e-mail est celle de l'auteur responsable du message, sauf si l'en-tête "sender" est présent, auquel cas l'en-tête "from" ne peut pas être vérifié. on peut constater que dans tous les noms de serveurs et de domaines, majuscules et minuscules sont considérées de même, donc "mark@cbosgd.att.com", "mark@cbosgd.att.com", et "mark@cbosgd.att.com" sont toutes trois équivalentes. les noms d'utilisateurs peuvent ou non être sensibles à la casse, par exemple, "billy@cbosgd.att.com" peut être différent de "billy@cbosgd.att.com". les programmes peuvent éviter de changer la casse des adresses e-mail en répondant sur les news ou par mail

La rfc-822 explique que tout texte entre parenthèses est interprété comme un commentaire. il est habituel dans les courriers internet de mettre le nom de l'utilisateur dans un commentaire à la fin du champ "from". la présente norme spécifie une convention d'écriture plus stricte. le nom n'est pas considéré comme un commentaire, mais comme une partie facultative du champ d'en-tête. soit le nom est oublié, soit il apparaît entre parenthèses après l'adresse e-mail de la personne postant le message, soit il apparaît avant une adresse e-mail comprise dans les signes "<" et ">". les trois formes autorisées sont donc :

           from: mark@cbosgd.att.com
           from: mark@cbosgd.att.com (mark horton)
           from: mark horton <mark@cbosgd.att.com>

Le noms peuvent contenir tous les caractères ascii de l'espace au tilde, sauf "(" (parenthèse gauche), ")" (parenthèse droite), "<" (inférieur à), ou ">" (supérieur à). d'autres restrictions peuvent être mises en place sur les noms par les normes de courrier, en particulier, les caractères "," (virgule), ":" (deux-points), "@" (arobase), "!" (point d'exclamation), "/" (slash), "=" (égal), et ";" (point-virgule) ne sont pas autorisés dans les noms.

2.1.2. Date

Le champ "date" (anciennement "posted") correspond à la date à laquelle le message a été posté sur le réseau. son format doit être reconnu à la fois par la rfc-822 et par l'habitude getdate(3) qui est fourni avec le logiciel usenet. cette date reste inchangée tout au long de la propagation du message sur le réseau. un format reconnu par les deux est :

           wdy, dd mon yy hh:mm:ss timezone

Plusieurs exemples de dates valides apapraîssent dans les messages d'exemples au-dessus. on remarquera en particulier ce format ctime(3) :

           wdy mon dd hh:mm:ss yyyy

qui n'est pas acceptable parce qu'il n'est pas en accord avec la rfc-822. cependant, puisque les plus anciens logiciels utilisent encore ce format, les outils de news sont encouragés à accepter ce format et à le transcrire dans un format acceptable.

il n'y a aucun espoir d'avoir une liste complète des fuseaux horaires. l'heure universelle (gmt), les fuseaux horaires nord-américains (pst, pdt, mst, mdt, cst, cdt, est, edt) et les formats +/-hhmm décrits dans la rfc-822 doivent être compris. il est recommandé que l'heure dans les en-têtes de messages soit transmise en heure de greenwinch (gmt) et s'affiche en heure locale.

2.1.3. newsgroups

Le champ "newsgroups" définit le ou les groupe(s) de discussion dans lequel le message est envoyé. plusieurs groupes peuvent être entrés, séparés par une virgule. les groupes entrés doivent tous être les noms de groupes existants, aucun nouveau forum ne sera créé simplement en postant dessus.

Les cartes blanches (par exemple, le mot "all" [le signe * en français]) ne sont jamais autorisées dans le champ "newsgroups". par exemple, un groupe de discussion comp.all est interdit, alors qu'un groupe rec.sport.football est autorisé.

Si un message est reçu avec un champ "newsgroups" contenant des forums valides et des forums invalides, un serveur ne peut pas enlever les groupes invalides de la liste. donc, les forums invalides seront ignorés. par exemple, supposons que le serveur a propage les hiérarchies btl.* et comp*, et échange les messages de news avec le serveur b, qui possède comp.* mais pas btl.*. supposons que a reçoit un message avec "newsgroups: comp.unix,btl.general".

Ce message est transmis à b puisque b reçoit comp.unix, mais b ne reçoit pas btl.general. a doit laisser le champ "newsgroups" inchangé. s'il enlevait btl.general, le message ne pourrait pas être propagé sur la hiérarchie btl.*, et ne sera pas vu par les lecteurs de btl.general. d'autre part, les réponses venant d'en-dehors de btl.* ne seraient pas montrées à ces lecteurs.

2.1.4. subject

Le champ "subject" (anciennement "title") définit de quoi le message parle. il doit être assez représentatif du contenu du message pour permettre au lecteur de prendre une décision pour lire ou non le message uniquement en lisant le sujet. si le message est une réponse à un autre message, le sujet par défaut devra commencer par les quatre caractères "re: ", et le champ "references" est indispensable. pour les réponses, l'utilisation du champ "summary" est encouragée.

2.1.5. Message-id

Le champ "message-id" donne au message un identifiant unique. le message-id ne doit pas être utilisé pendant la durée de vie d'un ancien message avec le même message-id. (il est recommandé qu'aucun message-id ne soit réutilisé pendant au moins deux ans). les message-id ont la syntaxe suivante :

           <suite de caractères ascii ne contenant pas d'espace ou de ">">

Pour être conforme à la rfc-822, les message-id doivent avoir le format suivant :

           <suite_unique@nom_de_domaine>

Où nom_de_domaine est le nom entier du serveur par lequel le message a été amené au réseau, comprenant un domaine dans lequel est situé le serveur, et suite_unique est une suite de caractères ascii, ne comprenant pas "<" (inférieur), ">" (supérieur), ou "@" (arobase). par exemple, cela peut être comme un numéro de série pour les messages envoyés au réseau, ou une courte suite provenant de la date et de l'heure à laquelle le message a été créé. par exemple, un message-id valide pour un message provenant du serveur ucbvax du domaine "berkeley.edu" pourrait être "<4123@ucbvax.berkeley.edu>". les programmeurs ne sont pas encouragés à faire des suppositions à propos du contenu des champs message-id d'autres serveurs, mais à les traiter comme des suites inconnues de caractères. il n'est pas prudent, par exemple, de supposer qu'un message-id fera moins de 14 caractères, qu'il est unique pour les 14 premiers caractères, ou qu'il ne doit pas contenir un "/".

Les signes "<" et ">" sont considérés comme parties intégrantes du message-id. par conséquent, ces signes sont inclus dans les références au message-id, comme dans les messages de contrôle ihave/sendme et cancel. les espaces et les tabulations ne sont pas autorisés dans un message-id. les slashs ("/") sont vivement déconseillés. tous les caractères entre les signes "<" et ">" doivent être des caractères ascii.

2.1.6. Path

Ce champ définit le chemin que le message a pris pour atteindre votre système. quand un système fait suivre le message, il doit ajouter son propre nom à la liste de systèmes dans le champ "path". les noms peuvent être séparés par n'importe quel caractère de ponctuation (sauf "." qui est considéré comme faisant partie du nom du serveur). les champs suivants sont valides :

                cbosgd!mhuxj!mhuxt
                cbosgd, mhuxj, mhuxt
                @cbosgd.att.com,@mhuxj.att.com,@mhuxt.att.com
                teklabs, zehntel, sri-unix@cca!decvax

(Le dernier définit un message qui est passé par decvax, cca, sri-unix, zehntel et teklabs, dans cet ordre). des noms supplémentaires peuvent être ajoutés sur la gauche. par exemple, le nom qui a été ajouté le plus récemment dans le quatrième exemple était teklabs. lettres, chiffres, points et tirets ont considérés comme des parties de noms de serveurs; les autres ponctuations, même les espaces, sont considérés comme des séparateurs.

Normalement, le nom le plus à droite sera le nom du système d'origine cependant, il est également permis d'inclure une entrée supplémentaire sur la droite, qui est le nom de l'expéditeur, pour des raisons de compatibilité avec les anciens systèmes.

Le champ "path" n'est pas utilisé pour des réponses, et ne peut pas être pris en tant qu'adresse e-mail. il est là pour montrer le chemin qu'a pris le message pour arriver au serveur. on peut faire plusieurs utilisations de cette information. l'une d'entre elles est de contrôler les itinéraires sur usenet pour des représentations graphiques diverses. on peut également établir un chemin pour atteindre de nouveaux serveurs. mais l'utilisation la plus répandue est de couper le trafic redondant sur usenet en omettant de transférer un message à un serveur dont on sait qu'il l'a déjà reçu. en particulier, quand le serveur a envoie un message au serveur b, le champ "path" contient le nom du serveur a, ainsi b ne va pas immédiatement retourner le message au serveur a. le nom que chaque serveur utilise pour s'identifier doit être le même que le nom par lequel ses voisins le connaissent, de façon à permettre cette optimisation.

Un serveur ajoute son propre nom au "path" quand il reçoit le message d'un autre serveur. par conséquent, si un message avec le "path" "a!x!y!z" est fourni par le serveur a au serveur b, b va ajouter son propre nom au "path" quand il recevra son message de a, ce qui donnera "b!a!x!y!z". si b envoie ensuite le message sur c, le message envoyé à c contiendra le "path" "b!a!x!y!z", et quand c le recevra, il le changera en "c!b!a!x!y!z".

Note spéciale de compatibilité: puisque les champs "from", "sender", et "reply-to" sont dans le format internet, et puisque beaucoup de serveurs usenet n'ont pas encore de logiciels capables de comprendre le format internet, cela empêchera la possibilité de répondre si la connexion entre le champ "path" et la fonction de réponse est coupée. il est reconnu que le "path" n'est pas toujours une adresse de réponse valide pour les logiciels anciens, et il n'y a pas d'exigence pour réparer ce problème contenu dans les logiciels. cependant, la convention de placer le nom du serveur et un "!" au premier plan du "path", et de commencer le "path" par le nom du serveur, un "!", et le nom de l'utilisateur, devrait être maintenue autant que possible.

2.2. en-têtes facultatifs

2.2.1. reply-to

Ce champ a le même format que le "from". s'il est présent, les réponses par mail à l'auteur seront envoyés au nom donné ici. sinon, les réponses sont envoyées au nom dans le champ "from". (cela n'empêche pas des copies d'être envoyées aux destinataires définis par celui qui répond, ni l'utilisation des champs "to" ou "cc"). le nom entier peut éventuellement être donné, entre parenthèses, comme dans le champ "from".

2.2.2. sender

Ce champ est uniquement présent si l'expéditeur entre manuellement un champ "from". il est convenu de rendre la personne responsable de propager ce message sur le réseau. il peut être vérifié par le logiciel de son serveur.

Par exemple, si john smith visite cca et souhaite poster un message sur le réseau, par l'intermédiaire du compte de son amie sarah jones, le message devra être :

           from: smith@ucbvax.berkeley.edu (john smith)
           sender: jones@cca.com (sarah jones)

Si un programme envoie un message sur le réseau à partir du serveur unix.sri.com, les champs devront être :

           from: john.doe@a.cs.cmu.edu
           sender: network@unix.sri.com

Le premier but de ce champ est de déterminer comment les messages sont arrivés sur le réseau. le nom peut éventuellement être donné, entre parenthèses, comme pour le champ "from".

2.2.3. followup-to

Ce champ a le même format que le champ "newsgroups". s'il est présent, les messages de réponse seront postés au(x) forum(s) énuméré(s) ici. si ce champ est absent, les réponses sont envoyées au(x) forum(s) énuméré(s) dans le champ "newsgroups".

Si le mot clé "poster" est présent, les messages de réponses ne sont pas permis. le message devra être envoyé par mail à l'auteur du message.

2.2.4. expires

Ce champ, s'il est présent, est dans le format convenu pour la date sur usenet. il spécifie une date d'expiration du message. s'il n'est pas présent, l'expiration locale par défaut est utilisée. ce champ est utilisé pour nettoyer les messages qui ont une utilité temporaire, ou pour garder les messages importants plus longtemps que d'ordinaire. par exemple, un message annonçant un séminaire à venir pourra avoir une date d'expiration le lendemain du séminaire, puisque le message n'a plus aucun utilité après la fin du séminaire. puisque les serveurs locaux ont des règles locales pour l'expiration des news (en fonction de l'espace disque, par exemple), il est déconseillé aux utilisateurs de fournir des dates d'expiration pour les messages s'il n'y a pas de date naturellement associée avec le sujet. les logiciels ne devraient presque jamais fournir un champ "expires" par défaut. oubliez-le et permettez aux règles locales d'être utilisées s'il n'y a pas de bonne raison de le faire.

2.2.5. references

Ce champ énumère les message-id des messages précédant l'envoi de ce message. il est obligatoire pour toutes les réponses, et interdit quand un nouveau sujet est lancé. les logiciels doivent fournir une commande de réponse, qui permet à l'utilisateur de poster une réponse. cette commande doit engendrer un champ "subject" identique au message original, sauf si le message original ne commence pas par "re: " ou "re: ", les quatre caractères "re: " étant insérés avant le sujet s'il n'y a pas de champ "references" dans les en-têtes originaux, le champ "references" contiendra le message-id du message original (avec les signes "<" et ">"). si le message original a un champ "references", la réponse aura un champ "references" contenant le texte du champ "references" original, un espace, et le message-id du message précédent.

Le but du champ "references" est de permettre aux messages d'être regroupés en fils de conversation par l'interface du programme de l'utilisateur. cela permet aux conversations dans un forum d'être regroupées ensemble, et aux utilisateurs d'isoler éventuellement des fils de conversations entiers sans se désabonner du forum. les interfaces de l'utilisateur n'ont pas besoin d'utiliser ce champ, mais toutes les réponses créent automatiquement le champ "references" pour les systèmes qui l'utilisent, et les réponses produites manuellement (si écrire en réponse au message original a été compris par la machine) peuvent l'inclure également.

Il est autorisé de ne pas inclure la totalité du champ "references" précédent s'il est trop long. on peut envisager un nombre raisonnable de références.

2.2.6. control

Si un message contient un champ "control", le message est un message de contrôle. les messages de contrôle sont utilisés pour la communication entre les machines des serveurs d'usenet, pas pour être lus par les utilisateurs. les messages de contrôle sont distribués comme les messages ordinaires. le corps du champ "control" est le message au serveur.

Par mesure de compatibilité, les messages qui sont envoyés aux groupes "*.*.ctl" sont aussi interprétés comme des messages de contrôle. s'il n'y a pas de champ "control" sur ces messages, le sujet est utilisé comme message de contrôle. cependant, ce genre de messages sur les forums n'est pas conforme aux normes.

Toujours pour des histoires de comptabilité, si les quatre premiers caractères du champ "subject:" sont "cmsg", le reste du champ "subject:" peut être interprété comme un message de contrôle.

2.2.7. distribution

Ce champ est utilisé pour modifier l'étendue de la propagation du message. c'est un champ similaire au champ "newsgroups", une liste dont chaque entité est séparée de l'autre par une virgule. les abonnements de l'utilisateur sont toujours définis par le champ "newsgroups", mais le message est envoyé à tous les systèmes propageant les forums du champ "distribution" en plus de ceux du champ "newsgroups" pour que le message soit propagé, le serveur qui le reçoit doit normalement recevoir au moins un des forums spécifiés et doit recevoir au moins un de ceux du champ "distribution". ainsi, un message concernant une voiture à vendre à new jersey pourra avoir ces en-têtes :

                newsgroups: rec.auto,misc.forsale
                distribution: nj,ny

Ainsi, il ne parviendra qu'aux personnes abonnées à rec.auto ou misc.forsale à new jersey ou new york. le but de cet en-tête est de restreindre la distribution d'un message, et non de l'étendre. un forum local, comme nj.crazy-eddie, ne sera probablement pas propagé par les serveurs en-dehors du new jersey qui ne le considéreront pas comme valide. un message de réponse possédera par défaut le même champ "distribution" que le message original, mais l'utilisateur peut le changer en un champ moins restrictif, ou l'étendre s'il était très restreint à l'origine et qu'une réponse étendue à plus de monde est appropriée.

2.2.8. organization

Le texte de ce champ est une courte phrase décrivant l'organisation à laquelle celui qui envoie le message appartient, ou à laquelle la machine appartient. le but de ce champ est d'aider à identifier la personne qui poste le message, puisque les noms de serveurs sont souvent assez cryptés pour rendre leur reconnaissance par l'adresse e-mail assez difficile.

2.2.9. keywords

Quelques mots-clés bien choisis identifiant le message peuvent être contenus dans ce champ. ceci est utilisé comme une aide pour déterminer si le lecteur est intéressé par ce message.

2.2.10. summary

Ce champ contient un rapide résumé du message. il est utilisé habituellement comme un morceau du message de réponse. encore une fois, c'est très utile au lecteur pour déterminer s'il veut lire le message.

2.2.11. approved

Ce champ est obligatoire pour tous les messages postés sur un forum modéré. il est ajouté par le modérateur et consiste en son adresse e-mail. il est également obligatoire pour certains messages de contrôle.

2.2.12. lines

Ce champ contient le nombre de lignes du corps du message.

2.2.13. xref

Ce champ contient le nom du serveur (sans le domaine) et une liste, des forums séparés entre eux par des espaces, et séparés par deux-points à un numéro de message. ce sont les forums définis dans le champ "newsgroups" et leurs numéros associés dans le dossier de stockage du serveur.

Ceci est seulement en vigueur sur le système local, et ne sera donc pas propagé. par exemple:

            path: seismo!lll-crg!lll-lcc!pyramid!decwrl!reid
            from: reid@decwrl.dec.com (brian reid)
            newsgroups: news.lists,news.groups
            subject: usenet readership summary report for sep 86
            message-id: <5658@decwrl.dec.com>
            date: 1 oct 86 11:26:15 gmt
            organization: dec western research laboratory
            lines: 441
            approved: reid@decwrl.uucp
            xref: seismo news.lists:461 news.groups:6378

Le champ "xref" montre que le message est le message numéro 461 sur le forum newslists, et le message numéro 6378 sur le forum news.groups, sur le serveur seismo. cette information peut être utilisée par certaines interfaces.

3. messages de contrôle

Cette partie énumère les messages de contrôle couramment utilisés le corps du champ "control" est le message de contrôle. le message est une suite de zéro mot ou plus, éventuellement séparés par des espaces ou des tabulations. le premier mot est le nom du message de contrôle, les mots restants sont les paramètres du message. le reste du champ et le corps du message sont également des paramètres éventuels; par exemple, le champ "from" peut suggérer une adressse e-mail à laquelle une réponse peut être faite.

Les administrateurs peuvent choisir de permettre aux messages de contrôle d'être traités immédiatement, ou d'attendre une opération annuelle. cependant, les messages faits manuellement seront traités rapidement.

Les messages qui n'ont pas abouti ne seront pas envoyés à l'expéditeur du message, mais au compte usenet local.

3.1. cancel

                  cancel <message-id>

Si un message avec le message-id donné est présent sur le système local, ce message est annulé. ce mécanisme permet à l'utilisateur d'annuler un message après sa propagation sur le réseau.

Si le système ne peut pas annuler le message démandé, il ne répandra pas la demande d'annulation aux autres systèmes.

Seul l'auteur du message ou l'administrateur local est autorisé à envoyer ce message. l'expéditeur de ce message est contenu dans le champ "sender", ou, s'il n'y a pas de champ "sender", dans le champ "from". l'expéditeur du message d'annulation doit être le même que celui contenu dans le champ "sender" ou "from" du message d'origine. un expéditeur authentifié pour le message d'annulation est autorisé à posséder un "from" non authentifié pour le message annulé.

3.2. ihave/sendme

                ihave <liste de message-id> [<nom_du_serveur>]
                sendme <liste de message-id> [<nom_du_serveur>]

Ce message fait partie du protocole ihave/sendme, qui permet à un serveur (appelons-le a) de demander à un autre serveur (b) qu'un message spécifique soit envoyé à a. supposons que le serveur a reçoive le message "<1234@ucbvax.berkeley.edu>", et qu'il veuille le transmettre au serveur b.

A envoie le message de contrôle "ihave <1234@ucbvax.berkeley.edu> a" au serveur b (en le postant sur le forum to.b). b répond par le message de contrôle "sendme <1234@ucbvax.berkeley.edu> b" (sur le forum to.a), s'il n'a pas encore reçu ce message. dès qu'il a reçu le message "sendme", a envoie le message à b.

Ce protocole peut être utilisé pour limiter le trafic répétitif entre serveurs. c'est facultatif et doit être utilisé uniquement si cela en vaut la peine. souvent, il en résulte que, puisque la majorité des messages d'origine sont courts, et puisqu'il y a beaucoup de frais à envoyer un nouveau message avec uucp, cela coûte autant d'envoyer le "ihave" que d'envoyer le message lui-même.

Une solution envisageable à ces problèmes de frais est de faire plusieurs demandes à la fois. plusieurs message-id peuvent être annoncés ou demandés dans un même message. s'il n'y a pas de message-id dans le message de contrôle, les message-id pourront être contenus dans le corps du message, un par ligne.

3.3. newgroup

                   newgroup <nom_du_forum> [moderated]

Ce message de contrôle crée un nouveau forum avec le nom donné. comme aucun message ne peut être posté ou transféré tant que le forum n'est pas créé, ce message est obligatoire avant que le forum puisse être utilisé. le corps du message doit être un court paragraphe décrivant l'utilisation attendue du forum.

S'il y a quelque chose ensuite et que c'est le mot-clé "moderated", le forum sera créé modéré; par défaut, il est non-modéré. le message de newgroup sera ignoré s'il n'y a pas de champ "approved" dans les en-têtes de ce message.

3.4. rmgroup

             rmgroup <nom_du_forum>

Ce message supprime le forum qui a le nom donné. puisque le forum est supprimé de tous les serveurs du réseau, cette commande doit être utilisée prudemment par un administrateur responsable. le message de rmgroup sera ignoré s'il n'y a pas de champ "approved:" dans les en-têtes de ce message.

3.5. sendsys

            sendsys (rien à définir)

Le fichier système, énumérant tous les serveurs voisins et tous les forums que propage chacun de ces serveurs, sera envoyé à l'auteur du message de contrôle ("reply-to", si présent, sinon "from"). cette information est considérée comme publique, et c'est une exigence d'usenet que cette information puisse être fournie, en réponse automatique à ce message de contrôle, ou manuellement, en envoyant l'information à l'auteur du message. cette information est utilisée pour mettre à jour un "plan" d'usenet, et pour déterminer où les messages sont envoyés.

Le format du fichier reçu en retour sera le même que le fichier système. ce format a un serveur par ligne (plus une ligne pour le serveur local), contenant quatre champs séparés par deux-points. le premier champ est le nom du serveur, le deuxième est une liste de hiérarchies décrivant les forums envoyés au serveur. les troisième et quatrième champs ne sont pas définis par cette norme. le fichier système n'est pas le même que le fichier l.système uucp (uucp l.sys file). un exemple de réponse pourrait être :

             from: cbosgd!mark  (mark horton)
             date: sun, 27 mar 83 20:39:37 -0500
             subject: response to your sendsys request
             to: mark@cbosgd.att.com

             responding-system: cbosgd.att.com
             cbosgd:osg,cb,btl,bell,world,comp,sci,rec,talk,misc,news,soc,to,
   
   
             test
             ucbvax:world,comp,to.ucbvax:l:
             cbosg:world,comp,bell,btl,cb,osg,to.cbosg:f:/usr/spool/outnews
   
   
             /cbosg
             cbosgb:osg,to.cbosgb:f:/usr/spool/outnews/cbosgb
             sescent:world,comp,bell,btl,cb,to.sescent:f:/usr/spool/outnews
   
   
             /sescent
             npois:world,comp,bell,btl,ug,to.npois:f:/usr/spool/outnews/npois
             mhuxi:world,comp,bell,btl,ug,to.mhuxi:f:/usr/spool/outnews/mhuxi

3.6. version

            version (rien à définir)

Le nom et la version du logiciel tournant sur le système local sera envoyé à l'auteur du message ("reply-to" si présent, sinon "from").

3.7. checkgroups

Le corps du message est une liste de forums "officiels" avec leur description, un groupe par ligne. ils sont comparés à la liste de forums actifs sur le serveur actuel. les noms de forums obsolètes ou récents sont envoyés à l'utilisateur "usenet" et les descriptions des nouveaux forums sont ajoutés au fichier d'aide d'utilisation des news.

4. méthodes de transmission

Usenet n'est pas un réseau physique, mais plutôt un réseau logique existant à partir de plusieurs réseaux physiques déjà existants. ces réseaux comprennent, uucp, l'internet, un ethernet, le réseau blicn, une hyperchannel nsc, et un berknet, mais ne sont pas limités à cela le plus important est que deux systèmes voisins sur usenet aient des méthodes pour obtenir un message, dans le format présenté ici, d'un système à l'autre, et qu'une fois sur le système récepteur, il puisse être traité par les logiciels de news de ce système. (sur les systèmes unix, cela signifie habituellement que le programme rnews sera lancé avec le message de l'entrée standard <1>).

Il n'est pas obligatoire aux serveurs usenet de posséder des systèmes de courrier capables de comprendre la syntaxe du mail internet, mais c'est fortement recommandé. puisque les champs "from", "reply-to", et "sender" utilisent la syntaxe internet, les réponses seront difficiles voire impossibles sans un logiciel de courrier internet. un serveur sans logiciel de mail internet peut essayer d'utiliser le champ "path" pour répondre, mais ce champ n'est pas garanti comme un chemin valable pour les réponses. dans tous les cas, chaque serveur produisant ou transférant des messages de news doit avoir une adresse e-mail qui lui permettra de recevoir du courrier des serveurs qui possèdent des logiciels de courrier internet, et il doit mettre cette adresse e-mail dans leur champ "from".

4.1. commandes à distance

Certains réseaux autorisent directement les commandes à distance. on peut faire suivre les news en associant la commande rnews au message de l'entrée standard. par exemple, si le système éloigné s'appelle remote, les news seront envoyées par un lien uucp avec la commande :

            uux - remote!rnews

Et sur un berknet :

            net -mremote rnews

Il est important que le message soit envoyé par un mécanisme fiable, impliquant la possibilté de stocker, plutôt que des commandes à distance en temps réel. c'est pourquoi, si le système éloigné n'est pas opérationnel, une commande directe va échouer, et le message ne sera jamais envoyé. si le message est stocké, il ne sera envoyé que lorsque les deux systèmes seront opérationnels.

4.2. transfert par courrier electronique (mail)

Sur certains systèmes, l'exécution directe de ce qui est situé à distance n'est pas possible. cependant, la majorité des systèmes supportent les courriers électroniques, et un message de news pourra être envoyé comme un courrier. une façon de s'y prendre est d'envoyer un courrier identique au message de news: les en-têtes de ce mail seront les en-têtes du message de news, et le corps du mail sera le corps du message de news. par convention, ce mail est envoyé au newsmail de l'utilisateur sur la machine éloignée.

Un problème de cette méthode est qu'il n'est pas possible de convaincre le système de courrier que le champ "from" du message est valide, puisque le mail a été créé par un programme situé sur un système différent de la source du message de news. un autre problème est que les messages d'erreur causés par la transmission du mail seront envoyés à l'auteur du message de news, qui n'a aucun contrôle sur la transmission des news entre deux serveurs et qui ne saura pas qui contacter. les messages d'erreur de transmission devront être adressés à une personne responsable, sur la machine qui a envoyé le message.

Une solution à ce problème est d'inclure le message de news dans un mail, tel que le message entier (en-têtes et corps) soit contenu dans le corps du mail. la convention est qu'un tel mail est envoyé à l'utilisateur de rnews sur le système éloigné. le corps d'un mail est créé en faisant précéder chaque ligne du message de news par la lettre n, et de joindre les en-têtes qui sont faciles à créer. les n sont joints pour empêcher des lignes spécifiques au message de news d'interférer avec la transmission du mail, et pour empêcher des lignes supplémentaires ajoutées par le logiciel (en-têtes, lignes blanches, etc.) d'apparaître dans le message de news. un programme sur la machine réceptrice reçoit le mail, extrait le message en lui-même et fait appel au programme rnews. un exemple de ce format pourraît ressembler à cela :

            date: mon, 3 jan 83 08:33:47 mst
            from: news@cbosgd.att.com
            subject: network news message
            to: rnews@npois.att.com
            npath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
            nfrom: derek@sask.uucp (derek andrew)
            nnewsgroups: misc.test
            nsubject: necessary test
            nmessage-id: <176@sask.uucp>
            ndate: mon, 3 jan 83 00:59:15 mst
            n
            nthis really is a test.  if anyone out there more than 6
            nhops away would kindly confirm this note i would
            nappreciate it.  we suspect that our news postings
            nare not getting out into the world.
            n

L'utilisation du courrier résout le problème de stockage temporaire, puisque le courrier doit toujours être conservé si l'hôte de destination n'est pas accessible. cependant, cela augmente encore les frais de transmission (pour inclure et extraire le message) et rend plus difficile pour les logiciels la distinction entre news et courrier.

4.3. transmission par paquets (batching)

Puisque les messages de news sont globalement assez courts, et qu'un grand nombre de messages par jour transitent entre deux serveurs, il est plus logique d'envoyer les messages par paquets. plusieurs messages peuvent être regroupés en un message plus gros, utilisant les conventions convenues entre les deux serveurs. un tel plan d'envoi par paquets est décrit ici; cette utilisation est fortement recommandée.

Les messages de news sont regroupés dans un message, séparés par un en-tête de la forme :

            #! rnews 1234

Où 1234 est la longueur du message en bytes. chacune de ces lignes est suivie par un message contenant le nombre donné de bytes. (le retour-charriot à la fin de chaque ligne du message est compté comme un byte). par exemple, un envoi de messages par paquets pourrait ressembler à cela :

            #! rnews 239
            from: jerry@eagle.att.com (jerry schwarz)
            path: cbosgd!mhuxj!mhuxt!eagle!jerry
            newsgroups: news.announce
            subject: usenet etiquette -- please read
            message-id: <642@eagle.att.com>
            date: fri, 19 nov 82 16:14:55 est
            approved: mark@cbosgd.att.com

            here is an important message about usenet etiquette.
            #! rnews 234
            from: jerry@eagle.att.com (jerry schwarz)
            path: cbosgd!mhuxj!mhuxt!eagle!jerry
            newsgroups: news.announce
            subject: notes on etiquette message
            message-id: <643@eagle.att.com>
            date: fri, 19 nov 82 17:24:12 est
            approved: mark@cbosgd.att.com

            there was something i forgot to mention in the last
            message.

Les news envoyées ainsi sont reconnaissables car le premier caractère du message est #. le message est ensuite passé à un "rassembleur" (unbatcher) pour être interprété.

La première ligne (dans cet exemple "rnews") détermine quel plan d'envoi par paquets sera utilisé. les serveurs utiliseront le plan le plus approprié pour eux.

5. l'algorithme de propagation des news

Cette partie décrit le plan général d'usenet et l'algorithme suivi par les serveurs pour propager les news au réseau. puisque tous les serveurs sont gênés par des messages mal formatés et par des erreurs de propagation, il est important de posséder une méthode généralisée.

Usenet est un graphique organisé. chaque noeud du graphique est l'ordinateur d'un serveur, et chaque arc est un chemin de transmission d'un serveur à l'autre. chaque arc est étiqueté par un ensemble de forums, spécifiant quels types de forums sont transmis par ce lien. la plupart des arcs sont bidirectionnels, ainsi, si le serveur a envoie un type de forums au serveur b, le serveur b enverra ensuite le même type de forums au serveur a. cette bidirectionnalité n'est cependant pas obligatoire.

Usenet est fait de beaucoup de réseaux secondaires. chacun de ces réseaux a un nom, comme comp ou btl. chacun de ces réseaux est un graphique relié, un chemin existannt de chaque noeud à tous les autres noeuds du réseau. de plus, le graphique entier est (en théorie) relié (en pratique, certaines considérations politiques ont empêché certains serveurs de poster des messages sur le reste du réseau).

Un message est posté sur une machine à une liste de forums. cette machine l'accepte localement, puis le transmet à tous ses voisins qui comportent au moins un des forums du message (le serveur a suppose que le serveur b est "intéressé" par un forum si le forum remplit les conditions de l'arc qui va de a à b. ces conditions sont gardées en mémoire dans un fichier sur la machine du serveur a). les serveurs recevant le message l'examinent pour être vraiment sûrs qu'ils le veulent, l'acceptent localement, puis le transmettent à leur tour à tous leurs voisins intéressés. ce processus continue jusqu'à ce que le réseau entier ait vu le message.

Une grosse partie de l'algorithme consiste en la prévention des boucles le processus ci-dessus pourrait amener un message à tourner éternellement autour du réseau. en particulier, quand le serveur a envoie un message au serveur b, le serveur b va le renvoyer au serveur a, qui va l'envoyer au serveur b, etc. une solution à cela est le mécanisme de l'historique. chaque serveur garde une trace de tous les messages qu'il a vus (par leur message-id) et quand un message qu'ils ont déjà vu apparaît, ce message est détruit immédiatement. cette méthode suffit à éviter les boucles, mais des optimisations supplémentaires peuvent être faites pour éviter aux messages envoyés aux serveurs d'être purement et simplement jetés.

L'une de ces optimisations est telle qu'un message ne puisse jamais être envoyé à une machine nommée dans le champ "path" du message. quand le nom d'une machine est dans le champ "path", le message est reconnu comme étant déjà passé par cette machine. une autre optimisation est telle que, si le message provient du serveur a, le serveur a a déjà vu le messsage. ainsi, si un message est posté sur le forum misc.misc, il remplit la condition misc.* (où * est un symbole qui comprend tous les forums), et sera transmis à tous les serveurs qui propagent misc.* (le serveur le détermine par ce que ses voisins lui envoient). ces serveurs forment le réseau secondaire misc. un message posté sur btl.general va atteindre tous les serveurs propageant btl.*, mais n'atteindra pas les serveurs qui ne possèdent pas btl.*. en effet, les messages atteignent le réseau secondaire btl. un message posté sur les forums misc.misc et btl.general atteindra tous les serveurs qui propagent au moins une de ces deux hiérarchies.

notes

<1> Unix est une marque déposée par at&t.