Équipe d'ingénierie de l'Internet IETF)	F. Ellermann, xyzzy
Request for Comments: 5538	avril 2010
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle
ISSN: 2070-1721

Schémas d'URI "news" et "nntp"

Résumé
Le présent mémoire spécifie les schémas d'identifiant de ressource universels (URI, Uniform Resource Identifier) "news" et "nntp" qui étaient à l'origine définis dans la RFC 1738. L'objet de ce document est de permettre que la RFC 1738 soit rendue obsolète tout en conservant les informations sur ces schémas sur la voie de la normalisation.

Statut de ce mémoire
Ceci est un document de l’Internet sur la voie de la normalisation.

Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Tous les documents approuvés par l’IESG ne sont pas candidats à devenir une norme de l’Internet ; voir la Section 2 de la RFC5741.

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc5538 

Notice de droits de reproduction
Copyright (c) 2012 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é de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

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
2. Fondements	2
2.1 URI "nntp"	2
2.2 URI "news"	2
2.3 Parties d'interrogation, fragments, et normalisation	3
3. Syntaxe des URI "nntp"	3
4. Syntaxe des URI "news"	4
5. Remerciements	4
6. Considérations d'internationalisation	5
7. Considérations sur la sécurité	5
8. Considérations relatives à l'IANA	5
8.1 URI "snews"	5
8.2 Type d'accès "news-message-ID"	6
9. Références	6
9.1 Références normatives	6
9.2 Références pour information	6
Appendice A. ABNF collecté	7
Appendice B. Exemple détaillé	8
Adresse de l'auteur	9

 	1.	Introduction

La première définition pour de nombreux schémas d'URI apparaît dans la [RFC1738]. Le présent mémoire en extrait les schémas d'URI "news" et "nntp" pour permettre que ce matériel reste sur la voie de la normalisation si la [RFC1738] est passée au statut de "historique". Il appartient à une série de documents similaires comme les [RFC4156], [RFC4157], [RFC4248], et [RFC4266], qui sont discutés sur la liste de diffusion <mailto:uri@w3.org>.

Les définitions pour les schémas d'URI "news" et "nntp" donnés ici sont des mises à jour de la [RFC1738] sur la base de l'usage moderne de ces schémas. Le présent mémoire limite intentionnellement sa description du schéma d'URI "news" aux caractéristiques essentielles supposées fonctionner avec "tout navigateur" et un serveur du protocole de transfert de nouvelles du réseau (NNTP, Network News Transfer Protocol).

La [RFC3986] spécifie comment définir les schémas pour les URI ; elle explique aussi le terme de "localisateur de ressource universel" (URL, Uniform Resource Locator). Le protocole de transfert de nouvelles du réseau (NNTP) est spécifié dans la [RFC3977]. Le format d'article Netnews est défini dans la [RFC5536].

Le mot clé "DOIT" dans le présent mémoire est à interpréter comme décrit dans la [RFC2119]. UTF-8 est spécifié dans la [RFC3629]. La syntaxe utilise l'ABNF défini dans la [RFC5234].

 	2.	Fondements

Les schémas d'URI "news" et "nntp" identifient des ressources sur un serveur NNTP, des articles individuels, des newsgroups individuels, ou des ensembles de newsgroups.

Les agents d'utilisateur comme des navigateurs de la Toile qui prennent en charge ces schémas utilisent le protocole NNTP pour accéder aux ressources correspondantes. Les détails sur la façon de le faire, par exemple, employer un lecteur de nouvelles séparé ou intégré, dépendent de la mise en œuvre. L'accès par défaut associé à NNTP dans la [RFC3977] est 119.

 	2.1	URI "nntp"
Le schéma d'URI "nntp" identifie les articles dans un newsgroup sur un serveur NNTP spécifique. Dans la terminologie de la [RFC3986] cela signifie que les URI "nntp" ont un composant <authority> non vide ; il n'y a pas de <host> par défaut comme pour les schémas d'URI "file" ou "news".

Netnews est normalement distribué parmi plusieurs serveurs de nouvelles, en utilisant les mêmes noms de newsgroup mais des numéros d'article locaux. Un article disponible comme numéro 10 dans le groupe "exemple" sur le serveur "news.exemple.com" a très probablement un numéro différent sur tous les autres serveurs où le même article est encore disponible. Les utilisateurs qui ont la permission de lire et poster des articles sur "leur" serveur peuvent ne pas avoir la permission d'accéder à des articles sur un serveur "arbitraire" spécifié dans un URI "nntp".

Pour ces raisons, l'utilisation du schéma d'URI "nntp" est limitée, et elle est moins largement prise en charge par les agents d'utilisateur que le schéma d'URI similaire "news".

 	2.2	URI "news"
Le schéma d'URI "news" identifie les articles par leur "Message-ID" (identifiant de message) unique au monde, indépendant du serveur et du newsgroup. Les lecteurs de nouvelles prennent en charge l'accès aux articles par leur "Message-ID", sans les frais généraux d'un schéma d'URI. Dans les cas simples, ils font cela directement comme un client NNTP d'un serveur par défaut ou couramment utilisé comme configuré par l'utilisateur. Les agents d'utilisateur plus généraux utilisent le schéma d'URI "news" pour distinguer les "Message-ID" des constructions similaires comme d'autres schémas d'URI dans des contextes comme un corps de message de texte.

Le schéma d'URI "news" permet aussi l'identification de newsgroups ou ensembles de newsgroups indépendants d'un serveur spécifique. Pour Netnews, un groupe "exemple" a le même nom sur tout serveur portant ce groupe, des cas exotiques impliquant cependant des passerelles. Pour distinguer les "Message-ID" et les noms de newsgroup, le schéma d'URI "news" s'appuie sur le "@" entre la partie locale (côté gauche) et la partie domaine (côté droit) des "Message-ID".

La [RFC1738] offrait seulement un caractère générique (wildcard) pour les ensembles de newsgroups dans les URI "news", un "*" utilisé pour se référer à "tous les newsgroups disponibles". Dans la pratique courante, cela a été étendu à des degrés divers par différents agents d'utilisateur. Une extension NNTP connue comme <wildmat>, spécifiée dans la [RFC2980] et qui fait maintenant partie de la spécification NNTP de base, permet des schémas correspondants au style de la commande "find" de [POSIX]. Pour les besoins du présent mémoire, cela signifie que des caractères spéciaux supplémentaires doivent être permis dans les URI "news", certains d'entre eux codés en pourcentage comme exigé par la syntaxe d'URI globale [RFC3986]. Les agents d'utilisateurs et serveurs NNTP qui ne sont pas déjà conformes à la [RFC3977] ne mettent pas en œuvre toutes les parties de cette nouvelle caractéristique.

Un autre ajout couramment pris en charge à la syntaxe de la [RFC1738] est la spécification facultative d'un serveur au début des URI "news". Ce composant facultatif <authority> suit la syntaxe globale de la [RFC3986], précédé par une double barre oblique "//" et terminé par la prochaine barre oblique "/", le point d'interrogation "?", le signe numéro "#", ou la fin de l'URI.

 	2.3	Parties d'interrogation, fragments, et normalisation
Les fragments introduits par un signe numéro "#" sont spécifiés dans la [RFC3986] ; leur sémantique est indépendante du schéma d'URI, et leur résolution dépend du type de support.

Le présent mémoire ne spécifie pas une partie d'interrogation introduite par un point d'interrogation "?" pour les schémas d'URI "news" et "nntp", mais certaines mises en œuvre sont connues pour utiliser des parties d'interrogation à la place de fragments en interne pour viser des parties d'un type de support composite [RFC2046] dans les extension multi-objets de messagerie Internet (MIME, Multipurpose Internet Mail Extensions).

Il n'y a pas de segments de chemin spéciaux "." ou ".." dans les URL "news" et "nntp". Noter que "." et ".." ne sont pas des <newsgroup-name> valides.

Les producteurs d'URI doivent coder en pourcentage certains caractères spécifiés ci-dessous (Section 4) ; autrement, ils DOIVENT traiter un "Message-ID" sans crochets angulaires pour les URL "news" comme il est, c'est-à-dire, sensible à la casse.

 	3.	Syntaxe des URI "nntp"

Un URI "nntp" identifie un article par son numéro dans un newsgroup donné sur un serveur spécifié, ou il identifie le newsgroup sans numéro d'article.

nntpURL = "nntp:" server "/" group [ "/" article-number ]
server = "//" authority	; voir la RFC 3986
group = 1*( group-char / pct-encoded )
article-number = 1*16DIGIT  	; voir la RFC 3977
group-char = ALPHA / DIGIT / "-" / "+" / "_" / "."

Dans la forme avec un <article-number>, l'URL correspond en gros au contenu d'un champ d'en-tête <xref> comme spécifié dans la [RFC5536], remplaçant son <article-locator> plus général par le <article-number> utilisé avec NNTP.

Un <newsgroup-name> comme spécifié dans la [RFC5536] consiste en composants séparés par des points. Chaque composant contient une ou plusieurs lettres, chiffres, "-" (tiret), "+", ou "_" (souligné). Ces caractères peuvent être directement utilisés dans un segment d'un chemin dans un URI de la [RFC3986] ; aucun codage en pourcentage n'est nécessaire. Exemple :

nntp://news.serveur.exemple/exemple.group.ceci/12345

Un nom de newsgroup <wildmat-exact> comme spécifié dans la [RFC3977] permet (en théorie) tout caractère <UTF8-non-ascii> (voir la Section 6) et la plupart des caractères US-ASCII imprimables, à l'exclusion de "!", "*", ",", "?", "[", "\", et "]". Cependant, la [RFC5536] ne permet pas (encore) les caractères en dehors de <group-char> et donc, pour que la syntaxe reste simple, les caractères supplémentaires sont couverts ici par le <pct-encoded> (codage en pourcentage) comme défini dans la [RFC3986], car la plupart d'entre eux doivent de toute façon être codés en pourcentage (avec quelques exceptions, comme ":", ";", et "~"). Exemple :

nntp://wild.serveur.exemple/exemple.group.n%2Fa/12345

Dans la forme sans <article-number>, l'URL identifie un seul groupe sur le serveur spécifié. Ceci est aussi possible avec un URI "news" équivalent, et ce dernier est mieux pris en charge par les agents d'utilisateur. Exemple :

nntp://news.serveur.exemple/exemple.group.ceci
news://news.serveur.exemple/exemple.group.ceci

 	4.	Syntaxe des URI "news"

Un URI "news" identifie un article par son "Message-ID" univoque, ou il identifie un ensemble de newsgroups. De plus, il peut spécifier un serveur ; quand le serveur n'est pas spécifié, un serveur configuré par défaut pour l'accès Netnews est utilisé.

newsURL = "news:" [ server "/" ] ( article / newsgroups )
article = msg-id-core 	; voir la RFC 5536

La forme qui identifie un <article> est le <msg-id-core> de la [RFC5536] ; c'est un "Message-ID" sans crochets angulaires. Selon la [RFC3986], les caractères qui sont dans des <gen-delims> (un sous ensemble de <réservé>) avec le caractère "%", DOIVENT être codés en pourcentage (bien qu'il ne soit pas faux d'en coder d'autres). Précisément, les caractères permis dans <msg-id-core> qui doivent être codés sont "/"  "?"  "#"  "[" "]" et "%".

Noter qu'un agent qui cherche à interpréter un URI "news" a besoin de décoder tous les caractères codés en pourcentage avant de le passer à un serveur NNTP qui va agir sur lui.

Noter que "%3E" (">") n'est pas permis ; <msg-id-core> est autrement identique à id-gauche "@" id-droit, comme défini dans la [RFC5322].

La forme qui identifie <newsgroups> correspond au <wildmat-pattern> de la [RFC3977], un nom de newsgroup avec des caractères génériques (wildcard) "*" et "?". Tout "?" doit être codé en pourcentage comme "%3F" dans cette partie d'un URI.

Exemples (les deux premiers sont équivalents) :

news://news.serveur.exemple/*
news://news.serveur.exemple/
news://wild.serveur.exemple/exemple.groupe.th%3Fse
news:exemple.groupe.*
news:exemple.groupe.ceci

Sans les caractères génériques, cette forme de l'URL identifie un seul groupe si il n'est pas vide. Les agents d'utilisateur vont normalement essayer de présenter un survol des articles disponibles dans ce groupe, limitant probablement ce survol aux articles non lus les plus récents jusqu'à un maximum configuré.

Avec les caractères génériques, les agents d'utilisateur pourraient essayer de faire la liste des noms de groupe correspondants sur le serveur spécifié ou par défaut. Certains agents d'utilisateur prennent en charge seulement un <group> spécifique sans caractère générique, ou un seul "*" facultatif.

Comme noté au paragraphe 2.2, la présence d'un "@" dans un URI "news" ôte les ambiguïtés sur <article> et <newsgroups> pour les consommateurs d'URI. La nouvelle construction <message-id> spécifiée dans la [RFC3977] n'exige pas de "@". Depuis la [RFC0822], la syntaxe de "Message-ID" a été en relation étroite avec la syntaxe des adresses de messagerie avec un "@" séparant le côté gauche (partie locale des adresses, partie unique des identifiants de message) et le côté droit (partie domaine) et le présent mémoire s'en tient à la pratique connue de la [RFC1738].

 	5.	Remerciements

Henry Spencer a été la force motrice pour l'adoption de MIME dans Netnews ; il a enregistré le type d'accès MIME "message/external-body" "news-message-ID", discuté au paragraphe 8.2, en 1993 comme rappelé dans "Son-of-1036" [RFC1849].

"Le schéma d'URL "news" [GILMAN], par Alfred S. Gilman (mars 1998) a introduit des ajouts au schéma d'URI "news" original de la [RFC1738]. Certaines de ces idées sont maintenant largement prises en charge et reflétées par le schéma d'URI "news" révisé spécifié ici.

Merci à Alfred Hoenes, Charles Lindsey, Clive Feather, Chris Newman, Ken Murchinson, Kjetil T. Homme, Lars Magne Ingebrigtsen, Martin Duerst, Matt Seitz, Nicolas Krebs, Paul Hoffman, Pasi Eronen, Roy T. Fielding, Russ Allbery, Stephane Bortzmeyer, et Tom Petch pour leurs retours, contributions, ou encouragements.

Le _xml2rfc validator_ et _ABNF checker_ de Bill Fenner ont été d'une grande aide pour la création du présent mémoire (et pas seulement). Même chose pour les divers outils  _IETF tools_ écrits par Henrik Levkowetz.

 	6.	Considérations d'internationalisation

Les schémas d'URI ont été mis à jour pour prendre en charge les caractères UTF-8 codés en pourcentage dans les noms de newsgroup NNTP comme spécifié dans les [RFC3977] et [RFC3987].

Le format d'article Netnews de la [RFC5536] ne permet pas encore l'UTF-8 dans les <newsgroup-name> ; donc, les considérations bien connues sur la sécurité de Unicode et de UTF-8 ne sont pas mentionnées ici. Pour une vue d'ensemble, voir [UTR36] et la [RFC3629].

Le travail sur l'internationalisation des adresses de messagerie électronique (EAI, Email Address Internationalization) commencé dans la [RFC4952], n'est pas supposé changer la syntaxe d'un "Message-ID".

 	7.	Considérations sur la sécurité

De nombreuses considérations sur la sécurité des schémas d'URI sont discutées dans la [RFC3986]. Le protocole NNTP peut utiliser des mots de passe en clair pour l'authentification mais n'offre aucune confidentialité, et les deux sont considérés comme extrêmement non sûrs dans la pratique courante. Des solutions de remplacement et plus de considérations sur la sécurité par rapport à NNTP sont discutées dans les [RFC4642] et [RFC4643].

La syntaxe pour les schémas d'URI "news" et "nntp" contient la construction générale <authority> avec un <userinfo> facultatif défini dans la [RFC3986]. Comme noté dans la [RFC3986], la forme "user:password" d'un <userinfo> est déconseillée.

Les articles sur les serveurs NNTP expirent normalement après un certain temps. Après ce temps, les URI "news" et "nntp" correspondants ne peuvent plus fonctionner selon le serveur. Bien qu'un "Message-ID" soit supposé être unique au monde pour toujours, le protocole NNTP ne le garantit pas. Dans diverses conditions selon les serveurs, le même "Message-ID" pourrait être utilisé pour des articles différents, et des attaquants pourrait essayer de distribuer du contenu malveillant pour des URI "news" ou "nntp" connus.

Si un URI ne satisfait pas à la syntaxe générique de la [RFC3986], il est invalide, et des URI endommagés peuvent causer des désastres. Comparer avec la [RFC5064] pour des considérations de sécurité similaires.

 	8.	Considérations relatives à l'IANA

Le registre IANA des schémas d'URI a été mis à jour pour pointer sur le présent mémoire au lieu de la [RFC1738] pour les schémas d'URI "news" et "nntp".

 	8.1	URI "snews"
Ce paragraphe contient le gabarit de la [RFC4395] pour l'enregistrement du schéma historique "snews" spécifié dans [GILMAN].

Nom de schéma d'URI : snews
Statut : historique
Syntaxe du schéma d'URI : la même que pour "news" (Section 4).
Sémantique du schéma d'URI : syntaxiquement équivalent à "news", mais en utilisant NNTP sur SSL/TLS (SSL/TLS avec couche de sécurité est négocié immédiatement après l'établissement de la connexion TCP) avec un accès par défaut de 563, enregistré comme "nntps".
Considérations de codage : les mêmes que pour "news" (Section 6).
Applications/protocoles qui utilisent ce nom de schéma d'URI : pour certains agents d'utilisateur, les URL "snews" déclenchent l'utilisation de "nntps" au lieu de NNTP pour leur accès à Netnews.
Considérations d'interopérabilité : ce schéma d'URI n'a pas été largement déployé ; son usage est maintenant déconseillé en faveur des URL "news"  ordinaires en conjonction avec les serveurs NNTP qui prennent en charge la [RFC4642].
Considérations de sécurité : voir la [RFC4642] ; l'utilisation d'un accès dédié pour des variantes sûres du protocole a été déconseillée dans la [RFC2595]
Contact : <mailto:uri@w3.org> (liste de diffusion URI)
Contrôleur des changements : IETF
Références : RFC 5538, [RFC4642], [GILMAN]

 	8.2	Type d'accès "news-message-ID"
Le type d'accès MIME "news-message-ID" était par erreur mentionné comme un sous type. L'IANA a supprimé "news-message-ID" du registre de sous type d'application, et l'a ajouté au registre des types d'accès défini dans la [RFC4289].

La [RFC4289] exige une RFC (de préférence sur la voie de la normalisation) pour le registre des types d'accès. Pour fournir une définition satisfaisant cette exigence, le paragraphe qui suit est reproduit de la [RFC1849] :

Note : Dans le cas spécifique où il est désiré essentiellement de faire d'un autre article une PARTIE de l'article en cours, par exemple, pour l'annotation de l'autre article, la convention MIME "message/external-body" peut être utilisée pour ce faire sans inclusion réelle. "news-message-ID" a été enregistré comme une méthode standard d'accès à un corps externe, avec un paramètre obligatoire NAME donnant l'identifiant de message et un paramètre facultatif SITE suggérant un site NNTP qui pourrait avoir l'article disponible (si il n'est pas disponible localement). IANA 22 juin 1993.

On notera que les URI "news" offrent une façon très similaire et (aujourd'hui) plus courante d'accéder aux articles par leur identifiant de message ; à comparer avec la [RFC2017].

 	9.	Références
 	9.1	Références normatives

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

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

[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)

[RFC5536]	K. Murchison, C. Lindsey, D. Kohn, "Format des articles pour Netnews", novembre 2009. (Remplace RFC1036 (P.S.)

 	9.2	Références pour information

[GILMAN]	Gilman, A., "The 'news' URL scheme", Travail en cours, mars 1998.

[POSIX]	Institute of Electrical and Electronics Engineers, "The Open Group Base Specifications Issue 6", IEEE Standard 1003.1, édition 2004.

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

[RFC1738]	T. Berners-Lee et autres, "Localisateurs uniformes de ressource (URL)", décembre   1994. (P.S., Obsolète, voir les RFC4248 et 4266 ; MàJ par RFC8089)

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

[RFC2017]	N. Freed, K. Moore, A. Cargille, "Définition du type d'accès de corps extérieur MIME d'URL", octobre 1996. (P.S.)

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

[RFC2595]	C. Newman, "Utilisation de TLS avec IMAP, POP3 et ACAP", juin 1999. (MàJ par RFC4616, 7817, 8314) (P.S.)

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

[RFC3629]	F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", STD 63, novembre 2003, DOI 10.17487/RFC3629.

[RFC3987]	M. Duerst et M. Suignard, "Identifiant de ressource internationalisé (IRI)", janvier 2005.

[RFC4156]	P. Hoffman, "Schéma d'URI wais", août 2005. (Historique)

[RFC4157]	P. Hoffman, "Schéma d'URI prospero", août 2005. (Historique)

[RFC4248]	P. Hoffman, "Schéma d'URI telnet", octobre 2005. (Remplace RFC1738) (P.S. ; MàJ par RFC8089)

[RFC4266]	P. Hoffman, "Le schéma d'URI gopher", novembre 2005. (Remplace RFC1738) (P.S. ; MàJ par RFC8089)

[RFC4289]	N. Freed, J. Klensin, "Extensions multi-objet de messagerie Internet (MIME) Partie quatre : Procédures d'enregistrement", décembre 2005. (Remplace RFC2048) (BCP0013)

[RFC4395]	T. Hansen et autres, "Lignes directrices et procédures d'enregistrement pour les nouveaux schémas d'URI", février 2006. (Remplace RFC2717, RFC2718) (BCP0115)

[RFC4642]	K. Murchison et autres, "Utilisation de la sécurité de la couche transport (TLS) avec le protocole de transfert des nouvelles du réseau (NNTP)", octobre 2006. (P.S. ; MàJ par RFC8143)

[RFC4643]	J. Vinocur, K. Murchison, "Extension d'authentification pour le protocole de transfert des nouvelles du réseau (NNTP)", octobre 2006. (MàJ RFC2980) (P.S.)

[RFC4952]	J. Klensin, Y. Ko, "Généralités et cadre pour la messagerie électronique internationalisée", juillet 2007. (Remplacée par la RFC6530) (Information)

[RFC5064]	M. Duerst, "Le champ d'en-tête de message Archived-At", décembre 2007. (P.S.)

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

[UTR36]	Davis, M. et M. Suignard, "Unicode Security Considerations", Unicode Technical Reports #36, août 2006.

 	Appendice A.	ABNF collecté

En plus de la syntaxe donnée ci-dessus, le présent appendice fait aussi la liste des sources des termes utilisés dans les commentaires et les développements :

nntpURL = "nntp:" server "/" group [ "/" article-number ]
server = "//" authority 	; voir la RFC 3986
group = 1*( group-char / pct-encoded )
article-number  = 1*16DIGIT	; voir la RFC 3977
group-char = ALPHA / DIGIT / "-" / "+" / "_" / "."

newsURL = "news:" [ server "/" ] ( article / newsgroups )
article = msg-id-core 	; voir la RFC 5536
newsgroups = *( group-char / pct-encoded / "*" )

authority = <voir la RFC 3986 paragraphe 3.2>
host = <voir la RFC 3986 paragraphe 3.2.2>
pct-encoded = <voir la RFC 3986 paragraphe 2.1>
port = <voir la RFC 3986 paragraphe 3.2.3>
gen-delims = <voir la RFC 3986 paragraphe 2.2>
msg-id-core = <voir la RFC 5536 paragraphe 3.1.3>
réservé = <voir la RFC 5536 paragraphe 2.2>
userinfo = <voir la RFC 3986 paragraphe 3.2.1>

message-id = <voir la RFC 3977 paragraphe 9.8>
UTF8-non-ascii  = <voir la RFC 3977 paragraphe 9.8>
wildmat = <voir la RFC 3977 paragraphe 4.1>
wildmat-exact = <voir la RFC 3977 paragraphe 4.1>
wildmat-pattern = <voir la RFC 3977 paragraphe 4.1>

ALPHA = <voir la RFC 5234 Appendice B.1>
DIGIT = <voir la RFC 5234 Appendice B.1>

article-locator = <voir la RFC 5536 paragraphe 3.2.14>
newsgroup-name = <voir la RFC 5536 paragraphe 3.1.4>
xref = <voir la RFC 5536 paragraphe 3.2.14>
 	Appendice B.	Exemple détaillé

Voici un exemple d'un message à la liste <mailto:tools.discuss@ietf.org> avec le "Message-ID" <p0624081dc30b8699bf9b@[10.20.30.108]>.

<http://dir.gmane.org/gmane.ietf.tools> est une des diverses archives de liste ; il convertit la messagerie en articles Netnews. L'en-tête de cet article contient les champs suivants (entre autres) :

Message-ID: <p0624081dc30b8699bf9b@[10.20.30.108]>
Xref: news.gmane.org gmane.ietf.tools:742
Archived-At: <http://permalink.gmane.org/gmane.ietf.tools/742>

Le "Xref" indique en gros le 742ième article dans le newsgroup <news://news.gmane.org/gmane.ietf.tools> sur ce serveur. Un URL "nntp" pourrait être <nntp://news.gmane.org/gmane.ietf.tools/742>. Pour les détails sur l'URL "Archived-At", voir la [RFC5064].

Le logiciel de liste et les abonnés à la liste qui lisent la liste ailleurs ne peuvent pas prédire un numéro d'article 742 spécifique du serveur dans cette archive. Si ils connaissent le serveur, ils peuvent cependant deviner l'URL <news://news.gmane.org/p0624081dc30b8699bf9b@%5B10.20.30.108%5D> correspondant.

Théoriquement, le logiciel de liste pourrait utiliser l'URL "news" deviné dans un champs d'en-tête "Archived-At", mais si une liste essaye cela, elle va probablement utiliser : 
<http://mid.gmane.org/p0624081dc30b8699bf9b@%5B10.20.30.108%5D>.

Utiliser des littéraux de domaine dans un "Message-ID" pourrait causer des collisions. Une collision pourrait forcer la passerelle mail2news dans cet exemple à inventer un nouvel "Message-ID", et une tentative de deviner le futur URL sur ce serveur va alors échouer.

 	Adresse de l'auteur

Frank Ellermann
xyzzy
Hamburg, Germany

mél : hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com
URI : http://purl.net/xyzzy/