Format des articles Netnews
(Traduction française)
Résumé
Ce document spécifie la syntaxe des articles Netnews dans le contexte du
format de messages Internet (Internet Message Format, RFC 5322) et des
extensions MIME (Multipurpose Internet Mail Extensions, RFC 2045). Ce
document remplace la RFC 1036 (Standard for Interchange of USENET Messages).
Il y apporte une mise à jour de manière à refléter les pratiques courantes
et à incorporer les changements que d'autres documents ont introduit de
façon incrémentale par leurs spécifications.
Statut
Le présent document spécifie un protocole Internet en normalisation pour la
communauté de l'Internet. Il appelle à la discussion et à des suggestions pour
son amélioration. Prière de se référer à l'édition actuelle des "Normes
officielles des protocoles de l'Internet" (STD 1) pour connaître l'état de
normalisation et le statut de ce protocole. La distribution du présent mémoire
n'est soumise à aucune restriction.
## Copyright (non-traduit) ##
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
## Traduction française : Carine Bournez
Relecture : Olivier Miakinen ##
1. Introduction
1.1 Concepts de base
"Netnews" est un ensemble de protocoles pour générer, conserver et récupérer
des "articles" de news (dont le format est un sous-ensemble du format de
messages électroniques Email) et pour les échanger parmi un lectorat
potentiellement largement distribué. Il est organisé autour de la notion de
groupes appelés "newsgroups", en supposant que chaque lecteur pourra voir tous
les articles postés à chacun des groupes auquel il participe. Ces protocoles
utilisent communément un algorithme d'inondation qui propage des copies
au sein d'un réseau de serveurs. En général, on conserve une seule copie
par serveur et chaque serveur la rend disponible à la demande aux lecteurs
qui ont accès à ce serveur.
1.2 Portée
Le présent document définit la syntaxe des articles Netnews dans le
contexte du format de messages Internet (Internet Message Format, RFC 5322)
et des extensions MIME (Multipurpose Internet Mail Extensions, RFC 2045).
Ce document remplace la RFC 1036 (Standard for Interchange of USENET Messages).
Il y apporte une mise à jour de manière à refléter les pratiques courantes
et à incorporer les changements que d'autres documents ont introduit de
façon incrémentale, notamment la "Descendante-de-1036" (Desc-de-1036).
Ceci est le premier d'un ensemble de documents qui remplacent la RFC 1036.
Il se concentre sur la syntaxe et la sémantique des articles Netnews. La
RFC 5537 est également un document en normalisation et règle les questions de
protocole liées aux articles Netnews, indépendamment des protocoles de
transport sous-jacents tels que le "Network News Transfer Protocol" (NNTP,
RFC 3977). USEAGE, les bonnes pratiques d'Usenet ("Usenet Best Practice"),
donne des recommandations pour améliorer l'interopérabilité et l'utilisabilité.
Cette spécification se veut une définition du format du contenu d'un article
tel qu'il doit passer d'un système à un autre. Bien que de nombreux serveurs
de news conservent les articles localement sous ce format (ce qui élimine le
besoin de traduire entre formats), la conservation locale est hors du propos
de ce document.
1.3 Notation des niveaux d'exigence
Les mots-clés "DOIT" ("MUST"), "NE DOIT PAS" ("MUST NOT"), "OBLIGATOIRE"
("REQUIRED"), "DEVRA" ("SHALL"), "NE DEVRA PAS" ("SHALL NOT"), "DEVRAIT"
("SHOULD"), "NE DEVRAIT PAS" ("SHOULD NOT"), "RECOMMANDÉ" ("RECOMMENDED"),
"POURRAIT" ("MAY") et "OPTIONNEL" ("OPTIONAL") dans ce document sont à
interpréter comme décrit dans la RFC 2119 [RFC 2119].
1.4 Notation pour la syntaxe
Les en-têtes définis dans cette spécification utilisent la notation ABNF
(Augmented Backus-Naur Form) incluant les règles principales (Core Rules)
spécifiées dans la RFC 5234, et de nombreuses constructions définies dans la
RFC 5322, la RFC 2045 mise à jour par la RFC 2231, et la RFC 3986.
Spécifiquement :
token = <voir RFC 2045 Section 5.1>
value = <voir RFC 2045 Section 5.1>
parameter = <voir RFC 2231 Section 7>
attribute = <voir RFC 2231 Section 7>
FWS = <voir RFC 5322 Section 3.2.2>
comment = <voir RFC 5322 Section 3.2.2>
CFWS = <voir RFC 5322 Section 3.2.2>
atext = <voir RFC 5322 Section 3.2.3>
dot-atom-text = <voir RFC 5322 Section 3.2.3>
phrase = <voir RFC 5322 Section 3.2.5>
date-time = <voir RFC 5322 Section 3.3>
mailbox = <voir RFC 5322 Section 3.4>
mailbox-list = <voir RFC 5322 Section 3.4>
address-list = <voir RFC 5322 Section 3.4>
body = <voir RFC 5322 Section 3.5>
fields = <voir RFC 5322 Section 3.6>
IPv6address = <voir RFC 3986 Section 3.2.2>
IPv4address = <voir RFC 3986 Section 3.2.2>
ALPHA = <voir RFC 5234 Annexe B.1>
CRLF = <voir RFC 5234 Annexe B.1>
DIGIT = <voir RFC 5234 Annexe B.1>
DQUOTE = <voir RFC 5234 Annexe B.1>
SP = <voir RFC 5234 Annexe B.1>
VCHAR = <voir RFC 5234 Annexe B.1>
En outre, la section 3.1.3 spécifie une définition plus stricte de <msg-id>
que la syntaxe de la section 3.6.4 de la RFC 5322.
1.5 Définitions
Un "article" est une unité de Netnews, similaire à un "message" dans la
RFC 5322. Un "proto-article" est un article qui n'a pas encore été injecté
dans le système de news. Il a ceci de différent d'un article qu'il ne
comporte pas tous les champs d'en-tête obligatoires.
Un "identifiant de message" (section 3.1.3) est un identifiant unique pour
un article, généralement fourni par l'agent (logiciel) utilisateur qui l'a
posté, ou à défaut par le "serveur de news". Il distingue l'article de tout
autre article jamais posté où que ce soit. Les articles ayant le même
identifiant sont traités comme s'ils étaient un seul et même article, peu
importe les différences qu'ils peuvent présenter dans leur corps ou dans
les champs d'en-tête.
Un "newsgroup" (groupe de news) est un forum pourvu d'un nom et réputé
recevoir des articles en relation avec un certain sujet. Un article est
"posté dans" un seul ou plusieurs groupes. Lorsqu'un article est posté sur
plus d'un newsgroup, il est dit "crossposté" ; notez que ce n'est pas la même
chose que d'écrire le même texte dans plusieurs articles postés chacun dans
un groupe.
Un groupe de news peut être "modéré", auquel cas les soumissions ne
sont pas postées directement, mais envoyées par courrier électronique à
un "modérateur" pour que celui-ci les examine, et poste éventuellement. Les
modérateurs sont généralement humains mais peuvent être partiellement ou
entièrement logiciels.
Un "posteur" est une personne ou un logiciel qui compose et soumet un
article, éventuellement conforme, à un agent utilisateur ("user
agent").
Un "lecteur" est une personne ou un logiciel qui lit des articles Netnews.
Un "suivi" ("followup") est un article contenant une réponse au contenu
d'un article le précédant, son "précurseur". Chaque suivi inclut un champ
d'en-tête "References" identifiant le précurseur (mais notez qu'il se peut
qu'un article qui n'est pas un suivi utilise également le champ d'en-tête
References).
Un "message de contrôle" est un article qui est marqué comme contenant une
information de contrôle ; un serveur de news recevant un tel article peut
(en fonction des règles observées par ce site) effectuer des actions en plus
du simple stockage et de la diffusion de cet article.
Un "serveur de news" est un logiciel qui peut accepter des articles d'un
agent utilisateur et/ou mettre des articles à disposition d'autres
agents utilisateurs et/ou échanger des articles avec d'autres serveurs de news.
Un "agent utilisateur" est un logiciel qui aide les posteurs à soumettre
des proto-articles à un serveur de news et/ou récupère des articles sur
un serveur de news pour les présenter à un lecteur et/ou assiste le lecteur
pour la création d'articles et de suivis.
Le terme générique "agent" est utilisé pour décrire les obligations qui
s'appliquent à la fois aux agents utilisateurs et aux serveurs de news.
On dit d'un agent qu'il "génère" une construction si celle-ci n'existait
pas avant que l'agent l'ait créée, par exemple lorsqu'un agent utilisateur
crée un message à partir de texte et d'information d'adressage fournis par
un utilisateur, ou lorsqu'un serveur de news crée un champ d'en-tête
"Injection-Info" pour un message nouvellement posté.
On dit d'un agent qu'il "accepte" une construction si une autre entité la
génère et la lui transmet, et que l'agent la traite autrement que comme
une erreur de format ou de protocole.
1.6 Structure de ce document
Ce document utilise une méthodologie de citation de références plutôt que
de répéter le contenu d'autres standards, car la répétition pourrait aboutir
à de subtiles incohérences et des problèmes d'interopérabilité.
Bien que ce document soit par conséquent assez court, il requiert, pour
s'y conformer, compréhension et implémentation complètes des références
normatives.
La section 2 définit le format des articles Netnews. La section 3 détaille
les champs d'en-tête nécessaires pour rendre un article correct dans
l'environnement Netnews.
2. Format
2.1 Base
Un article est dit conforme à cette spécification s'il est conforme au
format spécifié en section 3 de la RFC 5322 et aux exigences supplémentaires
de la présente spécification.
Un article utilisant la syntaxe obsolète spécifiée dans la section 4 de la
RFC 5322 n'est PAS conforme à la présente spécification, sauf dans les deux
cas suivants :
- Sont conformes les articles qui utilisent la constuction <obs-phrase>
(utilisation d'un phrase telle que "John Q. Public" sans les guillemets,
voir section 4.1 de la RFC 5322), mais les agents NE DOIVENT PAS générer
de productions d'une telle syntaxe.
- Sont conformes les articles utilisant la <zone> "GMT", comme spécifié
dans la section 3.1.1.
Ce document, ainsi que les spécifications qui s'y appuient, spécifie la
manière de traiter les articles conformes. La manipulation d'articles non
conformes est hors de propos.
Les agents conformes à la présente spécification DOIVENT générer seulement
des articles conformes.
Le texte ci-dessous utilise la notation ABNF pour spécifier les
restrictions par rapport à la syntaxe de la RFC 5322 ; cette grammaire
se veut plus restrictive que celle de la RFC 5322. Les articles doivent
être conformes à la grammaire ABNF spécifiée par la RFC 5322 et également aux
restrictions spécifiées ici, qu'elles soient exprimées dans le texte ou
sous la forme ABNF.
NOTE : D'autres spécifications utilisent le terme "en-tête" comme synonyme de
ce que la RFC 5322 appelle "champ d'en-tête". Ce document suit la terminologie
de la section 2 de la RFC 5322 pour ce qui est de l'utilisation des termes
"ligne" (line), "champ d'en-tête" (header field), "nom de champ d'en-tête"
(header field name), "corps de champ d'en-tête" (header field body) et
"repliement" (folding), puisqu'une terminologie cohérente entre spécifications
présentant des dépendances les rend plus simples à utiliser à long terme.
2.2 Champs d'en-tête
Tous les champs d'en-tête d'un article Netnews sont conformes à la RFC 5322.
La présente spécification est cependant moins permissive pour ce qui est généré
et accepté par les agents. La syntaxe autorisée pour les en-têtes d'articles
Netnews est un sous-ensemble strict des en-têtes du Format de Messages Internet,
ce qui rend tout en-tête conforme à la présente spécification également
conforme à la RFC 5322. Notez cependant que l'inverse n'est pas garanti dans
tous les cas.
Les règles générales s'appliquant à tous les champs d'en-tête (y compris
ceux documentés dans les RFC 5322 et 2045) sont enumérées ci-dessous ;
celles qui s'appliquent à des champs d'en-tête spécifiques sont décrites
dans les sections correspondantes de ce document.
- Tous les agents DOIVENT générer des champs d'en-tête comportant au moins
une espace juste après les ':' séparant le nom du champ d'en-tête et le corps
du champ d'en-tête (par souci de compatibilité avec les logiciels existants
en production, notamment les serveurs NNTP conformes à la RFC 3977). Les
agents POURRAIENT accepter des champs d'en-tête qui ne contiennent pas cette
espace.
- Toute ligne faisant partie du corps d'un champ d'en-tête (y compris la
première et toute ligne subséquemment repliée, c'est à dire coupée et mise
à la ligne) DOIT contenir au moins un caractère qui ne soit pas un caractère
d'espace blanc.
NOTE : Cela signifie qu'aucun corps de champ d'en-tête défini ou référencé
par ce document ne peut être vide. Par conséquent, plutôt que la syntaxe
<unstructured> de la section 3.2.5 de la RFC 5322, ce document utilise
une définition plus stricte :
unstructured = *WSP VCHAR *( [FWS] VCHAR ) *WSP
NOTE : La RFC 5322 utilise parfois [FWS] (NdT: "Folding WhiteSpace", "blanc
de repliement") au début ou à la fin d'une production ABNF décrivant le
contenu de champ d'en-tête. La présente spécification utilise *WSP dans
ces cas-là, ainsi que dans les cas où elle redéfinit des constructions de
la RFC 5322 ; ceci par souci de cohérence avec la restriction ci-dessus, mais
la restriction s'applique à tous les champs d'en-tête, pas seulement
ceux dont la production ABNF est définie dans ce document.
- Un logiciel conforme NE DOIT PAS générer (mais POURRAIT accepter) des lignes
de champ d'en-tête de plus de 998 octets. Ceci est la seule limite de
longueur d'une ligne de champ d'en-tête imposée par ce standard. Cependant,
des règles spécifiques peuvent par contre s'appliquer à des cas particuliers
(par exemple, selon la RFC 2047, les lignes d'un champ d'en-tête contenant
des mots encodés sont limitées à 76 octets). USEAGE inclut des limites pour
des raisons pratiques d'affichage par les agents utilisateurs.
NOTE: Comme décrit dans la RFC 5322, il n'y a PAS de restriction sur le
nombre de lignes sur lesquelles un champ d'en-tête peut être coupé, par
conséquent il n'y a PAS de restriction sur la longueur totale d'un champ
d'en-tête (en particulier il se peut que, par repliement, un champ dépasse la
limite de 998 octets imposée pour une unique ligne de champ d'en-tête).
- Le jeu de caractères pour les champs d'en-tête est US-ASCII. Lorsque
l'utilisation de caractères non-ASCII est requise, ils DOIVENT être encodés
grâce aux mécanismes MIME définis dans les RFC 2047 et 2231.
2.3 Conformité avec MIME
Les agents utilisateurs DOIVENT respecter la définition de la conformité
avec MIME de la RFC 2049 et DOIVENT aussi supporter la RFC 2231. Ce niveau
de conformité avec MIME offre un support de l'internationalisation et du
multimédia dans le corps des messages (RFC 2045, 2046 et 2231) et
de l'internationalisation des champs d'en-tête (RFC 2047 et 2231).
Notez que des errata existent pour les RFC 2045, 2046, 2047 et 2231.
Pour les fins de la section 5 de la RFC 2047, tout champ d'en-tête défini
dans la section 3 du présent standard est à considérer comme un "champ
d'en-tête d'extension" de message, permettant ainsi l'utilisation des encodages
de la RFC 2047 dans tout champ d'en-tête <unstructured>, et dans tout
<comment> ou <phrase> autorisé dans un champ d'en-tête structuré.
Les agents utilisateurs POURRAIENT accepter et générer d'autres champs
d'en-tête d'extension MIME, et en particulier DEVRAIENT accepter les champs
Content-Disposition (RFC 2183) et Content-Language (RFC 3282).
3 Champs d'en-tête de news
Les champs d'en-tête de news suivants s'ajoutent à ceux définis dans la
section 3.6 de la RFC 5322 :
fields =/ *( approved /
archive /
control /
distribution /
expires /
followup-to /
injection-date /
injection-info /
lines /
newsgroups /
organization /
path /
summary /
supersedes /
user-agent /
xref )
Chacun de ces champs d'en-tête NE DOIT PAS figurer plus d'une fois dans
un article de news.
Les champs d'en-tête de news suivants définis dans ce document n'autorisent
pas de <comment> (c.-à-d. utilisent FWS au lieu de CFWS)
Control
Distribution
Followup-To
Lines
Newsgroups
Path
Supersedes
Xref
Ceci s'applique aussi au champ d'en-tête suivant, défini dans la RFC 5322 :
Message-ID
La plupart de ces champs d'en-tête ont un intérêt surtout pour les
serveurs de news, et les serveurs ont besoin de les traiter très rapidement.
C'est pourquoi les <comment> (commentaires) y sont interdits.
3.1 Champs d'en-tête obligatoires
Chaque article Netnews conforme à la présente spécification DOIT avoir
exactement un de chacun des champs d'en-tête suivants : Date, From,
Message-ID, Newsgroups, Path et Subject.
3.1.1 Date
Le champ d'en-tête Date est le même que celui spécifié dans les sections
3.3 et 3.6.1 de la RFC 5322, avec les restrictions supplémentaires détaillées
ci-dessus dans la section 2.2. Par contre, l'utilisation de "GMT" comme
zone de temps (partie de <obs-zone>), bien que désapprouvé, est courant dans
les articles Netnews aujourd'hui. En conséquence, les agents DOIVENT accepter
les constructions de <date-time> utilisant la zone "GMT".
orig-date = "Date:" SP date-time CRLF
NOTE : Cette spécification ne change pas la RFC 5322, qui déclare que les
agents NE DOIVENT PAS générer de construction <date-time> incluant un
quelconque nom de zone défini par <obs-zone>.
Les logiciels qui acceptent des dates avec des zones de temps inconnues
DEVRAIENT traiter ces zones comme équivalentes à "-0000" lors des comparaisons
de dates, comme spécifié dans la section 4.3 de la RFC 5322.
Notez aussi que ces obligations s'appliquent partout où <date-time> est
utilisé, notamment pour Injection-Date et Expires (Sections 3.2.7 et 3.2.5,
respectivement).
3.1.2 From
Le champ d'en-tête From est le même que celui spécifié dans la section 3.6.2
de la RFC 5322, avec les restrictions supplémentaires détaillées ci-dessus
dans la section 2.2.
from = "From:" SP mailbox-list CRLF
3.1.3 Message-ID
Le champ d'en-tête Message-ID contient un identifiant de message unique.
Netnews dépend davantage de l'unicité de l'identifiant de message et de
la rapidité de comparaison que l'Email, et certains logiciels de news et
certains standards (RFC 3977) peuvent avoir des problèmes avec l'étendue
complète des <msg-id> possibles permis par la RFC 5322. Cette section
restreint donc la syntaxe de <msg-id> par rapport à la section 3.6.4 de
la RFC 5322.
L'obligation d'unicité globale pour <msg-id> dans la RFC 5322 doit être
comprise comme agissant pour tous les protocoles utilisant de tels identifiants
de message et en particulier à la fois pour le courrier électronique et Netnews.
message-id = "Message-ID:" SP *WSP msg-id *WSP CRLF
msg-id = "<" msg-id-core ">"
; la longueur maximale est de 250 octets
msg-id-core = id-left "@" id-right
id-left = dot-atom-text
id-right = dot-atom-text / no-fold-literal
no-fold-literal = "[" *mdtext "]"
mdtext = %d33-61 / ; Le reste des caracteres
%d63-90 / ; US-ASCII sauf
%d94-126 ; ">", "[", "]" et "\"
Le <msg-id> NE DOIT PAS excéder 250 octets de longueur.
NOTE : La restriction de longueur assure que les systèmes acceptant des
identifiants de messages comme paramètre réferençant un article (par
ex. RFC 3977) peuvent compter sur une taille bornée.
Attention, <msg-id> inclut les caractères < et >
Attention également aux différences avec la RFC 5322 :
- la syntaxe n'admet pas les commentaires dans le champ d'en-tête Message-ID
- il ne peut pas y avoir de caractère ">" ni de blanc (WSP) dans un <msg-id>
- même s'ils sont communément dérivés des domaines <domain>, la partie droite
<id-right> respecte la casse (et ne doit donc pas, après création, être
altérée lors de transmissions ou copies).
Ceci simplifie le traitement par les serveurs de news et assure
l'interopérabilité avec les implémentations existantes et la conformité
avec la RFC 3977. Une simple comparaison octet par octet suffira toujours
à déterminer l'identité de deux <msg-id>.
Notez également que cette grammaire ABNF modifiée s'applique partout où
<msg-id> est utilisé, notamment le champ d'en-tête References présenté dans la
section 3.2.10 et le champ d'en-tête Supersedes présenté dans la section 3.2.12.
Certains logiciels tenteront de faire correspondre la partie droite <id-right>
d'un <msg-id> sans respecter la casse ; certains le feront en respectant la
casse. Les implémentations NE DOIVENT PAS générer de Message-ID où la seule
différence avec un autre Message-ID se trouve dans la casse des caractères
de la partie <id-right>.
Lorsqu'elles génèrent un <msg-id>, les implémentations DEVRAIENT utiliser
un nom de domaine comme <id-right>.
NOTE : la section 3.6.4 de la RFC 5322 recommande que <id-right> soit
un nom de domaine ou bien un littéral de domaine. Les littéraux de domaine
sont problématiques car de nombreuses adresses IP ne sont pas globalement
uniques ; les noms de domaine sont davantage susceptibles de générer des
Message-ID uniques.
3.1.4 Newsgroups
Le champ d'en-tête Newsgroup spécifie le(s) groupe(s) de news où l'article est
posté.
newsgroups = "Newsgroups:" SP newsgroup-list CRLF
newsgroup-list = *WSP newsgroup-name
*( [FWS] "," [FWS] newsgroup-name ) *WSP
newsgroup-name = component *( "." component )
component = 1*component-char
component-char = ALPHA / DIGIT / "+" / "-" / "_"
Tous les serveurs ne supportent pas le FWS (espace blanc de repliement) dans
la liste des groupes de news. En particulier, il s'avère que replier le
champ d'en-tête Newsgroups sur plusieurs lignes est très dommageable pour la
propagation.
Les FWS optionnels dans la liste <newsgroup-list> NE DEVRAIENT PAS être
générés, mais DOIVENT être acceptés.
Un composant (<component>) NE DEVRAIT PAS être seulement constitué de chiffres
et NE DEVRAIT PAS contenir de lettres majuscules. De tels <component> POURRAIENT
être utilisés pour se référer à des groupes existants qui ne se conforment pas
à ce système de désignation, mais NE DOIVENT PAS être utilisés autrement.
NOTE : les composants composés uniquement de chiffres provoquent des conflits
avec un système largement utilisé pour le stockage d'articles. Les groupes
dont le nom mélange majuscules et minuscules entraînent des confusions
entre les systèmes reconnaissant la casse et ceux ne respectant pas la
casse pour la correspondance des noms de groupes (<newsgroup-name>).
Les composants commençant par un blanc souligné ("_") sont réservés pour
des versions futures de ce standard et NE DEVRAIENT PAS être générés par
les agents utilisateurs (que ce soit dans les champs d'en-tête ou dans les
messages de contrôle de nouveau groupe 'newgroup' définis par la RFC 5537).
Cependant, ils DOIVENT être acceptés par les serveurs de news.
Les composants commençant par "+" ou "-" sont réservés pour un usage privé
et NE DEVRAIENT PAS être générés par des agents utilisateurs (que ce soit
dans les champs d'en-tête ou dans les messages de contrôle de nouveau groupe
'newgroup' définis par la RFC 5537) sans un accord privé préalable.
Cependant, ils DOIVENT être acceptés par les serveurs de news.
Les <newsgroup-name> suivants sont réservés et NE DOIVENT PAS
être utilisés comme noms de groupes de news :
- les groupes dont le premier (ou unique) <component> est "example" (exemple)
- le groupe "poster" (posteur)
Les <newsgroup-name> suivants ont été utilisés pour divers buts dans différents
implémentations et protocoles et par conséquent NE DOIVENT PAS être utilisés
comme noms pour des groupes de news normaux. Ils POURRAIENT être utilisés pour
leur but spécifique ou selon une convention locale.
- Les groupes dont le premier (ou unique) <component> est "to"
- les groupes dont le premier (ou unique) <component> est "control"
- les groupes contenant le (ou composé du seul) <component> "all"
- les groupes contenant le (ou composé du seul) <component> "ctl"
- le groupe "junk".
NOTE : "example.*" est réservé pour les exemples dans le présent et d'autres
standards ; "poster" a une signification particulière dans le champ d'en-tête
Followup-To ; "to.*" est réservé pour certaines communications point-à-point
en conjonction avec le message de contrôle "ihave" tel que défini dans la
RFC 5537 ; "control.*" et "junk" ont une signification spéciale sur certains
serveurs de news ; "all" est utilisé comme joker par certaines
implémentations ; enfin "ctl" fut utilisé pour signaler une commande
<control-command> dans le champ d'en-tête Newsgroups.
3.1.5 Path
Le champ d'en-tête Path indique la route suivie par un article depuis son
injection dans le système de Netnews. Chaque agent qui traite l'article est
obligé d'ajouter au minimum un <path-identity> au début du corps de ce champ
d'en-tête. Ceci sert principalement à éviter que les serveurs de news
n'envoient des articles à des sites qui sont réputés les avoir déjà, en
particulier le site d'où ils sont venus. En plus, cela permet de faire des
statistiques et de tracer la route que les articles suivent pour se déplacer
sur le réseau.
path = "Path:" SP *WSP path-list tail-entry *WSP CRLF
path-list = *( path-identity [FWS] [path-diagnostic] "!" )
path-diagnostic = diag-match / diag-other / diag-deprecated
diag-match = "!" ; un autre "!"
diag-other = "!." diag-keyword [ "." diag-identity ] [FWS]
diag-deprecated = "!" IPv4address [FWS]
diag-keyword = 1*ALPHA ; voir [RFC 5537]
diag-identity = path-identity / IPv4address / IPv6address
tail-entry = path-nodot
; potentiellement la chaîne de caracteres "not-for-mail"
path-identity = ( 1*( label "." ) toplabel ) / path-nodot
path-nodot = 1*( alphanum / "-" / "_" ) ; noms préexistants
label = alphanum [ *( alphanum / "-" ) alphanum ]
toplabel = ( [ label *( "-" ) ] ALPHA *( "-" ) label ) /
( label *( "-" ) ALPHA [ *( "-" ) label ] ) /
( label 1*( "-" ) label )
alphanum = ALPHA / DIGIT ; comparer [RFC 3696]
Un <path-identity> est un nom identifiant un site. Il prend la forme
d'un nom de domaine avec 2 parties ou plus, séparées par des points, ou
bien un nom simple sans point (<path-nodot>).
Chaque <path-identity> dans la liste <path-list> (qui n'inclut pas la
<tail-entry>) indique, de droite à gauche, les agents qui ont successivement
reçu l'article. L'utilisation de <diag-match>, qui apparaît comme "!!", indique
que l'agent à sa gauche a vérifié l'identité de l'agent à sa droite avant
d'accepter l'article (alors que le séparateur simple <path-delimiter>,
affichant "!", sous-entend aucune vérification).
NOTE : historiquement, l'élément <tail-entry> mentionnait le nom de
l'expéditeur. S'il n'est pas utilisé dans ce but, la chaîne "not-for-mail"
est souvent utilisée à la place (à une époque la route pouvait
être utilisée comme adresse de courrier pour l'expéditeur).
NOTE : Bien qu'insensibles à la casse, il est prévu que les <diag-keyword>
soient en majuscules, pour les distinguer des <path-identity> qui sont
traditionnellement en minuscules.
Un <path-diagnostic> est un élément inséré dans le champ d'en-tête Path
pour d'autres usages que l'indication du nom d'un site. Ceci est décrit dans la
RFC 5537.
NOTE : L'un des usages pour <path-diagnostic> est d'enregistrer une
adresse IP. Le fait que les adresses IPv6 <IPv6address> sont autorisées
signifie que les deux points (:) sont permis ; notez que ceci peut causer
des problèmes d'interopérabilité sur des sites plus anciens qui voient ":"
comme un <path-delimiter> et ont des voisins de 4 caractères ou moins où
tous les caractères sont des caractères numériques hexadécimaux valides.
NOTE : Bien que les adresses IPv4 <IPv4address> aient été utilisées
occasionnellement par le passé (généralement dans un but de diagnostic),
continuer de les utiliser est à éviter (même si c'est toujours
acceptable sous la forme <diag-deprecated>).
3.1.6 Subject
Le champ d'en-tête Subject est le même que celui spécifié dans la section
3.6.5 de la RFC 5322, avec les restrictions supplémentaires détaillées
ci-dessus dans la section 2.2. Une discussion plus approfondie du contenu
du champ d'en-tête Subject se trouve dans la RFC 5537 et dans USEAGE.
subject = "Subject:" SP unstructured CRLF
3.2 Champs d'en-tête optionnels
Aucun des champs d'en-tête apparaissant dans cette section n'est obligatoire
dans tout article, mais quelques uns peuvent être obligatoires dans certains
types d'articles. Une discussion plus approfondie de ces obligations se
trouve dans la RFC 5537 et dans USEAGE.
Les champs d'en-tête Comments, Keywords, Reply-To et Sender sont utilisés
dans les articles Netnews dans le même contexte et avec le même sens que
ceux spécifiés dans la RFC 5322, avec les restrictions supplémentaires
décrites ci-dessus dans la section 2.2. L'existence de plusieurs instances
du champ d'en-tête Keywords n'est pas permise.
comments = "Comments:" SP unstructured CRLF
keywords = "Keywords:" SP phrase *("," phrase) CRLF
reply-to = "Reply-To:" SP address-list CRLF
sender = "Sender:" SP mailbox CRLF
Les champs d'en-tête MIME MIME-Version, Content-Type,
Content-Transfer-Encoding, Content-Disposition et Content-Language sont
utilisés dans les articles Netnews dans le même contexte et avec le même sens
que ceux spécifiés dans les RFC 2045, 2183 et 3282, plus les restrictions
supplémentaires décrites ci-dessus en section 2.2.
Tous les autres champs d'en-tête de news sont décrits ci-dessous.
3.2.1 Approved
Le champ d'en-tête Approved indique les adresses de courrier (et
éventuellement les noms complets) des personnes ou entités approuvant la
publication de l'article. Il est principalement utilisé dans les articles
modérés et dans les articles de contrôle de groupes (voir la RFC 5537).
approved = "Approved:" SP mailbox-list CRLF
3.2.2 Archive
Le champ d'en-tête Archive indique les souhaits du posteur concernant la
conservation de son article dans un espace de stockage accessible au
public, sur le long terme ou de façon permanente.
archive = "Archive:" SP [CFWS] ("no" / "yes")
*( [CFWS] ";" [CFWS] archive-param ) [CFWS] CRLF
archive-param = parameter
La présence d'un champ d'en-tête Archive dans l'article avec pour corps
de champ "no" indique que le posteur ne permet pas la redistribution
à partir d'archives publiques à long terme ou permanentes. Si le corps
de champ est "yes", la redistribution via une archive publique est permise.
Aucune valeur de l'élément <parameter> n'est actuellement définie ; s'il
est présent, il peut être ignoré. USEAGE discute davantage de l'utilisation
du champ d'en-tête Archive.
3.2.3 Control
Le champ d'en-tête Control indique que l'article est un message de contrôle
et spécifie l'action à effectuer (en plus des actions habituelles de
stockage et/ou de transmission de l'article).
control = "Control:" SP *WSP control-command *WSP CRLF
control-command = verb *( 1*WSP argument )
verb = token
argument = 1*( %x21-7E )
Le verbe <verb> indique l'action à prendre, et les arguments s'il y a lieu
fournissent les détails nécessaires. Dans certains cas, le corps (<body>,
défini par la RFC 5322) de l'article peut aussi contenir des détails. Les
verbes licites et leurs arguments respectifs sont décrits dans le document
complémentaire, la RFC 5537.
Un article avec un champ d'en-tête Control NE DOIT PAS comporter de
champ d'en-tête Supersedes.
3.2.4 Distribution
Le champ d'en-tête Distribution spécifie des limites géographiques ou
organisationnelles à la propagation d'un article.
distribution = "Distribution:" SP dist-list CRLF
dist-list = *WSP dist-name
*( [FWS] "," [FWS] dist-name ) *WSP
dist-name = ALPHA / DIGIT
*( ALPHA / DIGIT / "+" / "-" / "_" )
Les valeurs de <dist-name> "world" et "local" sont réservées. "world" indique
une distribution illimitée et NE DEVRAIT PAS être utilisé explicitement,
puisque cela correspond au choix par défaut lorsque le champ d'en-tête
Distribution est absent. "local" est réservé pour mentionner une distribution
réduite au site local, tel que défini par la configuration locale du logiciel.
"All" NE DOIT PAS être utilisé comme <dist-name>. <dist-name> DEVRAIT contenir
au moins trois caractères, sauf dans le cas des codes de pays dérivés de la
norme ISO3166-1. <dist-name> n'est pas sensible à la casse (c.-à-d. "US",
"Us", "uS" et "us" spécifient tous la même distribution).
Les espaces blancs de repliement (FWS) optionnels dans <dist-list> NE DEVRAIENT
PAS être générés, mais DOIVENT être acceptés.
3.2.5 Expires
Le champ d'en-tête Expires spécifie les date et heure que le posteur considère
comme le moment où l'article ne sera plus à prendre en compte et pourra être
supprimé (il aura alors "expiré").
NOTE : ce champ d'en-tête est utile lorsque le posteur désire un délai
d'expiration inhabituellement long ou court.
expires = "Expires:" SP date-time CRLF
Voir les remarques en section 3.1.1 sur la syntaxe de <date-time> et les
obligations et recommandations qui s'y appliquent.
NOTE : le champ d'en-tête Expires est parfois utilisé dans le courrier
électronique avec une signification similaire, voir la RFC 2156.
3.2.6 Followup-To
Le champ d'en-tête Followup-To spécifie les groupes de news dans lesquels le
posteur souhaite que les suivis soient postés. Le champ d'en-tête Followup-To
NE DEVRAIT PAS apparaître dans un message si son contenu est identique à
celui du champ d'en-tête Newsgroups.
followup-to = "Followup-To:" SP ( newsgroup-list / poster-text )
CRLF
poster-text = *WSP %d112.111.115.116.101.114 *WSP
; "poster" en minuscules
La syntaxe est la même que pour le champ Newsgroups (section 3.1.4), à
l'exception du mot-clé "poster" qui veut que les suivis soient envoyés par
courrier électronique au posteur de l'article (en utilisant les adresses
contenues dans le champ d'en-tête Reply-To s'il existe, ou les
adresses contenues dans le champ d'en-tête From sinon) au lieu d'être
postés dans un quelconque groupe. Les agents DOIVENT générer le mot-clé
"poster" en minuscules mais POURRAIENT reconnaître indifféremment une
autre casse, par exemple "Poster".
Comme dans le champ d'en-tête Newsgroups (section 3.1.4), les blancs de
repliement (FWS) dans la liste <newsgroup-list> NE DEVRAIENT PAS être générés,
mais DOIVENT être acceptés.
3.2.7 Injection-Date
Le champ d'en-tête Injection-Date contient les date et heure auxquelles
l'article a été injecté dans le réseau. Il permet aux serveurs de news
d'utiliser, pour la vérification d'articles périmés, le moment de l'injection
par le serveur de news plutôt que l'indication du moment de la composition
par l'agent utilisateur.
Ce champ d'en-tête DOIT être inséré à chaque injection d'article. Cependant,
les logiciels antérieurs à ce standard n'utilisant pas ce champ, les agents
DOIVENT accepter les articles sans champ d'en-tête Injection-Date.
injection-date = "Injection-Date:" SP date-time CRLF
Voir les remarques en section 3.1.1 sur la syntaxe de <date-time> et les
obligations et recommandations qui s'y appliquent.
NOTE : les horloges des différents agents ne sont pas nécessairement
synchronisées donc <date-time> dans ce champ d'en-tête n'est pas
forcément ultérieur à la valeur présente dans le champ d'en-tête Date.
Les agents NE DOIVENT PAS modifier le champ d'en-tête Date existant
lorsqu'ils ajoutent le champ Injection-Date.
Ce champ d'en-tête se veut le remplacement du champ actuellement utilisé
mais non documenté "NNTP-Posting-Date", dont l'usage est désormais
déconseillé.
3.2.8 Injection-Info
Le champ d'en-tête Injection-Info contient des informations fournies par
le serveur de news sur la manière dont l'article est arrivé dans le
système Netnews. Il contribue à la traçabilité de l'origine de l'article.
Il peut aussi mentionner une ou plusieurs adresses où des plaintes au
sujet du posteur peuvent être envoyées.
injection-info = "Injection-Info:" SP [CFWS] path-identity
[CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLF
NOTE : La syntaxe de <parameter> (section 5.1 de la RFC 2045, modifiée
par la RFC 2231), complétée par les règles de repliement ("folding rules")
de la RFC 822 (notez : non pas celles de la RFC 2822 ni de la RFC 5322),
autorise effectivement [CFWS] de n'importe quel côté du signe "=" dans
un <parameter>.
Le tableau suivant décrit les valeurs de <attribute> et le format de <value>
pour chaque <parameter> défini pour ce champ d'en-tête.
Au plus une seule occurence de chaque <parameter> est permise.
<attribute> format de <value>
-------------------- -----------------
"posting-host" une <host-value>
"posting-account" n'importe quelle <value>
"logging-data" n'importe quelle <value>
"mail-complaints-to" une liste <address-list>
où
host-value = dot-atom-text / IPv4address / IPv6address /
(dot-atom-text ":" ( IPv4address / IPv6address ))
NOTE : Puisque toute valeur <host-value> ou liste <address-list> doit
également être une <value> syntaxiquement correcte, il est généralement
nécessaire de l'encapsuler comme une chaîne citée <quoted-string>, par
exemple :
posting-host = "posting.example.com:192.0.2.1"
Un autre <attribute> que ceux-ci NE DEVRAIT PAS être utilisé sauf s'il
est défini par une extension de ce standard. Si des <attribute> non
standardisés sont utilisés, ils DOIVENT commencer par un "x-".
Bien que les commentaires et le repliement soient permis dans le champ
d'en-tête Injection-Info, le repliement NE DEVRAIT PAS être utilisé à
l'intérieur d'un <parameter>. Le repliement DEVRAIT se produire seulement
juste avant ou juste après le séparateur ";" entre deux <parameter>. Les
commentaires DEVRAIENT se trouver seulement après le dernier <parameter>.
NOTE : Certaines de ces informations étaient auparavant envoyées sous
la forme de champs d'en-têtes non standardisés, notamment
"NNTP-Posting-Host", "X-Trace", "X-Complaints-To". Dès lors qu'un serveur
de news génère un champ Injection-Info, il ne devrait plus avoir besoin de
générer ces champs non standards.
Le paramètre "posting-host" spécifie le nom de domaine complet et/ou
l'adresse IP (IPv4address ou IPv6address) de l'hôte duquel le serveur de news
a reçu l'article.
NOTE : Si le paramètre "posting-host" ne suffit pas à identifier l'hôte
de manière déterministe (par ex. en raison d'une allocation dynamique
d'adresse IP), alors "posting-account" ou "logging-data" peuvent donner
des informations supplémentaires sur la véritable origine de l'article.
Le paramètre "posting-account" identifie la source depuis laquelle ce
serveur de news a reçu l'article, en suivant une notation propre à
l'administrateur de ce serveur de news. Cette syntaxe peut inclure toute
information que l'administrateur juge pertinente. Afin de limiter
l'exposition de données personnelles, cela DEVRAIT être une forme qui ne
puisse pas être interprétée par d'autres sites. Par contre, pour simplifier
la limitation de débit et la détection d'abus, deux messages provenant de la
même source DEVRAIENT avoir la même valeur de "posting-account", et deux
messages venant de sources différentes DEVRAIENT avoir des valeurs différentes
de "posting-account". La définition exacte de "source" est laissée à
l'appréciation de l'administrateur de serveur de news.
Le paramètre "logging-data" contient des informations permettant de
trouver la véritable source d'un article à partir d'une référence à une
information de journal stockée par le serveur de news (généralement un
numéro de session ou tout autre moyen non persistant d'identifier un
compte posteur).
Le paramètre "mail-complaints-to" désigne une ou plusieurs boîtes
de courrier électronique pour envoyer des plaintes concernant le comportement
du posteur de l'article.
L'inclusion ou non des paramètres ci-dessus relève de règlements locaux.
Certaines informations ont des implications sur la vie privée, le document
USEAGE débat sur ce point.
3.2.9 Organization
Le champ d'en-tête Organization est une phrase courte identifiant
l'organisation du posteur.
organization = "Organization:" SP unstructured CRLF
NOTE : Organization ne s'écrit pas avec un "s". (NdT: si la remarque est
à l'origine destinée à attirer l'attention sur l'orthographe américaine
par opposition à l'orthographe anglaise "organisation", elle est valable
pour le français. Cet avertissement figure bien dans le texte original et
n'est pas de mon invention !)
3.2.10 References
Le champ d'en-tête References est le même que celui spécifié dans la
section 3.6.4 de la RFC 5322, avec les restrictions supplémentaires détaillées
ci-dessus dans la section 2.2, ainsi que les restrictions suivantes :
- la production <msg-id> définie dans la section 3.1.3 DOIT être utilisée.
- les identifiants de messages DOIVENT être séparés par CFWS (NdT :
commentaire, folding et/ou blanc)
- les commentaires dans CFWS entre identifiants de messages peuvent causer
des problèmes d'interopérabilité, donc ils NE DEVRAIENT PAS être générés
mais DOIVENT être acceptés.
references = "References:" SP [CFWS] msg-id *(CFWS msg-id)
[CFWS] CRLF
3.2.11 Summary
Le champ d'en-tête Summary est une courte phrase résumant le contenu de
l'article.
summary = "Summary:" SP unstructured CRLF
3.2.12 Supersedes
Le champ d'en-tête Supersedes contient un identifiant de message indiquant
un article qui devra être remplacé à l'arrivée de celui-ci. Un article
contenant un champ d'en-tête Supersedes équivaut à un message de contrôle
"cancel" (voir RFC 5537) pour l'article indiqué, suivi immédiatement du
nouvel article sans le champ Supersedes.
supersedes = "Supersedes:" SP *WSP msg-id *WSP CRLF
NOTE : Il n'y a pas de "c" dans Supersedes. (NdT: L'orthographe anglaise
"supercedes" est de toute manière incorrecte puisque l'origine latine
est "supersedere". Le lecteur curieux pourra s'intéresser au vieux verbe
français Superséder).
NOTE : Le champ d'en-tête Supersedes défini ici n'a pas de lien avec le
champ d'en-tête Supersedes apparaissant parfois dans les courriers
électroniques convertis à partir de X.400 selon la RFC 2156 ; en particulier
la syntaxe présente permet un seul <msg-id> alors que cette version Email en
a plusieurs.
3.2.13 User-Agent
Le champ d'en-tête User-Agent contient l'information relative à l'agent
utilisateur (généralement un lecteur de news) ayant généré l'article, à des
fins statistiques et d'identification de violations des standards par des
logiciels nécessitant des corrections. Ce champ d'en-tête est réputé
utilisable dans le courrier électronique.
user-agent = "User-Agent:" SP 1*product [CFWS] CRLF
product = [CFWS] token [ [CFWS] "/" product-version ]
product-version = [CFWS] token
Ce champ d'en-tête POURRAIT contenir plusieurs <product> identifiant l'agent
utilisateur et tout sous-produit représentant une partie non négligeable du
logiciel, énumérés dans leur ordre d'importance pour l'application.
NOTE : cette information était auparavant envoyée sous la forme de
champs d'en-tête non standardisés comme X-Newsreader, X-Mailer,
X-Posting-Agent, X-Http-User-Agent et d'autres encore. Dès lors qu'un agent
utilisateur génère un champ d'en-tête User-Agent, il n'est plus nécessaire
de générer ces champs non standard.
NOTE : La RFC 2616 décrit un système semblable pour le protocole HTTP.
Le format d'article Netnews diffère en cela que "{" et "}" sont autorisés
dans les jetons ("token", présent dans <product> et <product-version>) et
que les commentaires sont autorisés partout où l'espace l'est.
3.2.14 Xref
Le champ d'en-tête Xref indique où l'article a été classé par le dernier
serveur de news qui l'a traité. Les agents utilisateurs utilisent souvent
l'information contenue dans le champ d'en-tête Xref pour éviter de traiter
plusieurs fois les articles crosspostés.
xref = "Xref:" SP *WSP server-name
1*( FWS location ) *WSP CRLF
server-name = path-identity
location = newsgroup-name ":" article-locator
article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E )
; caractères US-ASCII imprimables
; sauf '(' and ';'
Le nom du serveur <server-name> est inclus, pour que le logiciel puisse
déterminer quel serveur de news a généré le champ d'en-tête. La localisation
<location> spécifie où l'article est classé, c.-à-d. sous quels groupes de news
(ceci peut différer du champ Newsgroups) et l'endroit dans ces groupes.
La forme exacte de <article-locator> dépend des implémentations.
NOTE : La forme traditionnelle de <article-locator> (telle que voulue
par la RFC 3977) est un nombre décimal, les articles étant numérotés dans
chaque groupe à partir de 1.
3.3 Champs d'en-tête obsolètes
Les champs d'en-tête Date-Received, Posting-Version et Relay-Version
définis dans la RFC 850, ainsi que Also-Control, Article-Names,
Article-Updates et See-Also définis dans la Descendante-de-1036, sont
déclarés obsolètes. Voir les documents de spécifications référencés pour
plus d'information sur leur usage d'origine.
Ces champs d'en-tête NE DOIVENT PAS être générés et DEVRAIENT être ignorés.
3.3.1 Lines
Le champ d'en-tête Lines indique le nombre de ligne du corps de l'article
(<body>, tel que défini dans la RFC 5322).
lines = "Lines:" SP *WSP 1*DIGIT *WSP CRLF
Le nombre de lignes est le nombre de séparateurs CRLF dans le <body>.
Historiquement, ce champ d'en-tête était utilisé par la fonction
d'aperçu dans NNTP (RFC 3977), mais son utilisation dans ce but est
désormais évitée. Par conséquent, ce champ doit être considéré obsolète
et il est probable qu'il soit retiré complètement dans une version future de
ce standard. Tous les agents DEVRAIENT l'ignorer et NE DEVRAIENT PAS le
générer.
4. Considérations sur l'internationalisation
L'internationalisation des champs d'en-tête et des corps des articles Netnews
est couverte par les mécanismes MIME mentionnés dans la section 2.3. Notez
que la génération de <newsgroup-name> internationalisés à utiliser dans les
champs d'en-tête n'est pas traitée dans ce document.
5. Considérations sur la sécurité
Le format d'article Netnews spécifié dans ce document ne fournit aucun service
de sécurité du style confidentialité, authentification de l'expéditeur, ou non
répudiation. De tels services doivent se trouver à un niveau supérieur, en
utilisant des protocoles comme S/MIME (RFC 3851) ou PGP/MIME (Pretty Good
Privacy / MIME) (RFC 3156), ou à un niveau inférieur, grâce à des versions
sécurisées des protocoles de transport des news. De plus, plusieurs protocoles
encore non standardisés comme PGPVERIFY pourraient être prochainement
standardisés.
Les identifiants de message (section 3.1.3) dans les articles Netnews se
doivent d'être uniques ; des articles peuvent être refusés (lors du transfert
d'un serveur à un autre) si l'identifiant a déjà été rencontré. Si un agent
mal intentionné peut prédire l'identifiant d'un article, il peut prendre les
devants et poster son propre article (potentiellement dans un groupe tout à
fait différent) avec le même identifiant de message, empêchant ainsi que
l'article ciblé soit propagé. C'est pourquoi les agents générant les
identifiants de messages DEVRAIENT s'assurer qu'il n'est pas possible de les
prédire.
Les considérations sur la sécurité de MIME sont débattues dans la RFC 2046.
Notez que la gamme complète d'encodages autorisés par les RFC 2046 et 2231
permet des constructions que les analyseurs syntaxiques simples ne savent pas
forcément analyser correctement ; par exemple, ces constructions sont
difficiles à analyser :
Content-Type: multipart/mixed
(; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")
Content-Type: multipart/digest;
boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy
Ces insuffisances de l'analyse peuvent contribuer à une attaque.
D'autres considérations sur la sécurité sont présentées dans la RFC 5537.
6. Considérations liées à l'IANA
L'IANA a enregistré les champs d'en-tête suivants dans le répertoire
permanent de champs d'en-tête de messages (Permanent Message Header
Field Repository), en accord avec les procédures publiées dans la RFC 3864.
Nom du champ d'en-tête : Also-Control
Applicable au protocole : netnews
Statut : obsolète
Auteur/Contrôle de changement : IETF
Document(s) de spécification : [Desc-de-1036] (Section 6.15)
Nom du champ d'en-tête : Approved
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2.1)
Nom du champ d'en-tête : Archive
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2.2)
Nom du champ d'en-tête : Article-Names
Applicable au protocole : netnews
Statut : obsolète
Auteur/Contrôle de changement : IETF
Document(s) de spécification : [Desc-de-1036] (Section 6.17)
Nom du champ d'en-tête : Article-Updates
Applicable au protocole : netnews
Statut : obsolète
Auteur/Contrôle de changement : IETF
Document(s) de spécification : [Desc-de-1036] (Section 6.18)
Nom du champ d'en-tête : Comments
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2), [RFC 5322] (Section 3.6.5)
Nom du champ d'en-tête : Control
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2.3)
Nom du champ d'en-tête : Date
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.1.1), [RFC 5322] (Section 3.6.1)
Nom du champ d'en-tête : Date-Received
Applicable au protocole : netnews
Statut : obsolète
Auteur/Contrôle de changement : IETF
Document(s) de spécification : [RFC 850] (Section 2.2.4)
Nom du champ d'en-tête : Distribution
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2.4)
Nom du champ d'en-tête : Expires
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2.5)
Nom du champ d'en-tête : Followup-To
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2.6)
Nom du champ d'en-tête : From
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.1.2), [RFC 5322] (Section 3.6.2)
Nom du champ d'en-tête : Injection-Date
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2.7)
Nom du champ d'en-tête : Injection-Info
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2.8)
Nom du champ d'en-tête : Keywords
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2), [RFC 5322] (Section 3.6.5)
Nom du champ d'en-tête : Lines
Applicable au protocole : netnews
Statut : deprecated
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.3.1)
Autre information : [RFC 3977] (Section 8.1)
Nom du champ d'en-tête : Message-ID
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.1.3)
Autre information : [RFC 5322] (Section 3.6.4)
Nom du champ d'en-tête : Newsgroups
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.1.4)
Nom du champ d'en-tête : NNTP-Posting-Date
Applicable au protocole : netnews
Statut : obsolète
Auteur/Contrôle de changement : IETF
Document(s) de spécification : aucun
Nom du champ d'en-tête : NNTP-Posting-Host
Applicable au protocole : netnews
Statut : obsolète
Auteur/Contrôle de changement : IETF
Document(s) de spécification : [RFC 2980] (Section 3.4.1)
Nom du champ d'en-tête : Organization
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2.9)
Nom du champ d'en-tête : Path
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.1.5)
Nom du champ d'en-tête : Posting-Version
Applicable au protocole : netnews
Statut : obsolète
Auteur/Contrôle de changement : IETF
Document(s) de spécification : [RFC 850] (Section 2.1.2)
Nom du champ d'en-tête : References
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2.10),
[RFC 5322] (Section 3.6.4)
Nom du champ d'en-tête : Relay-Version
Applicable au protocole : netnews
Statut : obsolète
Auteur/Contrôle de changement : IETF
Document(s) de spécification : [RFC 850] (Section 2.1.1)
Nom du champ d'en-tête : Reply-To
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2),
[RFC 5322] (Section 3.6.2)
Nom du champ d'en-tête : See-Also
Applicable au protocole : netnews
Statut : obsolète
Auteur/Contrôle de changement : IETF
Document(s) de spécification : [Desc-de-1036] (Section 6.16)
Nom du champ d'en-tête : Sender
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2),
[RFC 5322] (Section 3.6.2)
Nom du champ d'en-tête : Subject
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.1.6),
[RFC 5322] (Section 3.6.5)
Nom du champ d'en-tête : Summary
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2.11)
Nom du champ d'en-tête : Supersedes
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2.12)
Nom du champ d'en-tête : User-Agent
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2.13)
Autre information : [RFC 2616] (Section 14.43)
Nom du champ d'en-tête : Xref
Applicable au protocole : netnews
Statut : standard
Auteur/Contrôle de changement : IETF
Document(s) de spécification : ce document (Section 3.2.14)
7. Références
7.1 Références normatives
[RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
[RFC 2046] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types",
RFC 2046, November 1996.
[RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, November 1996.
[RFC 2049] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Five: Conformance Criteria
and Examples", RFC 2049, November 1996.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183,
August 1997.
[RFC 2231] Freed, N. and K. Moore, "MIME Parameter Value and
Encoded Word Extensions: Character Sets, Languages,
and Continuations", RFC 2231, November 1997.
[RFC 3282] Alvestrand, H., "Content Language Headers", RFC 3282,
May 2002.
[RFC 3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005.
[RFC 5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC 5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[RFC 5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture
and Protocols", RFC 5537, November 2009.
7.2 Références informatives
[Errata] "RFC Editor Errata",
<http://www.rfc-editor.org/errata.php>.
[ISO3166-1] International Organization for Standardization, "ISO
3166-1:1997. Codes for the representation of names of
countries and their subdivisions -- Part 1: Country
codes", 1997.
[PGPVERIFY] Lawrence, D., "Authentication of Usenet Group Changes
(pgpverify)", June 1999,
<ftp://ftp.isc.org/pub/pgpcontrol/README.html>.
[RFC 822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[RFC 850] Horton, M., "Standard for interchange of USENET
messages", RFC 850, June 1983.
[RFC 1036] Horton, M. and R. Adams, "Standard for interchange of
USENET messages", RFC 1036, December 1987.
[RFC 2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced
Relay): Mapping between X.400 and RFC 822/MIME",
RFC 2156, January 1998.
[RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
June 1999.
[RFC 2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC 2980] Barber, S., "Common NNTP Extensions", RFC 2980,
October 2000.
[RFC 3156] Elkins, M., Del Torto, D., Levien, R., and T.
Roessler, "MIME Security with OpenPGP", RFC 3156,
August 2001.
[RFC 3696] Klensin, J., "Application Techniques for Checking and
Transformation of Names", RFC 3696, February 2004.
[RFC 3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message
Specification", RFC 3851, July 2004.
[RFC 3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90,
RFC 3864, September 2004.
[RFC 3977] Feather, C., "Network News Transfer Protocol (NNTP)",
RFC 3977, October 2006.
[Desc-de-1036] Spencer, H., "Son of 1036: News Article Format and
Transmission", Work in Progress, May 2009.
[USEAGE] Lindsey, C., "Usenet Best Practice", Work in Progress,
March 2005.
Annexe A. Remerciements
Ce document étant le résultat d'un effort de huit années, le nombre de
personnes y ayant contribué est trop important pour les citer toutes.
Merci à tous les membres passés et présents du groupe de travail USEFOR
de l'IETF (Internet Engineering Task Force) et de la liste de diffusion
associée.
Annexe B. Différences avec la RFC 1036 et ses dérivées
Cette annexe contient une liste de changements que le format d'article
Netnews présente par rapport aux standards précédents, en particulier la
RFC 1036.
- Les conventions de la RFC 5322 pour les commentaires entre parenthèses
dans les champs d'en-tête s'appliquent à tous les nouveaux champs
d'en-tête ainsi que tous ceux hérités de la RFC 5322. Elles sont en
revanche toujours prohibées pour des raisons de performance ou de
compatibilité dans les champs Control, Distribution, Followup-To, Lines,
Message-ID, Newsgroups, Path, Supersedes et Xref.
- Les adresses multiples sont autorisées dans le champ d'en-tête From.
- Le blanc de repliement [FWS] est possible dans le champ d'en-tête Newsgroups.
- Une syntaxe élargie pour le champ d'en-tête Path permet de déterminer
le point d'injection et la route suivie par un article avec plus de précision.
- Seul un (1) identifiant de message est autorisé dans le champ d'en-tête
Supersedes.
- MIME est reconnu comme faisant partie intégrante de Netnews.
- Un nouveau champ d'en-tête Injection-Date rend le rejet d'articles
périmés plus précis et minimise les rejets illégitimes.
- Plusieurs nouveaux champs d'en-tête optionnels sont définis, parmi
lesquels Archive, Injection-Info et User-Agent, pour apporter plus de
fonctionnalités.
- Certains champs d'en-tête, dont Lines, ont été remplacés ou rendus
obsolètes (section 3.3).
- La convention d'interprétation des sujets commençant par le mot "cmsg"
comme des messages de contrôle a été supprimée.
- De nombreux autres petits changements, clarifications et améliorations
ont été apportés.
Annexe C. Différences avec la RFC 5322
Cette annexe présente la liste des différences entre la syntaxe autorisée
par le format d'article Netnews (ce document) et le format de messagerie
Internet spécifié dans la RFC 5322.
Le format d'articles Netnews est un sous-ensemble strict du format de
message Internet, donc tous les articles Netnews sont conformes à la
syntaxe de la RFC 5322.
Les restrictions suivantes sont importantes :
- Une espace (SP) est OBLIGATOIRE après les deux points (":") qui suivent le
nom d'un champ d'en-tête.
- Une syntaxe légèrement restrictive de <msg-id> (utilisée dans les
champs d'en-tête Message-ID, References et Supersedes) est définie.
- La longueur d'un <msg-id> NE DOIT PAS excéder 250 octets.
- Les commentaires ne sont pas autorisés dans le champ d'en-tête
Message-ID.
- Le CFWS entre les <msg-id> dans le champ References n'est pas optionnel.
- Il est licite qu'un analyseur lexical rejette une syntaxe obsolète, sauf
dans les cas suivants :
* La construction <obs-phrase> DOIT être acceptée.
* La <zone> obsolète "GMT" DOIT être acceptée dans un élément <date-time>.
- Chaque ligne du corps d'un champ d'en-tête (la première et toute ligne
suivante repliée incluses) DOIT contenir au moins un caractère qui ne
soit pas un caractère d'espace blanc. Cela veut dire qu'un corps de champ
vide est illicite.
Adresses des auteurs
Kenneth Murchison (éditeur)
Carnegie Mellon University
5000 Forbes Avenue
Cyert Hall 285
Pittsburgh, PA 15213
U.S.A.
Téléphone: +1 412 268 2638
EMail: murch@andrew.cmu.edu
Charles H. Lindsey
University of Manchester
5 Clerewood Avenue
Heald Green
Cheadle
Cheshire SK8 3JU
U.K.
Téléphone: +44 161 436 6131
EMail: chl@clerew.man.ac.uk
Dan Kohn
Healing Thresholds
211 N End Ave Apt 22E
New York, NY 10282
U.S.A.
Téléphone: +1 415 233 1000
EMail: dan@dankohn.com