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 = value = parameter = attribute = FWS = comment = CFWS = atext = dot-atom-text = phrase = date-time = mailbox = mailbox-list = address-list = body = fields = IPv6address = IPv4address = ALPHA = CRLF = DIGIT = DQUOTE = SP = VCHAR = En outre, la section 3.1.3 spécifie une définition plus stricte de 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 (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 "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 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 , et dans tout ou 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 (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 (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 ), bien que désapprouvé, est courant dans les articles Netnews aujourd'hui. En conséquence, les agents DOIVENT accepter les constructions de 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 incluant un quelconque nom de zone défini par . 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ù 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 possibles permis par la RFC 5322. Cette section restreint donc la syntaxe de par rapport à la section 3.6.4 de la RFC 5322. L'obligation d'unicité globale pour 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 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, 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 - même s'ils sont communément dérivés des domaines , la partie droite 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 . Notez également que cette grammaire ABNF modifiée s'applique partout où 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 d'un 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 . Lorsqu'elles génèrent un , les implémentations DEVRAIENT utiliser un nom de domaine comme . NOTE : la section 3.6.4 de la RFC 5322 recommande que 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 NE DEVRAIENT PAS être générés, mais DOIVENT être acceptés. Un composant () NE DEVRAIT PAS être seulement constitué de chiffres et NE DEVRAIT PAS contenir de lettres majuscules. De tels 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 (). 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 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) est "example" (exemple) - le groupe "poster" (posteur) Les 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) est "to" - les groupes dont le premier (ou unique) est "control" - les groupes contenant le (ou composé du seul) "all" - les groupes contenant le (ou composé du seul) "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 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 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 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 (). Chaque dans la liste (qui n'inclut pas la ) indique, de droite à gauche, les agents qui ont successivement reçu l'article. L'utilisation de , 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 , affichant "!", sous-entend aucune vérification). NOTE : historiquement, l'élément 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 soient en majuscules, pour les distinguer des qui sont traditionnellement en minuscules. Un 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 est d'enregistrer une adresse IP. Le fait que les adresses IPv6 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 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 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 ). 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 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 indique l'action à prendre, et les arguments s'il y a lieu fournissent les détails nécessaires. Dans certains cas, le corps (, 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 "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 . DEVRAIT contenir au moins trois caractères, sauf dans le cas des codes de pays dérivés de la norme ISO3166-1. 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 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 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 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 et les obligations et recommandations qui s'y appliquent. NOTE : les horloges des différents agents ne sont pas nécessairement synchronisées donc 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 (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 . Le tableau suivant décrit les valeurs de et le format de pour chaque défini pour ce champ d'en-tête. Au plus une seule occurence de chaque est permise. format de -------------------- ----------------- "posting-host" une "posting-account" n'importe quelle "logging-data" n'importe quelle "mail-complaints-to" une liste où host-value = dot-atom-text / IPv4address / IPv6address / (dot-atom-text ":" ( IPv4address / IPv6address )) NOTE : Puisque toute valeur ou liste doit également être une syntaxiquement correcte, il est généralement nécessaire de l'encapsuler comme une chaîne citée , par exemple : posting-host = "posting.example.com:192.0.2.1" Un autre que ceux-ci NE DEVRAIT PAS être utilisé sauf s'il est défini par une extension de ce standard. Si des 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 . Le repliement DEVRAIT se produire seulement juste avant ou juste après le séparateur ";" entre deux . Les commentaires DEVRAIENT se trouver seulement après le dernier . 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 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 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 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 et ) 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 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 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 dépend des implémentations. NOTE : La forme traditionnelle de (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 (, 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 . 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 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", . [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, . [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 (utilisée dans les champs d'en-tête Message-ID, References et Supersedes) est définie. - La longueur d'un 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 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 DOIT être acceptée. * La obsolète "GMT" DOIT être acceptée dans un élément . - 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