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.