Groupe de travail Réseau	K. Murchison, éd., Carnegie Mellon University
Request for Comments: 5536	C. Lindsey, University of Manchester
RFC rendue obsolète : 1036 	D. Kohn, Healing Thresholds
Catégorie : Sur la voie de la normalisation	novembre 2009
Traduction Carine Bournez

Format d'article Netnews
Résumé
Le présent document spécifie la syntaxe des articles Netnews dans le contexte du format de message Internet de la (RFC 5322) et des extensions multi-objets de messagerie Internet (MIME, Multipurpose Internet Mail Extensions) (RFC 2045). Ce document rend obsolète la RFC 1036, fournissant une spécification mise à jour pour refléter la pratique courante et incorporer les changements incrémentaires spécifiés dans d'autres documents.

Statut de ce mémoire
Le présent document spécifie un protocole sur la voie de la normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifiée de BSD comme décrit à la Section 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.
Table des matières
1. Introduction	2
1.1 Concepts de base	2
1.2 Domaine d'application	2
1.3 Notation des exigences	2
1.4 Notation de la syntaxe	2
1.5 Définitions	3
1.6 Structure du document	4
2. Format	4
2.1 Base	4
2.2 Champs d'en-tête	4
2.3 Conformité à MIME	5
3. Nouveaux champs d'en-tête	5
3.1 Champs d'en-tête obligatoires	6
3.2 Champs d'en-tête facultatifs	9
3.3 Champs d'en-tête obsolètes	14
4. Considérations d'internationalisation 	15
5. Considérations sur la sécurité	15
6. Considérations relatives à l'IANA	15
7. Références	19
7.1 Références normatives	19
7.2 Références pour information	20
Appendice A. Remerciements	20
Appendice B. Différences avec la RFC 1036 et ses dérivés	21
Appendice C. Différences avec la RFC 5322	21
Adresse des auteurs	22

 	1.	Introduction
 	1.1	Concepts de base
"Netnews" est un ensemble de protocoles pour générer, mémoriser, et restituer des "articles" de nouvelles (dont le format est un sous ensemble de celui pour les messages électroniques) et pour les échanger entre un lectorat qui est potentiellement largement distribué. Il est organisé autour de groupes de nouvelles appelés "newsgroups", avec l'attente que chaque lecteur va être capable de voir tous les articles postés à chaque groupe de nouvelles auquel il participe. Ces protocoles utilisent très couramment un algorithme d'arrosage, qui propage les copies à travers un réseau de serveurs participants. Normalement, une seule copie est mémorisée par serveur, et chaque serveur la rend disponible à la demande aux lecteurs qui sont capables d'accéder à ce serveur.

 	1.2	Domaine d'application
Le présent document définit la syntaxe des articles Netnews dans le contexte du format de messages Internet [RFC5322] et des extensions multi objets de messagerie Internet (MIME, Multipurpose Internet Mail Extensions) [RFC2045]. Le présent document rend obsolète la [RFC1036], mettant à jour la syntaxe des articles de Netnews pour refléter les pratiques courantes et incorporer les changements et précisions spécifiées dans d'autres documents comme [RFC1849].

Ceci est le premier d'un ensemble de documents qui remplacent la [RFC1036]. Le présent document se concentre sur la syntaxe et la sémantique des articles Netnews. La [RFC5537] est aussi un document sur la voie de la normalisation qui décrit les questions de protocole des articles Netnews, indépendamment des protocoles de transport comme le protocole de transport des nouvelles du réseau (NNTP, Network News Transfer Protocol) [RFC3977]. [USEAGE], "Bonnes pratiques de Usenet", décrit les recommandations de mise en œuvre pour améliorer l'interopérabilité et l'utilisabilité.

La présente spécification est destinée à définir ce que doit être le format du contenu d'article passé entre les systèmes. Bien que de nombreux systèmes de nouvelles mémorisent localement les articles dans ce format (ce qui élimine le besoin de traduction entre formats) la mémorisation locale sort du domaine d'application de la présente norme.

 	1.3	Notation des exigences
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119],.

 	1.4	Notation de la syntaxe
Les champs d'en-tête définis dans la présente spécification utilisent la notation du format Backus-Naur augmenté (ABNF) (y compris les règles centrales) spécifiée dans la [RFC5234] ainsi que de nombreuses constructions définies dans la [RFC5322], la [RFC2045] telle que mise à jour par la [RFC2231], et la [RFC3986]. Spécifiquement :

jeton  = <voir le paragraphe 5.1 de la RFC 2045>
valeur = <voir le paragraphe 5.1 de la RFC 2045>
paramètre = <voir la Section 7 de la RFC 2231>
attribut = <voir la Section 7 de la RFC 2231>

FWS = <voir le paragraphe 3.2.2 de la RFC 5322>
commentaire = <voir le paragraphe 3.2.2 de la RFC 5322>
CFWS = <voir le paragraphe 3.2.2 de la RFC 5322>
atext = <voir le paragraphe 3.2.3 de la RFC 5322>
dot-atom-text = <voir le paragraphe 3.2.3 de la RFC 5322>
phrase = <voir le paragraphe 3.2.5 de la RFC 5322>
date-time = <voir le paragraphe 3.3 de la RFC 5322>
mailbox = <voir le paragraphe 3.4 de la RFC 5322>
mailbox-list  = <voir le paragraphe 3.4 de la RFC 5322>
adresse-list  = <voir le paragraphe 3.4 de la RFC 5322>
corps = <voir le paragraphe 3.5 de la RFC 5322>
champs = <voir le paragraphe 3.6 de la RFC 5322>

IPv6address = <voir le paragraphe 3.2.2 de la RFC 3986>
IPv4address = <voir le paragraphe 3.2.2 de la RFC 3986>

ALPHA = <voir l'appendice B.1 de la RFC 5234>
CRLF = <voir l'appendice B.1 de la RFC 5234>
DIGIT = <voir l'appendice B.1 de la RFC 5234>
DQUOTE = <voir l'appendice B.1 de la RFC 5234>
SP = <voir l'appendice B.1 de la RFC 5234>
VCHAR = <voir l'appendice B.1 de la RFC 5234>

De plus, le paragraphe 3.1.3 spécifie une définition plus stricte de <msg-id> que la syntaxe du paragraphe 3.6.4 de la [RFC5322].

 	1.5	Définitions
Un "article" est l'unité de Netnews, analogue à un "message" de la [RFC5322]. Un "proto-article" est celui qui n'a pas encore été injecté dans le système de nouvelles. À la différence d'un article, un proto-article peut manquer de certains champs d'en-tête obligatoires.

Un "identifiant de message" (paragraphe 3.1.3) est un identifiant univoque pour un article, généralement fourni par l'agent d'utilisateur qui l'a posté ou, à défaut, par le "serveur de nouvelles". Il distingue l'article de tous les autres articles postés partout ailleurs. Les articles avec le même identifiant de message sont traités comme si ils étaient le même article sans considération d'aucune différence dans le corps ou les champs d'en-tête.

Un "newsgroup" est un forum qui a un nom et qui est destiné à des articles sur un sujet spécifique. Un article est "posté à" un seul ou plusieurs newsgroups. Quand un article est posté à plus d'un newsgroup, il est dit être "crossposté" ; noter que ceci est différent de poster le même texte au titre de chacun de plusieurs articles, un par newsgroup.

Un newsgroup peut être "modéré", auquel cas les soumissions ne sont pas postées directement, mais envoyées à un "modérateur" pour examen et possible postage. Les modérateurs sont normalement des personnes mais peuvent être mis en œuvre partiellement ou entièrement par un logiciel.

Un "posteur" est la personne ou logiciel qui compose et soumet un article potentiellement conforme à un agent d'utilisateur.

Un "lecteur" est la personne ou logiciel qui lit les articles de 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 des informations de contrôle ; un serveur de nouvelles qui reçoit un tel article peut (sous réserve de la politique du site) prendre des actions qui vont au delà de juste mémoriser et passer l'article.

Un serveur de nouvelles est un logiciel qui peut accepter des articles d'un agent d'utilisateur, et/ou rendre les articles disponibles aux agents d'utilisateur, et/ou échanger des articles avec d'autres serveurs de nouvelles.

Un "agent d'utilisateur" est un logiciel qui peut aider les posteurs à soumettre des proto-articles à un serveur de nouvelles, et/ou aller chercher des articles sur un serveur de nouvelles et les présenter à un lecteur, et/ou aider le lecteur à créer des articles et suivis.

Le terme générique de "agent" est utilisé quand on décrit les exigences qui s'appliquent à la fois aux agents d'utilisateur et aux serveurs de nouvelles.

Un agent est dit "générer" une construction si elle n'existait pas avant que l'agent la crée. Des exemples sont quand un agent d'utilisateur crée un message à partir de texte et d'informations d'adressage fournis par un utilisateur, ou quand un serveur de nouvelles crée un champ d'en-tête "Injection-Info" pour un nouveau message posté.

Un agent est dit "accepter" une construction si une autre entité la génère et la passe à l'agent en question, et l'agent la traire sans la considérer comme une erreur de format ou de protocole.

 	1.6	Structure du document
Le présent document utilise une méthode de citation par référence, plutôt que de répéter le contenu d'autres normes, ce qui pourrait résulter en de subtiles différences et défis d'interopérabilité. Bien que le présent document soit par suite assez court, il exige une compréhension complète et que la mise en œuvre des références normatives soit conforme.

La Section 2 définit le format des articles Netnews. La Section 3 détaille les champs d'en-tête nécessaires pour qu'un article convienne dans l'environnement Netnews.

 	2.	Format
 	2.1	Base
Un article est dit être conforme à la présente spécification si il se conforme au format spécifié à la Section 3 de la [RFC5322] et aux exigences supplémentaires de la présente spécification.

Un article qui utilise la syntaxe obsolète spécifiée à la Section 4 de la [RFC5322] est NON conforme à la présente spécification, sauf dans les deux cas suivants :

o	Les articles sont conformes si ils utilisent la construction <obs-phrase> (utilisation d'une phrase comme "John Q. Public" sans les guillemets, voir le paragraphe 4.1 de la [RFC5322]), mais les agents NE DOIVENT PAS générer de productions d'une telle syntaxe.

o	Les articles sont conformes si ils utilisent la <zone> "GMT", comme spécifié au paragraphe 3.1.1.

Le présent document, et les spécifications qui s'appuient sur lui, spécifie comment traiter les articles conformes. Le traitement d'articles non conformes sort du domaine d'application de la présente spécification.

Les agents qui se conforment à cette spécification DOIVENT générer seulement des articles conformes.

Le texte ci-dessous utilise l'ABNF pour spécifier des restrictions à la syntaxe spécifiée dans la [RFC5322] ; cette grammaire est destinée à être plus restrictive que la grammaire de la [RFC5322]. Les articles doivent se conformer à l'ABNF spécifié dans la [RFC5322] et aussi aux restrictions spécifiées ici, celles qui sont exprimées comme du texte et celles qui sont exprimées en ABNF.

Note : d'autres spécifications utilisent le terme "en-tête" comme un synonyme de ce que la [RFC5322] appelle un "champ d'en-tête". Le présent document suit la terminologie de la Section 2 de la [RFC5322] en utilisant les termes "ligne", "champ d'en-tête", "nom de champ d'en-tête", "corps de champ d'en-tête", et "saut à la ligne", sur la base de la croyance qu'une terminologie cohérente entre les spécifications qui dépendent les unes des autres rend les spécifications plus faciles à utiliser à long terme.

 	2.2	Champs d'en-tête
Tous les champs d'en-tête dans un article Netnews sont conformes à la [RFC5322] ; la présente spécification est cependant moins permissive dans ce qui peut être généré et accepté par les agents. La syntaxe permise pour les en-têtes d'articles Netnews est un strict sous ensemble des en-têtes au format de message Internet, rendant tous les en-têtes conformes à la présente spécification naturellement conformes à la [RFC5322]. Noter cependant que l'inverse n'est pas garanti dans tous les cas.

Les règles générales qui s'appliquent à tous les champs d'en-tête (même ceux documentés dans les [RFC5322] et [RFC2045]) sont mentionnés ci-dessous, et ceux qui s'appliquent à des champs d'en-tête spécifiques sont décrits dans les paragraphes pertinents du présent document.

o	Tous les agents DOIVENT générer des champs d'en-tête de façon qu'au moins une espace suive immédiatement le ':' qui sépare le nom de champ d'en-tête et le corps de champ d'en-tête (pour la compatibilité avec le logiciel déployé, incluant les serveurs NNTP [RFC3977]). Les nouveaux agents PEUVENT accepter des champs d'en-tête qui ne contiennent pas l'espace requise.

o	Chaque ligne d'un corps de champ d'en-tête (incluant la première et toutes celles qui sont ensuite repliées) DOIT contenir au moins un caractère non espace.

Note : Cela signifie que aucun corps de champ d'en-tête défini ou référencé par le présent document ne peut être vide. Par suite, plutôt que d'utiliser la syntaxe <unstructured> du paragraphe 3.2.5 de la [RFC5322], le présent document utilise une définition plus stricte :

unstructured =  *WSP VCHAR *( [FWS] VCHAR ) *WSP

Note : la [RFC5322] utilise parfois [FWS] au début ou à la fin d'un ABNF décrivant le contenu d'un champ d'en-tête. La présente spécification utilise *WSP dans ce cas, et aussi dans les cas où la présente spécification redéfinit des constructions provenant de la [RFC5322]. Ceci est fait pour la cohérence avec la restriction décrite ici, mais la restriction s'applique à tous les champs d'en-tête, pas seulement ceux où l'ABNF est défini dans ce document.

o	Un logiciel conforme NE DOIT PAS générer (mais PEUT accepter) des lignes de champ d'en-tête de plus de 998 octets.  C'est la seule limite de longueur d'une ligne de champ d'en-tête prescrite par la présente norme. Cependant, des règles spécifiques du contraire peuvent s'appliquer dans des cas particuliers (par exemple, selon la [RFC2047], les lignes d'un champ d'en-tête contenant des mots codés sont limitées à 76 octets). [USEAGE] inclut des limites suggérées pour faciliter l'affichage par les agents d'utilisateur.

Note : comme déclaré dans la [RFC5322], il n'y a PAS de restriction sur le nombre de lignes sur lesquelles un champ d'en-tête peut être partagé, et donc il n'y a PAS de restriction à la longueur totale d'un champ d'en-tête (en particulier il peut, par des sauts à la ligne convenables, excéder la restriction à 998 octets relative à une seule ligne de champ d'en-tête).

o	Le jeu de caractères pour les champs d'en-tête est l'US-ASCII. Lorsque l'utilisation de caractères non ASCII est requise, ils DOIVENT être codés en utilisant les mécanismes MIME définis dans les [RFC2047] et [RFC2231].

 	2.3	Conformité à MIME
Les agents d'utilisateur DOIVENT respecter la définition de conformité à MIME de la [RFC2049] et DOIVENT aussi prendre en charge la [RFC2231]. Ce niveau de conformité à MIME assure la prise en charge de l'internationalisation et du multimédia dans les corps de message des [RFC2045], [RFC2046], et [RFC2231], et la prise en charge de l'internationalisation des champs d'en-tête des [RFC2047] et [RFC2231]. Noter que des [Errata] existent actuellement pour les [RFC2045], [RFC2046], [RFC2047] et [RFC2231].

Pour les besoins de la Section 5 de la [RFC2047], tous les champs d'en-tête définis à la Section 3 de la présente norme sont à considérer comme des "champs d'en-tête d'extension de message", permettant l'utilisation des codages de la [RFC2047] au sein de tout champ d'en-tête <unstructured>, ou au sein de tout <comment> ou <phrase> permis au sein de tout champ d'en-tête structuré.

Les agents d'utilisateur PEUVENT accepter et générer d'autres champs d'en-tête d'extension MIME, et en particulier DEVRAIENT accepter Content-Disposition [RFC2183] et Content-Language [RFC3282].

 	3.	Nouveaux champs d'en-tête

Les nouveaux champs d'en-tête suivants étendent ceux définis au paragraphe 3.6 de la [RFC5322] :

champs =/ *( 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 se produire plus d'une fois dans un article de nouvelles.

Les champs d'en-tête suivants définis dans le présent document ne permettent pas de <comment> (c'est-à-dire, ils utilisent FWS plutôt que 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 [RFC5322] :

Message-ID

La plupart de ces champs d'en-tête sont principalement intéressants pour les serveurs de nouvelles, et les serveurs de nouvelles ont souvent besoin de traiter ces champs très rapidement. Donc, certains champs d'en-tête interdisent les <comment>.

 	3.1	Champs d'en-tête obligatoires
Chaque article Netnews conforme à la présente spécification DOIT avoir exactement un de chaque champs d'en-tête suivant : 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é aux paragraphes 3.3 et 3.6.1 de la [RFC5322], avec l'ajout des restrictions détaillées au paragraphe 2.2. Cependant, l'utilisation de "GMT" comme zone horaire (partie de <obs-zone>), bien que déconseillée, est largement répandue dans les articles Netnews aujourd'hui. Donc, les agents DOIVENT accepter les constructions <date-time> qui utilisent la zone "GMT".

orig-date =  "Date:" SP date-time CRLF

Note : la présente spécification ne change pas la [RFC5322], qui dit que les agents NE DOIVENT PAS générer de constructions <date-time> qui incluent des noms de zone définis par <obs-zone>.

Les logiciels qui acceptent des dates avec des zone horaires inconnues DEVRAIENT traiter ces zones horaires comme équivalentes à "-0000" quand elles comparent les dates, comme spécifié au paragraphe 4.3 de la [RFC5322].

Noter aussi que ces exigences s'appliquent partout où <date-time> est utilisé, incluant Injection-Date et Expires (respectivement aux paragraphes 3.2.7 et 3.2.5, ).

 	3.1.2	From
Le champ d'en-tête From est le même que celui spécifié au paragraphe 3.6.2 de la [RFC5322], avec l'ajout des restrictions détaillées au paragraphe 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 univoque. Netnews est plus dépendant de l'unicité de l'identifiant de message et de la comparaison rapide que ne l'est le message électronique, et certains logiciels et normes de nouvelles [RFC3977] pourraient avoir des problèmes avec la gamme complète de <msg-id> possibles permise par la [RFC5322]. Ce paragraphe restreint donc la syntaxe de <msg-id> par rapport au paragraphe 3.6.4 de la [RFC5322]. L'exigence d'unicité globale pour <msg-id> dans la [RFC5322] est à comprendre comme s'appliquant sur tous les protocoles qui utilisent de tels identifiants de message, et sur la messagerie et Netnews en particulier.

message-id = "Message-ID:" SP *WSP msg-id *WSP CRLF

msg-id = "<" msg-id-core ">"	; longueur maximum 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 / %d63-90 / %d94-126	; reste des caractères US-ASCII non inclus ">", "[", "]", ou "\"

Le <msg-id> NE DOIT PAS faire plus de 250 octets.

Note : la restriction de longueur assure que les systèmes qui acceptent les identifiants de message comme paramètre quand ils référencent un article (par exemple, [RFC3977]) peuvent s'appuyer sur une longueur limitée.

Observer que <msg-id> inclut < et >.

Observer aussi qu'à la différence du champ d'en-tête correspondant dans la [RFC5322] :
o	La syntaxe ne permet pas les commentaires au sein du champ d'en-tête Message-ID.
o	Il n'y a pas de possibilité que ">" ou WSP se produise dans un <msg-id>.
o	Bien qu'ils soient couramment dérivés des <domaine>, les <id-rights> sont sensibles à la casse (et donc, une fois créés, ne doivent pas être altérés durant la transmission ou copie suivante).

C'est pour simplifier le traitement par les serveurs de nouvelles et pour assurer l'interopérabilité avec les mises en œuvre existantes et la conformité avec la [RFC3977]. Une simple comparaison d'octets va toujours suffire pour déterminer l'identité de deux <msg-id>.

Noter aussi que cet ABNF mis à jour s'applique partout où <msg-id> est utilisé, incluant le champ d'en-tête References discuté au paragraphe 3.2.10 et le champ d'en-tête Supersedes discuté au paragraphe 3.2.12.

Certains logiciels vont essayer de confronter le <id-right> d'un <msg-id> de façon insensible à la casse et certains vont le confronter de façon sensible à la casse. Les mises en œuvre NE DOIVENT PAS générer de Message-ID lorsque la seule différence avec un autre Message-ID est la casse de caractères dans la partie <id-right>.

Quand elles génèrent un <msg-id>, les mises en œuvre DEVRAIENT utiliser un nom de domaine comme <id-right>.

Note : le paragraphe 3.6.4 de la [RFC5322] recommande que le <id-right> devrait être un nom de domaine ou un littéral de domaine. Les littéraux de domaine sont perturbants car beaucoup d'adresses IP ne sont pas uniques au monde ; les noms de domaine vont plus probablement générer des Message-ID uniques.

 	3.1.4	Newsgroups
Le champ d'en-tête Newsgroups spécifie le ou les groupes de nouvelles auxquels l'article est envoyé.

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 prennent pas en charge le FWS facultatif dans la liste de newsgroups. En particulier, le repli du champ d'en-tête Newsgroups sur plusieurs lignes a été montré comme significativement dommageable à la propagation. Un FWS facultatif dans <newsgroup-list> NE DEVRAIT PAS être généré, mais DOIT être accepté.

Un <component> NE DEVRAIT PAS consister seulement en chiffres et NE DEVRAIT PAS contenir de lettres majuscules.  De tels <component> PEUVENT être utilisés seulement pour se référer à des groupes existants qui ne se conforment pas à ce schéma de dénomination, mais NE DOIVENT PAS être utilisés autrement.

Note : les <component> tout de chiffres entrent en conflit avec un schéma de mémorisation largement utilisé pour les articles. Les groupes de casse mixte causent de la confusion entre les systèmes avec confrontation sensible à la casse et les systèmes avec confrontation insensible à la casse de <newsgroup-name>.

Les <component> qui commencent par un souligné ("_") sont réservés pour être utilisés par de futures versions de la présente norme et NE DEVRAIENT PAS être générés par les agents d'utilisateur (dans les champs d'en-tête ou dans les messages de contrôle de newsgroup comme défini par la [RFC5537]). Cependant, de tels noms DOIVENT être acceptés par les serveurs de nouvelles.

Les <component> qui commencent par "+" et "-" sont réservés pour utilisation privée et NE DEVRAIENT PAS être générés par les agents d'utilisateur (dans les champs d'en-tête ou dans les messages de contrôle de newsgroup [RFC5537]) sans un accord privé préalable pour le faire. Cependant, de tels noms DOIVENT être acceptés par les serveurs de nouvelles.

Les <newsgroup-name> suivants sont réservés et NE DOIVENT PAS être utilisés comme nom d'un newsgroup :
o	groupes dont le premier (ou seul) <component> est "exemple",
o	le groupe "poster".

Les <newsgroup-name> suivants ont été utilisés à des fins spécifiques dans diverses mises en œuvre et protocoles et donc NE DOIVENT PAS être utilisés pour les noms de newsgroup normaux. Ils PEUVENT être utilisés pour leur objet spécifique ou par accord local :
o	Groupes dont le premier (ou seul) composant est "to"
o	Groupes dont le premier (ou seul) composant est "control"
o	Groupes qui contiennent (ou consistent seulement en) le composant "all"
o	Groupes qui contiennent (ou consistent seulement en) le composant "ctl"
o	Le groupe "junk".

Note : "exemple.*" est réservé pour les exemples dans cette norme et les autres ; "poster" a une signification spéciale dans le champ d'en-tête Followup-To ; "to.*" est réservé pour certaines communications en point à point en conjonction avec le message de contrôle "ihave" comme défini dans la [RFC5537] ; "control.*" et "junk" ont une signification particulière dans certains serveurs de nouvelles ; "all" est utilisé comme caractère générique dans certaines mises en œuvre, et "ctl" était anciennement utilisé pour indiquer une <control-command> au sein du champ d'en-tête Newsgroups.

 	3.1.5	Path
Le champ d'en-tête Path indique le chemin suivi par un article depuis son injection dans le système Netnews. Chaque agent qui traite un article est obligé d'ajouter au moins une <path-identity> devant ce corps de champ d'en-tête. C'est principalement ainsi que les serveurs de nouvelles sont capables d'éviter d'envoyer des articles aux sites déjà connus pour les avoir, en particulier le site d'où ils viennent. De plus, il permet de collecter des statistiques et de retracer le chemin que prennent les articles en se déplaçant 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 la [RFC5537]

diag-identity = path-identity / IPv4address / IPv6address

tail-entry =  path-nodot	; peut être la chaîne "not-for-mail"

path-identity =  ( 1*( label "." ) toplabel ) / path-nodot

path-nodot =  1*( alphanum / "-" / "_" )	; noms traditionnels

label =  alphanum [ *( alphanum / "-" ) alphanum ]

toplabel =  ( [ label *( "-" ) ] ALPHA *( "-" ) label ) / ( label *( "-" ) ALPHA [ *( "-" ) label ] ) / ( label 1*( "-" ) label )

alphanum =  ALPHA / DIGIT 	; comparer à la [RFC3696]

Un <path-identity> est un nom qui identifie un site. Il prend la forme d'un nom de domaine ayant deux composants ou plus séparés par des points, ou un seul nom sans points (<path-nodot>).

Chaque <path-identity> dans la <path-list> (qui n'inclut pas de <tail-entry>) indique, de droite à gauche, les agents successifs à travers lesquels l'article est passé. 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 (tandis que le <path-delimiter> "!" implique qu'il n'y a eu aucune vérification).

Note : Historiquement, la <tail-entry> indiquait le nom de l'envoyeur. Si elle n'est pas utilisée pour cela, la chaîne "not-for-mail" est souvent utilisée à la place (car à un moment, le chemin entier pourrait être utilisé comme adresse de messagerie pour l'envoyeur).

Note : Bien qu'insensible à la casse, il est prévu que les <diag-keyword> devraient être 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 des besoins autres que d'indiquer le nom d'un site. Son utilisation est décrite dans la [RFC5537].

Note : un usage d'un <path-diagnostic> est d'enregistrer une adresse. Le fait que les <IPv6address> soient permises signifie que le caractère deux-points (:) est permis ; noter que cela peut causer des problèmes d'interopérabilité sur d'anciens sites qui considèrent ":" comme un <path-delimiter> et ont des voisins dont les noms ont 4 caractères ou moins, et où tous les caractères sont des chiffres HEX valides.

Note : bien que les <IPv4address> aient été occasionnellement utilisées dans le passé (généralement dans une intention de diagnostic) la poursuite de leur utilisation est déconseillés (bien qu'elle soit encore acceptable sous la forme de <diag-deprecated>).

 	3.1.6	Subject
Le champ d'en-tête Subject est le même que celui spécifié au paragraphe 3.6.5 de la [RFC5322], avec l'ajout des restrictions détaillées au paragraphe 2.2. Une discussion du contenu du champ d'en-tête Subject figure dans la [RFC5537] et dans [USEAGE].

subject =  "Subject:" SP unstructured CRLF

 	3.2	Champs d'en-tête facultatifs
Aucun des champs d'en-tête qui apparaissent dans ce paragraphe n'est obligé d'apparaître dans chaque article, mais certains d'entre eux peuvent être exigé dans certains types d'articles. Une discussion de ces exigences figure dans la [RFC5537] et dans [USEAGE].

Les champs d'en-tête Comments, Keywords, Reply-To, et Sender sont utilisés dans les articles Netnews dans les mêmes circonstances et avec la même signification que ceux spécifiés dans la [RFC5322], avec l'ajout des restrictions détaillées au paragraphe 2.2. Plusieurs occurrences de champ d'en-tête Keywords ne sont pas permises.

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 les mêmes circonstances et signification que celles spécifiées dans les [RFC2045], [RFC2183], et [RFC3282], avec les restrictions détaillées au paragraphe 2.2.

Tous les nouveaux champs d'en-tête restants sont décrits ci-dessous.

 	3.2.1	Approved
Le champ d'en-tête Approved indique les adresses de messagerie (et éventuellement les noms complets) des personnes ou entités qui approuvent le postage de l'article. Sa principale utilisation est dans les articles "modérés" et dans les messages de contrôle de groupe ; voir la [RFC5537].

approved = "Approved:" SP mailbox-list CRLF

 	3.2.2	Archive
Le champ d'en-tête Archive donne une indication de l'intention du posteur à l'égard de la préservation de l'article dans une mémorisation publiquement accessible à long terme ou 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 un article avec un corps de champ de "no" indique que le posteur ne permet pas la redistribution à partir d'archives publiquement accessibles à long terme ou permanentes. Un corps de champ de "yes" indique que le posteur permet une telle redistribution.

Aucun <paramètre> n'est actuellement défini ; si il en est de présent, il peut être ignoré. Une discussion de l'utilisation du champ d'en-tête Archive figure dans [USEAGE].

 	3.2.3	Control
Le champ d'en-tête Control marque l'article comme un message de contrôle et spécifie les actions désirées (en plus des actions usuelles de mémorisation et/ou de relais 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 indique quelle action devrait être prise, et le ou les arguments (si il en est) fournissent les détails. Dans certains cas, le <corps> (comme défini dans la [RFC5322]) de l'article peut aussi contenir des détails. Les verbes légaux et leurs arguments respectifs sont discutés dans le document d'accompagnement, [RFC5537].

Un article avec un champ d'en-tête Control NE DOIT PAS avoir aussi un champ d'en-tête Supersedes.

 	3.2.4	Distribution
Le champ d'en-tête Distribution spécifie les limites géographiques ou organisationnelles de la propagation de l'article.

distribution = "Distribution:" SP dist-list CRLF

dist-list = *WSP dist-name *( [FWS] "," [FWS] dist-name ) *WSP

dist-name = ALPHA / DIGIT *( ALPHA / DIGIT / "+" / "-" / "_" )

Les <dist-name> "world" et "local" sont réservés. "world" indique une distribution illimitée et NE DEVRAIT PAS être utilisé explicitement, car c'est la valeur par défaut quand le champ d'en-tête Distribution est entièrement absent. "local" est réservé pour indiquer une distribution seulement au site local, comme défini par la configuration de logiciel locale.

"All" NE DOIT PAS être utilisé comme un <dist-name>. Les <dist-name> DEVRAIENT contenir au moins trois caractères, sauf quand ils sont les codes de pays à deux lettres tirés de [ISO3166-1]. Les <dist-name> sont insensibles à la casse (c'est-à-dire, "US", "Us", "uS", et "us" spécifient tous la même distribution).

Un FWS facultatif dans la <dist-list> NE DEVRAIT PAS être généré, mais DOIT être accepté.

 	3.2.5	Expires
Le champ d'en-tête Expires spécifie une date et une heure à laquelle le posteur estime que l'article n'est plus pertinent et pourrait utilement être supprimé ("expired").

Note : ce champ d'en-tête est utile quand le posteur désire un temps d'expiration inhabituellement long ou court.

expires =  "Expires:" SP date-time CRLF

Voir la remarque sous le paragraphe 3.1.1 concernant la syntaxe de <date-time> et les exigences et recommandations auxquelles il est sujet.

Note : le champ d'en-tête Expires est aussi parfois utilisé en messagerie avec une signification similaire ; voir la [RFC2156].

 	3.2.6	Followup-To
Le champ d'en-tête Followup-To spécifie à quels newsgroups le posteur a demandé que des suivis soient postés. Le champ d'en-tête Followup-To NE DEVRAIT PAS apparaître dans un message, sauf si son contenu est différent du contenu 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 celle du champ d'en-tête Newsgroups (paragraphe 3.1.4) avec l'exception que le mot-clé "poster" demande que les suivis devrait être envoyés directement par message au posteur de l'article (en utilisant les adresses contenues dans le champ d'en-tête Reply-To si il en existe un, autrement en utilisant les adresses contenues dans le champ d'en-tête From) plutôt que postés à un newsgroup. Les agents DOIVENT générer le mot-clé "poster" en minuscules, mais PEUVENT choisir de reconnaître les formes insensibles à la casse comme "Poster".

Comme dans le champ d'en-tête Newsgroups (paragraphe 3.1.4) un FWS facultatif dans la <newsgroup-list> NE DEVRAIT PAS être généré, mais DOIT être accepté.

 	3.2.7	Injection-Date
Le champ d'en-tête Injection-Date contient la date et l'heure à laquelle l'article a été injecté dans le réseau. Son objet est de permettre au serveur de nouvelles, quand il vérifie que l'article n'est pas "stale" (périmé) d'utiliser une <date-time> qui a été ajoutée par un serveur de nouvelles au moment de l'injection plutôt qu'une ajoutée par l'agent d'utilisateur au moment de la composition du message.

Ce champ d'en-tête DOIT être inséré chaque fois qu'un article est injecté. Cependant, les logiciels qui précèdent la présente norme n'utilisent pas cet en-tête, et donc les agents DOIVENT accepter les articles sans le champ d'en-tête Injection-Date.

injection-date  =  "Injection-Date:" SP date-time CRLF

Voir les remarques sous le paragraphe 3.1.1 concernant la syntaxe de <date-time> et les exigences et recommandations auxquelles il est sujet.

Note : comme les horloges des divers agents ne sont pas nécessairement synchronisées, la <date-time> dans ce champ d'en-tête pourrait n'être pas une valeur plus tardive que celle dans le champ d'en-tête Date. Les agents NE DOIVENT PAS altérer un champ d'en-tête Date pré-existant quand ils ajoutent un champ d'en-tête Injection-Date.

Ce champ d'en-tête est destiné à remplacer le champ d'en-tête "NNTP-Posting-Date" actuellement utilisé mais non documenté, dont l'usage est maintenant déconseillé.

 	3.2.8	Injection-Info
Le champ d'en-tête Injection-Info contient les informations fournies par le serveur de nouvelles injecteur sur comment un article est entré dans le système Netnews ; il aide à retracer la vraie origine de l'article. Il peut aussi spécifier une ou plusieurs adresses où des plaintes concernant le posteur de l'article peuvent être envoyées.

injection-info = "Injection-Info:" SP [CFWS] path-identity [CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLF

Note : la syntaxe de <parameter> (paragraphe 5.1 de la [RFC2045], telle qu'amendée par la [RFC2231]) en conjonction avec les règles de saut à la ligne de la [RFC0822] (note : pas la [RFC2822] ni la [RFC5322]) permet effectivement les "CFWS" d'un côté ou de l'autre de "=" dans un <parameter>.

Le tableau suivant montre l'<attribute> et le format de <valeur> pour chaque <parameter> défini avec ce champ d'en-tête.
Au plus, une occurrence de chaque <parameter> est permise.

<attribute>	format de <value>
"posting-host"	<host-value>
"posting-account"	toute <value>
"logging-data"	toute <value>
"mail-complaints-to"	<address-list>

où :

host-value = dot-atom-text / IPv4address / IPv6address / (dot-atom-text ":" ( IPv4address / IPv6address ))

Note :	comme toute <host-value> ou <address-list> doit aussi être une <value> syntaxiquement correcte, il va généralement être nécessaire de l'encapsuler comme une <quoted-string>, par exemple :
posting-host = "posting.exemple.com:192.0.2.1"

D'autres <attribute> NE DEVRAIENT PAS être utilisés sauf défini dans des extensions à la présente norme. Si des <attribute> non fondés sur des normes sont utilisés, ils DOIVENT commencer avec un "x-".

Bien que les commentaires et saut à la ligne d'espace soient permis dans le champ d'en-tête Injection-Info, le saut à la ligne NE DEVRAIT PAS être utilisé au sein d'un <parameter>. Le saut à la ligne DEVRAIT seulement se produire avant ou après le ";" séparant les <parameter>, et les commentaires DEVRAIENT seulement être utilisés à la suite du dernier <parameter>.

Note : certaines de ces informations étaient précédemment envoyées dans des champs d'en-tête non normalisés comme NNTP-Posting-Host, X-Trace, X-Complaints-To, et autres. Une fois qu'un serveur de nouvelles génère un champ d'en-tête Injection-Info, il ne devrait pas avoir besoin d'envoyer ces champs d'en-tête non standard.

Le <paramètre> "posting-host" spécifie le nom de domaine pleinement qualifié (FQDN, Fully Qualified Domain Name) et/ou l'adresse IP (IPv4address ou IPv6address) de l'hôte d'où le serveur de nouvelles a reçu l'article.

Note : si le <paramètre> "posting-host" échoue à identifier de façon déterministe l'hôte (par exemple, allocation dynamique d'adresse IP) le <paramètre> "posting-account" ou "logging-data" peut fournir des informations supplémentaires sur la vraie origine de l'article.

Le <paramètre> "posting-account" identifie la source d'où ce serveur de nouvelles a reçu l'article, dans une notation qui peut être interprétée par l'administrateur du serveur de nouvelles. Cette notation peut inclure toute information que l'administrateur estime pertinente. Afin de limiter l'exposition de données personnelles, elle DEVRAIT être donnée sous une forme qui ne puisse pas être interprétée par d'autres sites. Cependant, pour la rendre utile pour la limitation de débit et la détection d'abus, deux messages postés à partir de la même source DEVRAIENT avoir la même valeur de "posting-account", et deux messages provenant de sources différentes DEVRAIENT avoir des valeurs différentes  de "posting-account". La définition exacte de "source" est laissée à la discrétion de l'administrateur du serveur de nouvelles.

Le <paramètre> "logging-data" contient des informations (normalement un numéro de session ou autre moyen non persistant d'identifier un compte de postage) qui va permettre de déterminer la vraie origine de l'article par référence aux informations d'enregistrement conservées par le serveur de nouvelles.

Le <paramètre> "mail-complaints-to" spécifie une ou plusieurs boîtes aux lettres pour envoyer des plaintes concernant le comportement du posteur de l'article.

Lesquels  des <paramètre> ci-dessus inclure est l'affaire de la politique locale. Certains éléments d'information ont des implications de confidentialité ; c'est discuté dans [USEAGE].

 	3.2.9	Organization
Le champ d'en-tête Organization est une courte phrase identifiant l'organisation du posteur.

organization =  "Organization:" SP unstructured CRLF

Note : il n'y a pas de "s" dans "Organization".

 	3.2.10	References
Le champ d'en-tête References est le même que spécifié au paragraphe 3.6.4 de la [RFC5322], avec l'ajout des restrictions détaillées au paragraphe 2.2 et celles mentionnées ci-dessous :
o	La construction mise à jour <msg-id> définie au paragraphe 3.1.3 DOIT être utilisée.
o	Les identifiants de message DOIVENT être séparés par des CFWS.
o	Les commentaires dans les CFWS entre identifiants de message peuvent causer des problèmes d'interopérabilité, donc des commentaires 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 spécifiant un article à remplacer à l'arrivée de celui-ci. Un article contenant un champ d'en-tête Supersedes est équivalent à un message de contrôle "cancel" [RFC5537] pour l'article spécifié, suivi immédiatement par le nouvel article sans le champ d'en-tête Supersedes.

supersedes =  "Supersedes:" SP *WSP msg-id *WSP CRLF

Note : il n'y a pas de "c" dans "Supersedes".

Note : le champ d'en-tête Supersedes défini ici n'a pas de rapport avec le champ d'en-tête Supersedes qui apparaît parfois dans les messages électroniques convertis de X.400 conformément à la [RFC2156] ; en particulier, ici la syntaxe permet seulement un <msg-id> à la différence des multiples <msg-id> de cette version de messagerie.

 	3.2.13	User-Agent
Le champ d'en-tête User-Agent contient des informations sur l'agent d'utilisateur (normalement un lecteur de nouvelles) qui génère l'article, à des fins statistiques et de traçage des violations de norme d'un logiciel spécifique qui a besoin d'être corrigé. Il est entendu que ce champ d'en-tête convient pour être utilisé dans la messagerie é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 PEUT contenir plusieurs jetons <product> qui identifient l'agent d'utilisateur et tous les sous produits qui en forment une partie significative, dans l'ordre de leur signification pour identifier l'application.

Note : certaines de ces informations étaient précédemment envoyées dans des champs d'en-tête non normalisés comme X-Newsreader, X-Mailer, X-Posting-Agent, X-Http-User-Agent, et autres. Une fois qu'un agent d'utilisateur a généré un champ d'en-tête User-Agent, il ne devrait pas avoir besoin d'envoyer ces champs d'en-tête non standard.

Note : la [RFC2616] décrit une facilité similaire pour le protocole HTTP. Le format d'article Netnews en diffère en ce que "{" et "}" sont permis dans les jetons (<product> et <product-version>) et les commentaires sont permis partout où des espaces sont permises.

 	3.2.14	Xref
Le champ d'en-tête Xref indique où un article a été mémorisé par le dernier serveur de nouvelles qui l'a traité. Les agents d'utilisateur utilisent souvent les informations du champ d'en-tête Xref pour éviter de multiples traitements d'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 '(' et ';'

Le <server-name> est inclus pour que les logiciels puissent déterminer quel serveur de nouvelles a généré le champ d'en-tête. Les localisations spécifient où l'article est mémorisé -- c'est-à-dire, dans quels newsgroups (qui peuvent différer de ceux du champ d'en-tête Newsgroups) et où dans ces newsgroups. La forme exacte d'un <article-locator> est spécifique de la mise en œuvre.

Note : la forme traditionnelle d'un <article-locator> (comme exigée par la [RFC3977]) est un nombre décimal, avec les articles dans chaque newsgroup numérotés consécutivement en commençant à 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 [RFC0850], ainsi que Also-Control, Article-Names, Article-Updates, et See-Also définis dans [RFC1849] sont déclarés obsolètes. Voir les documents de spécification cités pour plus d'informations sur leur utilisation originale.

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 lignes dans le <corps> (comme défini dans la [RFC5322]) de l'article.

lines =  "Lines:" SP *WSP 1*DIGIT *WSP CRLF

Le compte de lignes est le nombre de séparateurs CRLF dans le <corps>.

Historiquement, ce champ d'en-tête était utilisé par la facilité de visionnage NNTP [RFC3977], mais son utilisation à cette fin est maintenant déconseillée. Par suite, ce champ d'en-tête est à considérer comme obsolescent, et il sera probablement supprimé entièrement dans une future version de ce standard. Tous les agents DEVRAIENT l'ignorer et NE DEVRAIENT PAS le générer.

 	4.	Considérations d'internationalisation

L'internationalisation des champs d'en-tête et corps d'article Netnews est fournie en utilisant les mécanismes MIME discutés au paragraphe 2.3. Noter 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é, comme la confidentialité, l'authentification de l'envoyeur, ou la non répudiation. De tels services devraient plutôt être mis en couche par dessus, en utilisant des protocoles comme S/MIME [RFC3851] ou PGP/MIME [RFC3156], ou par dessous, en utilisant des versions sûres des protocoles de transport de nouvelles. De plus, plusieurs protocoles actuellement non normalisés comme [PGPVERIFY] pourraient être normalisés dans un proche avenir.

Les identifiants de message (paragraphe 3.1.3) dans les articles de Netnews doivent être uniques ; les articles peuvent être refusés (dans le transfert de serveur à serveur) si l'identifiant a déjà été vu. Si un agent malveillant peut prédire l'identifiant d'un article, il peut préempter l'article en postant son propre article (éventuellement à un groupe assez différent) avec le même identifiant de message, empêchant ainsi l'article cible d'être propagé. Donc, les agents qui génèrent les identifiants de message pour les articles de Netnews DEVRAIENT s'assurer qu'ils sont imprévisibles.

Les considérations sur la sécurité de MIME sont discutées dans la [RFC2046]. Noter que la pleine gamme des codages permis pour les paramètres dans les [RFC2046] et [RFC2231] permet des constructions que des analyseurs simples peuvent échouer à analyser correctement ; des exemples de constructions difficiles à analyser sont :

Content-Type: multipart/mixed
     (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")

Content-Type: multipart/digest;
     boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy

De telles déficiences d'analyse peuvent être utilisées au titre d'une attaque.

Plus de considérations sur la sécurité sont discutées dans la [RFC5537].

 	6.	Considérations relatives à l'IANA

L'IANA a enregistré les champs d'en-tête suivants dans le registre des champs d'en-tête de message permanents, en accord avec les procédures de la [RFC3864].

Nom de champ d'en-tête : Also-Control
Protocole applicable : netnews
Statut : obsolète
Auteur/contrôleur des changements : IETF
Document de spécification : [RFC1849] (paragraphe 6.15)

Nom de champ d'en-tête : Approved
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2.1)

Nom de champ d'en-tête : Archive
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2.2)

Nom de champ d'en-tête : Article-Names
Protocole applicable : netnews
Statut : obsolète
Auteur/contrôleur des changements : IETF
Document de spécification : [RFC1849] (paragraphe 6.17)

Nom de champ d'en-tête : Article-Updates
Protocole applicable : netnews
Statut : obsolète
Auteur/contrôleur des changements : IETF
Document de spécification : [RFC1849] (paragraphe 6.18)

Nom de champ d'en-tête : Comments
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2), [RFC5322] (paragraphe 3.6.5)

Nom de champ d'en-tête : Control
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2.3)

Nom de champ d'en-tête : Date
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.1.1), [RFC5322] (paragraphe 3.6.1)

Nom de champ d'en-tête : Date-Received
Protocole applicable : netnews
Statut : obsolète
Auteur/contrôleur des changements : IETF
Document de spécification : [RFC0850] (paragraphe 2.2.4)

Nom de champ d'en-tête : Distribution
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2.4)

Nom de champ d'en-tête : Expires
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2.5)

Nom de champ d'en-tête : Followup-To
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2.6)

Nom de champ d'en-tête : From
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.1.2), [RFC5322] (paragraphe 3.6.2)

Nom de champ d'en-tête : Injection-Date
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2.7)

Nom de champ d'en-tête : Injection-Info
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2.8)

Nom de champ d'en-tête : Keywords
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2), [RFC5322] (paragraphe 3.6.5)

Nom de champ d'en-tête : Lines
Protocole applicable : netnews
Statut : déconseillé
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.3.1)
Informations en rapport : [RFC3977] (paragraphe 8.1)

Nom de champ d'en-tête : Message-ID
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.1.3)
Informations en rapport : [RFC5322] (paragraphe 3.6.4)

Nom de champ d'en-tête : Newsgroups
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe .1.4)

Nom de champ d'en-tête : NNTP-Posting-Date
Protocole applicable : netnews
Statut : obsolète
Auteur/contrôleur des changements : IETF
Document de spécification : aucun

Nom de champ d'en-tête : NNTP-Posting-Host
Protocole applicable : netnews
Statut : obsolète
Auteur/contrôleur des changements : IETF
Document de spécification : [RFC2980] (paragraphe 3.4.1)

Nom de champ d'en-tête : Organization
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2.9)

Nom de champ d'en-tête : Path
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.1.5)

Nom de champ d'en-tête : Posting-Version
Protocole applicable : netnews
Statut : obsolète
Auteur/contrôleur des changements : IETF
Document de spécification : [RFC0850] (paragraphe 2.1.2)

Nom de champ d'en-tête : References
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2.10), [RFC5322] (paragraphe 3.6.4)

Nom de champ d'en-tête : Relay-Version
Protocole applicable : netnews
Statut : obsolète
Auteur/contrôleur des changements : IETF
Document de spécification : [RFC0850] (paragraphe 2.1.1)

Nom de champ d'en-tête : Reply-To
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2), [RFC5322] (paragraphe 3.6.2)

Nom de champ d'en-tête : See-Also
Protocole applicable : netnews
Statut : obsolète
Auteur/contrôleur des changements : IETF
Document de spécification : [RFC1849] (paragraphe 6.16)

Nom de champ d'en-tête : Sender
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2), [RFC5322] (paragraphe 3.6.2)

Nom de champ d'en-tête : Subject
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.1.6), [RFC5322] (paragraphe 3.6.5)

Nom de champ d'en-tête : Summary
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2.11)

Nom de champ d'en-tête : Supersedes
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2.12)

Nom de champ d'en-tête : User-Agent
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2.13)
Informations en rapport : [RFC2616] (paragraphe 14.43)

Nom de champ d'en-tête : Xref
Protocole applicable : netnews
Statut : standard
Auteur/contrôleur des changements : IETF
Document de spécification : Le présent document (paragraphe 3.2.14)

 	7.	Références
 	7.1	Références normatives

[RFC2045]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", novembre 1996. (D. S., MàJ par 2184, 2231, 5335.)

[RFC2046]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 2 : Types de support", novembre 1996. (D. S., MàJ par 2646, 3798, 5147, 6657, 8098)

[RFC2047]	K. Moore, "MIME (Extensions de messagerie Internet multi-objets) Partie trois : extensions d'en-tête de message pour texte non ASCII", novembre 1996. (MàJ par RFC2184, RFC2231) (D.S.)

[RFC2049]	N. Freed, N. Borenstein, "Extensions multi-objets de la messagerie Internet (MIME) Partie cinq : critères de conformité et exemples", novembre 1996. (Remplace RFC1521, RFC1522, RFC1590) (D.S.)

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2183]	R. Troost, S. Dorner, K. Moore, éd., "Communication des informations de présentation dans les messages Internet : le champ d'en-tête Contenu-disposition", août 1997. (MàJ par RFC2184, RFC2231) (P.S.)

[RFC2231]	N. Freed, K. Moore, "Extensions MIME Valeur de paramètre et Mot codé : jeux de caractères, langages, et continuations", novembre 1997. (P.S.)

[RFC3282]	H. Alvestrand, "En-têtes de langage de contenu", mai 2002. (D.S.)

[RFC3986]	T. Berners-Lee, R. Fielding et L. Masinter, "Identifiant de ressource uniforme (URI) : Syntaxe générique", STD 66, janvier 2005. (P.S.  ; MàJ par RFC8820)

[RFC5234]	D. Crocker, P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", janvier 2008. (STD0068)

[RFC5322]	P. Resnick, éd., "Format du message Internet", octobre 2008. (D.S. ; Remplace RFC2822 ; MàJ RFC4021)

[RFC5537]	R. Allbery, Ed., C. Lindsey, "Architecture et protocoles de Netnews", novembre 2009, (Remplace la RFC1036, (P.S. ; MàJ par RFC8315)

 	7.2	Références pour information

[Errata]	"RFC Editor Errata", <http://www.rfc-editor.org/errata.php>.

[ISO3166-1]	Organisation Internationale de normalisation, "Codes pour la représentation des noms de pays et de leurs subdivisions -- Partie 1 : Codes de pays, 2ième édition", Norme ISO 3166, novembre 2006.

[PGPVERIFY]	Lawrence, D., "Authentication of Usenet Group Changes (pgpverify)", juin 1999, <ftp://ftp.isc.org/pub/pgpcontrol/README.html>.

[RFC0822]	D. Crocker, "Norme pour le format des messages de texte de l'ARPA-Internet", STD 11, août 1982. (Obsolète, voir RFC5322)

[RFC0850]	M. Horton, "Norme pour l'échange des messages USENET", juin 1983. (Remplacée par la RFC 1036)

[RFC1036]	M. Horton et R. Adams, "Norme pour l'échange de messages USENET", décembre 1987. (Remplacée par RFC5536)

[RFC2156]	S. Kille, "MIXER (Relais amélioré Mime Internet X.400) : transposition entre X.400 et la RFC0822/MIME", janvier  1998. (Remplace RFC0987, RFC1026, RFC1138, RFC1148, RFC1327, RFC1495) (MàJ RFC0822) (P.S.)

[RFC2616]	R. Fielding et autres, "Protocole de transfert hypertexte -- HTTP/1.1", juin 1999. (D.S., MàJ par 2817, 6585)

[RFC2822]	P. Resnick, "Format de message Internet", avril 2001. (Remplace la RFC0822, STD 11, Remplacée par RFC5322)

[RFC2980]	S. Barber, "Extensions communes à NNTP", octobre 2000. (MàJ par RFC3977, RFC4643, RFC4644) (Information)

[RFC3156]	M. Elkins et autres, "Sécurité MIME avec OpenPGP", août 2001.(P.S.)

[RFC3696]	J. Klensin, "Techniques d'application pour la vérification et la transformation des noms", février 2004. (Information)

[RFC3851]	B. Ramsdell, "Spécification du message d'extensions de messagerie Internet multi-objets/sécurisé (S/MIME) version  3.1", juillet 2004. (Obsolète, voir RFC5751)

[RFC3864]	G. Klyne, M. Nottingham, J. Mogul, "Procédures d'enregistrement pour les champs d'en-tête de message", septembre  2004. (BCP0090 ; MàJ par 9110)

[RFC3977]	C. Feather, "Protocole de transfert de nouvelles du réseau (NNTP)", octobre 2006. (P.S., MàJ par RFC    6048

[RFC1849]	H. Spencer, "Fils de 1036" : Format et transmission d'articles de nouvelles", octobre 1995. (Obsolète, voir 5536, 5537) 

[USEAGE]	Lindsey, C., "Usenet Best Practice", Travail en cours, mars 2005.

 	Appendice A.	Remerciements

Comme le présent document est le résultat de huit années d'efforts, le nombre de personnes qui y ont contribué est trop grand pour qu'on les mentionne individuellement. Un grand merci à tous les membres passés et présents du groupe de travail USEFOR de l'équipe d'ingénierie de l'Internet (IETF, Internet Engineering Task Force) et de sa liste de diffusion.

 	Appendice B.	Différences avec la RFC 1036 et ses dérivés

Cet appendice contient la liste des changements qui ont été faits au format de l'article Netnews depuis les normes antérieures, en particulier la [RFC1036].

o	Les conventions de la [RFC5322] pour les <comment> entre parenthèses dans les champs d'en-tête sont prises en charge dans tous les nouveaux champs d'en-tête définis et dans les champs d'en-tête hérités de la [RFC5322]. Ils sont cependant, toujours interdits pour des raisons de performances et/ou de compatibilité dans les champs d'en-tête Control, Distribution, Followup-To, Lines, Message-ID, Newsgroups, Path, Supersedes, et Xref.

o	Des adresses multiples sont permises dans le champ d'en-tête From.

o	Un "FWS" est permis dans les champs d'en-tête Newsgroups.

o	Une syntaxe améliorée pour le champ d'en-tête Path permet de déterminer avec plus de précision le point d'injection et la chemin suivi par un article.

o	Seulement un (1) identifiant de message est permis dans le champ d'en-tête Supersedes.

o	MIME est reconnu comme partie intégrante de Netnews.

o	Il y a un nouveau champ d'en-tête Injection-Date pour rendre plus précis le rejet d'articles périmés et pour minimiser les rejet parasites.

o	Plusieurs nouveaux champs d'en-tête facultatifs sont définis, notamment Archive, Injection-Info, et User-Agent, donnant des fonctionnalités accrues.

o	Certains champs d'en-tête, notamment Lines, ont été déconseillés ou rendus obsolètes (paragraphe 3.3).

o	La convention pour interpréter les sujets commençant par le mot "cmsg" comme message de contrôle a été supprimée.

o	Il y a de nombreux autres petits changements, précisions, et améliorations.

 	Appendice C.	Différences avec la RFC 5322

Cet appendice fait la liste des différences entre la syntaxe permise par le format d'article Netnews (le présent document) par rapport au format de message Internet, spécifié dans la [RFC5322].

Le format d'article Netnews est un sous ensemble strict du format de message Internet ; tous les articles Netnews se conforment à la syntaxe de la [RFC5322].

Les restrictions suivantes sont importantes :

o	Un SP (espace) est EXIGÉ après les deux-points (':') qui suivent le nom d'un champ d'en-tête.

o	Une syntaxe légèrement restreinte de <msg-id> (à utiliser par les champs d'en-tête Message-ID, References, et Supersedes) est définie.

o	La longueur d'un <msg-id> NE DOIT PAS excéder 250 octets.

o	Les commentaires ne sont pas admis dans le champ d'en-tête Message-ID.

o	Les CFWS entre les <msg-id> dans le champ d'en-tête References ne sont pas facultatifs.

o	Il est légal pour un analyseur de rejeter la syntaxe obsolète, sauf que :
*	La construction <obs-phrase> DOIT être acceptée.
*	La <zone> obsolète "GMT" DOIT être acceptée dans une <date-time>.

o	Chaque ligne d'un corps de champ d'en-tête (y compris la première et toutes celles qui sont ensuite mises à la ligne) DOIT contenir au moins un caractère non espace. Cela signifie qu'un corps de champ d'en-tête vide est illégal.

 	Adresse des auteurs

Kenneth Murchison (editor)	Charles H. Lindsey	Dan Kohn	
Carnegie Mellon University	University of Manchester	Healing Thresholds	
5000 Forbes Avenue	5 Clerewood Avenue	211 N End Ave Apt 22E	
Cyert Hall 285	Heald Green	New York, NY  10282	
Pittsburgh, PA  15213	Cheadle	U.S.A.	
U.S.A.	Cheshire  SK8 3JU	téléphone : +1 415 233 1000	
téléphone : +1 412 268 2638	U.K.	mél : dan@dankohn.com	
mél : murch@andrew.cmu.edu	téléphone : +44 161 436 6131		
	mél : chl@clerew.man.ac.uk