Groupe de travail Réseau	J. Vinocur, Cornell University
Request for Comments : 4644	K. Murchison, Carnegie Mellon University
RFC mise à jour : 2980	octobre 2006
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Extension d'alimentation en direct pour le protocole de transfert des nouvelles du réseau (NNTP)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation 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 "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2006). Tous droits réservés.

Résumé
Le présent mémoire définit une extension au protocole de transfert des nouvelles du réseau (NNTP, Network News Transfer Protocol) pour fournir un transfert asynchrone (aussi appelé "en direct") d'articles. Cela permet aux serveurs de transférer des articles aux autres serveurs avec une efficacité beaucoup plus grande.

Le présent document met à jour et formalise les commandes CHECK et TAKETHIS spécifiées dans la RFC 2980 et déconseille la commande MODE STREAM.
Table des matières
1. Introduction	1
1.1 Conventions utilisées dans ce document	2
2. Extension STREAMING	2
2.1 Transfert d'article Streaming	2
2.2 Annonce de l'extension STREAMING	2
2.3 Commande MODE STREAM	3
2.4 Commande CHECK 	4
2.5 Commande TAKETHIS	5
3. Syntaxe BNF augmenté pour l'extension STREAMING	6
3.1 Commandes	6
3.2 Commande Datastream	6
3.3 Réponses	7
3.4 Entrées de capacités	7
4. Sommaire des codes de réponse	7
5. Considérations sur la sécurité	8
6. Considérations relatives à l'IANA	8
7. Remerciement	8
8. Références	8
8.1 Références normatives	8
8.2 Référence pour information	9
Adresse des auteurs	9
Déclaration complète de droits de reproduction	9

 	1.	Introduction

Selon la spécification de NNTP [RFC3977], un homologue utilise la commande IHAVE pour demander si un serveur veut un article particulier. Parce que la commande IHAVE ne peut pas être traitée en parallèle, le besoin d'arrêter et attendre que l'extrémité distante envoie sa réponse restreint beaucoup le débit qui peut être réalisé.

Les commandes ad-hoc CHECK et TAKETHIS, originellement documentées dans la [RFC2980], fournissent une méthode de remplacement pour le transfert d'article d'homologue à homologue qui permet une utilisation plus efficace de la bande passante du réseau. Du fait de leur utilité prouvée et de leur large déploiement, elles sont formalisée dans la présente spécification.

La commande ad-hoc MODE STREAM, aussi documentée dans la [RFC2980], est déconseillée par la présente spécification, mais du fait de sa large utilisation, elle est documentée ici pour la rétro compatibilité.

 	1.1	Conventions utilisées dans ce document
Les conventions de notation utilisées dans le présent document sont les mêmes que celles de la [RFC3977] et tout terme non défini dans le présent document a la même signification que dans celle là.

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].

Le présent document suppose le lecteur familiarisé avec NNTP [RFC3977]. En général, les connexions décrites ci-dessous sont d'un homologue à l'autre, mais on continuera d'utiliser "client" pour signifier l'initiateur de la connexion NNTP, et "serveur" pour désigner l'autre point d'extrémité.

Dans les exemples, les commandes du client sont indiquées par [C], et les réponses du serveur sont indiquées par [S].

 	2.	Extension STREAMING

Cette extension fournit trois nouvelles commandes : MODE STREAM, CHECK, et TAKETHIS. L'étiquette de capacité pour cette extension est STREAMING.

 	2.1	Transfert d'article Streaming
L'extension STREAMING fournit la même fonctionnalité que la commande IHAVE ([RFC3977] paragraphe 6.3.2) mais sépare la fonction d'interrogation et de transfert dans les commandes respectivement CHECK et TAKETHIS. Cela permet aux commandes CHECK et TAKETHIS d'être traitées en parallèle ([RFC3977] paragraphe 3.5) et fournit le transfert d'article en "streaming".

Un client de streaming va souvent traiter en parallèle de nombreuses commandes CHECK et utiliser les réponses pour construire une liste d'articles à envoyer par une séquence en parallèle de commandes TAKETHIS, augmentant donc la fraction de temps passé à transférer les articles. Les commandes CHECK et TAKETHIS utilisent des codes de réponse distincts afin que ces commandes puissent être entrelacées dans un tuyau et que la réponse à toute commande puisse être identifiée de façon définitive par le client.

Le client PEUT envoyer des articles via TAKETHIS sans d'abord interroger le serveur avec CHECK. Le client NE DEVRAIT PAS envoyer chaque article de cette façon sauf si il est explicitement configuré à le faire par l'administrateur du site sur la base d'informations hors bande. Cependant, le client PEUT utiliser une stratégie adaptative où il envoie initialement les commandes CHECK pour tous les articles, mais passe à l'utilisation de TAKETHIS sans CHECK si la plupart des articles sont acceptés (plus de 95 % d'acceptation pourrait être une métrique raisonnable dans certaines configurations). Si le client utilise une telle stratégie, il DEVRAIT aussi revenir à l'utilisation de CHECK sur tous les articles si le taux d'acceptation tombe bien en dessous de ce seuil.

 	2.2	Annonce de l'extension STREAMING
Un serveur qui prend en charge les commandes de streaming décrites dans ce document vont annoncer l'étiquette de capacité "STREAMING" en réponse à la commande CAPABILITIES ([RFC3977] paragraphe 5.2). Le serveur DOIT continuer d'annoncer cette capacité après qu'un client a produit la commande MODE STREAM. Cette capacité PEUT être annoncée aussi bien avant qu'après toute utilisation de la commande MODE READER ([RFC3977] paragraphe 5.3) avec la même sémantique.

Exemple d'un client utilisant CAPABILITIES et MODE STREAM sur un serveur en mode commutation :

[C] CAPABILITIES
[S] 101 Liste de capacités :
[S] VERSION 2
[S] MODE-READER
[S] IHAVE
[S] LIST ACTIVE
[S] STREAMING
[S] .
[C] MODE STREAM
[S] 203 Streaming permis
[C] CAPABILITIES
[S] 101 Liste de capacités :
[S] VERSION 2
[S] MODE-READER
[S] IHAVE
[S] LIST ACTIVE
[S] STREAMING
[S] .
[C] MODE READER
[S] 200 Envoi permis
[C] CAPABILITIES
[S] 101 Liste de capacités :
[S] VERSION 2
[S] READER
[S] POST
[S] LIST ACTIVE NEWSGROUPS HEADERS
[S] HDR
[S] .

 	2.3	Commande MODE STREAM
Historiquement, cettte commande était utilisée par un client pour découvrir si un serveur prend en charge les commandes CHECK et TAKETHIS. Cette commande est déconseillée en faveur de la commande de découverte de CAPABILITIES et n'est fournie que pour la compatibilité avec les mises en œuvre traditionnelles de la [RFC2980] de ces commandes de transport.

Les nouveaux clients DEVRAIENT utiliser la commande CAPABILITIES pour vérifier la prise en charge par un serveur de l'extension STREAMING mais ils PEUVENT utiliser la commande MODE STREAM pour la rétro compatibilité avec les serveurs traditionnels qui ne prennent pas en charge la commande de découverte de CAPABILITIES. Les serveurs DOIVENT accepter la commande MODE STREAM pour la rétro compatibilité avec les clients traditionnels qui n'utilisent pas la commande de découverte de CAPABILITIES.

Note : cette commande pourra être supprimée dans une future version de cette spécification, donc les clients sont invités à passer à la commande CAPABILITIES chaque fois que possible.

 	2.3.1	Usage
Syntaxe : MODE STREAM

Réponses : 203 Streaming permis

 	2.3.2	Description
Si un serveur prend en charge cette extension, il DOIT retourner une réponse 203 à la commande MODE STREAM (ou 501 si un argument est donné). La commande MODE STREAM NE DOIT affecter en aucune façon l'état du serveur (c'est-à-dire, ce n'est pas un changement de mode en dépit de son nom) donc cette commande PEUT être traitée en parallèle. Un serveur NE DOIT PAS exiger que la commande MODE STREAM soit produite par le client avant d'accepter les commandes CHECK ou TAKETHIS.

 	2.3.3	Exemples
Exemple d'un client qui vérifie la capacité d'écouler en direct des articles sur un serveur qui ne prend pas en charge cette extension :

[C] MODE STREAM
[S] 501 variante de MODE inconnue

Exemple d'un client vérifiant la capacité d'écouler en direct des articles sur un serveur qui prend en charge cette extension :

[C] MODE STREAM
[S] 203 Streaming permis

 	2.4	Commande CHECK 
 	2.4.1	Usage
Syntaxe : CHECK message-id

Réponses :
238 message-id   Envoyer l'article à transférer
431 message-id   Transfert impossible ; réessayer plus tard
438 message-id   Article non voulu

Paramètres :
message-id = Article message-id

Le premier paramètre des réponses 238, 431, et 438 DOIT être l'identifiant de message fourni par le client comme paramètre de CHECK.

 	2.4.2	Description
La commande CHECK informe le serveur que le client a un article avec l'identifiant de message spécifié. Si le serveur désire une copie de cet article, une réponse 238 DOIT être retournée, indiquant que le client peut envoyer l'article en utilisant la commande TAKETHIS. Si le serveur ne veut pas l'article (si, par exemple, le serveur en a déjà une copie) une réponse 438 DOIT être retournée, indiquant que l'article n'est pas voulu. Finalement, si l'article n'est pas voulu immédiatement mais que le client devrait réessayer plus tard si possible (si, par exemple, un autre client a offert d'envoyer le même article au serveur) une réponse 431 DOIT être retournée.

Note : les réponses à CHECK sont indicatives ; le serveur NE DOIT PAS s'appuyer sur l'idée que le client va se comporter comme demandé par ces réponses.

 	2.4.3	Exemples
Exemple d'un client qui vérifie si le serveur aimerait un ensemble d'articles et qui obtient une mélange de réponses :

[C] CHECK <je.suis.un.article.que.tu.veux@exemple.com>
[S] 238 <je.suis.un.article.que.tu.voudras@exemple.com>
[C] CHECK <je.suis.un.article.que.tu.as@exemple.com>
[S] 438 <je.suis.un.article.que.tu.as@exemple.com>
[C] CHECK <je.suis.un.article.que.tu.ajournes@exemple.com>
[S] 431 <je.suis.un.article.que.tu.ajournes@exemple.com>

Exemple de traitement en parallèle des commandes CHECK dans l'exemple précédent :

[C] CHECK <je.suis.un.article.que.tu.voudras@exemple.com>
[C] CHECK <je.suis.un.article.que.tu.as@exemple.com>
[C] CHECK <je.suis.un.article.que.tu.ajournes@exemple.com>
[S] 238 <je.suis.un.article.que.tu.voudras@exemple.com>
[S] 438 <je.suis.un.article.que.tu.as@exemple.com>
[S] 431 <je.suis.un.article.que.tu.ajournes@exemple.com>

 	2.5	Commande TAKETHIS
 	2.5.1	Usage
Un client NE DOIT PAS utiliser cette commande si le serveur n'annonce pas la capacité STREAMING ou retourne une réponse 203 à la commande MODE STREAM.

Syntaxe : TAKETHIS message-id

Réponses :
239 message-id   Article transféré OK
439 message-id   Transfert rejeté ; ne pas réessayer

Paramètres :
message-id = Article message-id

Le premier paramètre des réponses 239 et 439 DOIT être l'identifiant de message fourni par le client comme paramètre de TAKETHIS.

 	2.5.2	Description
La commande TAKETHIS est utilisée pour envoyer un article avec l'identifiant de message spécifié au serveur. L'article est envoyé immédiatement à la suite du CRLF de fin de la ligne de commande TAKETHIS. Le client DOIT envoyer l'article entier, incluant les en-têtes et le corps, au serveur comme un bloc de données multi lignes ([RFC3977] paragraphe 3.1.1). Donc, un seul point (".") sur une ligne indique la fin du texte, et les lignes commençant par un point dans le texte original ont ce point doublé durant la transmission. Le serveur DOIT retourner soit une réponse 239, indiquant que le transfert de l'article a réussi, soit une réponse 439 , indiquant que l'article a été rejeté. Si le serveur rencontre une erreur temporaire qui l'empêche de traiter l'article mais ne veut pas rejeter l'article, il DOIT renvoyer une réponse 400 au client et clore la connexion.

Cette fonction diffère de la commande POST en ce qu'elle est destinée à être utilisée dans le transfert d'articles déjà postés entre les hôtes. Elle NE DEVRAIT PAS être utilisée quand le client est un programme personnel de lecture de nouvelles, car utiliser cette commande indique que l'article a déjà été posté à un autre site et est simplement transmis d'un autre hôte. Cependant, en dépit de cela, le serveur PEUT choisir de ne pas poster ou transmettre l'article si, après examen de l'article, il n'estime pas approprié de le faire. Les raisons d'un tel rejet ultérieur d'un article peuvent inclure des problèmes tels que des groupes de nouvelles ou des distributions inappropriés, des limitations d'espace de disque, la longueur des articles, des en-têtes endommagés, et autres. Ces restrictions sont normalement appliquées par le logiciel de nouvelles de l'hôte du serveur et pas nécessairement par le serveur NNTP lui-même.

Le client NE DEVRAIT PAS supposer que l'article a été transféré avec succès sauf si il reçoit une réponse affirmative de la part du serveur. Un manque de réponse (comme l'abandon d'une connexion réseau ou une fin de temporisation dans le réseau) ou une réponse 400 DEVRAIT être traité comme une défaillance temporaire et causer un nouvel essai de transfert plus tard si possible.

Parce que certains logiciels de serveur de nouvelles peuvent n'être pas immédiatement capables de déterminer si un article convient pour postage ou transmission, un serveur NNTP PEUT accuser réception de la réussite du transfert de l'article (avec une réponse 239) mais l'éliminer en silence plus tard.

 	2.5.3	Exemples
Exemple d'envoi de deux articles à un autre site (le premier article est accepté et le second est rejeté) :

[C] TAKETHIS <je.suis.un.article.que.tu.voudras@exemple.com>
[C] Path: pathost!demo!somewhere!not-for-mail
[C] From: "Demo User" <personne@exemple.com>
[C] Newsgroups: misc.test
[C] Subject: Je suis juste un article d'essai
[C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: Un Exemple Com, San Jose, CA
[C] Message-ID: <je.suis.un.article.que.tu.voudras@exemple.com>
[C]
[C] Ceci est juste un article d'essai.
[C] .
[C] TAKETHIS <je.suis.un.article.que.tu.as@exemple.com>
[C] Path: pathost!demo!somewhere!not-for-mail
[C] From: "Demo User" <personne@exemple.com>
[C] Newsgroups: misc.test
[C] Subject: Je suis juste un article d'essai
[C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: Un Exemple Com, San Jose, CA
[C] Message-ID: <je.suis.un.article.que.tu.as@exemple.com>
[C]
[C] Ceci est juste un article d'essai.
[C] .
[S] 239 <je.suis.un.article.que.tu.voudras@exemple.com>
[S] 439 <je.suis.un.article.que.tu.as@exemple.com>

Exemple d'envoi d'un article à un site où le transfert échoue :

[C] TAKETHIS <je.suis.un.article.que.tu.voudras@exemple.com>
[C] Path: pathost!demo!somewhere!not-for-mail
[C] From: "Demo User" <personne@exemple.com>
[C] Newsgroups: misc.test
[C] Subject: Je suis juste un article d'essai
[C] Date: 6 Oct 1998 04:38:40 -0500
[C] Organization: Un Exemple Com, San Jose, CA
[C] Message-ID: <je.suis.un.article.que.tu.voudras@exemple.com>
[C]
[C] Ceci est juste un article d'essai.
[C] .
[S] 400 Service temporairement indisponible
[Le serveur clôt la connexion.]

 	3.	Syntaxe BNF augmenté pour l'extension STREAMING

Cette Section décrit la syntaxe formelle de l'extension STREAMING en utilisant l'ABNF [RFC4234]. Elle étend la syntaxe de la Section 9 de la [RFC3977], et les non terminaux non définis dans le présent document y sont définis. L'ABNF de la [RFC3977] devrait être importé avant de tenter de valider ces règles.

 	3.1	Commandes
Cette syntaxe étends le non terminal "command", qui représente une commande NNTP.

command =/ check-command / mode-stream-command / takethis-command

check-command             = "CHECK" WS message-id
mode-stream-command = "MODE" WS "STREAM"
takethis-command          = "TAKETHIS" WS message-id

 	3.2	Commande Datastream
Cette syntaxe étend le non terminal "command-datastream", qui représente la suite du matériel envoyé par le client dans le cas de commandes de streaming.

command-datastream =/ takethis-datastream

takethis-datastream = encoded-article

 	3.3	Réponses
Cette syntaxe étend le non terminal "initial-response-content", qui représente une ligne de réponse initiale envoyée par le serveur.

initial-response-content =/ response-238-content / response-239-content / response-431-content / response-438-content / response-439-content

response-238-content = "238" SP message-id
response-239-content = "239" SP message-id
response-431-content = "431" SP message-id
response-438-content = "438" SP message-id
response-439-content = "439" SP message-id

 	3.4	Entrées de capacités
Cette syntaxe étend le non terminal "capacity-entry", qui représente une capacité qui peut être annoncée par le serveur.

capacity-entry =/ streaming-capacity

streaming-capacity = "STREAMING"

 	4.	Sommaire des codes de réponse

Cette section contient une liste de chaque nouveau code de réponse défini dans le présent document et indique si il est multi lignes, quelles commandes peuvent le générer, quels arguments il a, et quelle est sa signification.

Code de réponse 203
Généré par: MODE STREAM
Signification : streaming permis.

Code de réponse 238
Généré par: CHECK
Argument : message-id
Signification : envoyer l'article à transférer.

Code de réponse 239
Généré par: TAKETHIS
Argument : message-id
Signification : article bien transféré.

Code de réponse 431
Généré par: CHECK
Argument : message-id
Signification : transfert impossible ; ressayer plus tard.

Code de réponse 438
Généré par: CHECK
Argument : message-id
Signification : article non voulu.

Code de réponse 439
Généré par: TAKETHIS
Argument : message-id
Signification : transfert rejeté ; ne pas réessayer.

 	5.	Considérations sur la sécurité

Aucune nouvelle considération de sécurité n'est introduite par cette extension, au delà de celles déjà décrites dans la spécification principale [RFC3977].

 	6.	Considérations relatives à l'IANA

Cette Section donne une définition formelle de l'extension STREAMING comme exigé par le paragraphe 3.3.3 de la [RFC3977] pour le registre de l'IANA.

L'extension STREAMING assure le transfert en flux direct des articles.
L'étiquette de capacité pour cette extension est "STREAMING".
L'étiquette de capacité n'a pas d'arguments.
L'extension définit trois nouvelles commandes, MODE STREAM, CHECK, et TAKETHIS, dont le comportement, les arguments, et les réponses sont définis respectivement aux paragraphes 2.3, 2.4, et 2.5.
L'extension n'associe aucune nouvelle réponse à des commandes NNTP pré existantes.
L'extension n'affecte pas le comportement d'un serveur ou client autre que via les nouvelles commandes.
L'extension n'affecte pas la longueur maximum lignes de commandes ou de réponse initiale.
L'extension n'altère pas le traitement en parallèle, et les commandes MODE STREAM, CHECK, et TAKETHIS peuvent être traitées en parallèle.
L'utilisation de cette extension néaltère pas la liste des capacités.
L'extension ne cause pas la production par une commande pré-existante de réponse 401, 480, ou 483.
L'utilisation de la commande MODE READER sur un serveur enmode commutation peut désactiver cette extension.
Spécification publiée : le présent document.
Contact pour des informations complémentaires : les auteurs du document.
Contrôleur des changements : IESG <iesg@ietf.org>.

 	7.	Remerciement

Le présent document s'appuie largement sur les paragraphes pertinents de la [RFC2980], par Stan Barber.

Des remerciements particuliers sont dus à Russ Allbery, Clive Feather, Andrew Gierth, et les autres qui ont commenté en privé les révisions intermédiaires de ce document, ainsi que les membres du groupe de travail NNTP de l'IETF pour leur implication continuelle (bien que sporadique) dans la discussion.

 	8.	Références
 	8.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 RFC    6048

[RFC4234]	D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", octobre 2005. (Remplace RFC2234, remplacée par RFC5234)

 	8.2	Référence pour information

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

 	Adresse des auteurs
Jeffrey M. Vinocur	Kenneth Murchison	
Department of Computer Science	Carnegie Mellon University	
Upson Hall	5000 Forbes Avenue	
Cornell University	Cyert Hall 285	
Ithaca, NY  14853	Pittsburgh, PA  15213 USA	
mél : vinocur@cs.cornell.edu 	mél : murch@andrew.cmu.edu 	

 	Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2006)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY, le IETF TRUST et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement
Le financement de la fonction d'édition des RFC est fourni par l'activité de soutien administratif de l'IETF (IASA).