Groupe de travail Réseau	K. Toyoda, PCC	
Request for Comments : 4141	D. Crocker, Brandenburg	
Catégorie : En cours de normalisation	novembre 2005	
	Traduction Claude Brière de L'Isle	

Extensions à SMTP et MIME pour la conversion de contenu

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

Notice de copyright
Copyright (C) The Internet Society (2005).

Résumé
Un générateur de message envoie parfois du contenu sous une forme que le receveur ne peut pas traiter, ou préfèrerait ne pas traiter une forme de qualité inférieure à celle qu'il préfère. Un tel contenu a besoin d'être converti en une forme acceptable, avec les mêmes informations ou informations contraintes (par exemple, en changeant de la couleur au noir et blanc). Dans un environnement à livraison différée, il peut être convenable que cette conversion soit effectuée par un intermédiaire. La présente spécification intègre deux extensions ESMTP et trois champs d'en-tête de contenu MIME, qui définissent un service coopératif qui permet une conversion de forme de contenu autorisée et responsable par les intermédiaires.
Table des Matières
1. Introduction	2
1.1 Fondements	2
1.2 Vue d'ensemble	2
1.3 Conventions de notation	3
2. Applicabilité	3
3. Spécification du service	3
3.1 Envoi de permission	5
3.2 Retour de capacités	6
3.3 Non prise en charge du service par le prochain bond	7
4. Extension SMTP Permission de conversion de contenu	7
4.1 Définition de l'extension de service Permission de conversion de contenu	7
4.2 Paramètre CONPERM à MAIL-FROM	7
4.3 Syntaxe	7
5. Extension SMTP de négociation de contenu	7
5.1 Définition de l'extension de service de négociation de contenu	7
5.2 Paramètre CONNEG à RCPT-TO	8
5.3 Syntaxe	8
6. Champ d'en-tête MIME Content-Features	8
7. Champ d'en-tête MIME Content-Convert	8
8. Champ d'en-tête MIME Content-Previous	9
9. Exemples	9
9.1 Négociation de CONPERM	9
9.2 Exemple de négociation de CONNEG	10
9.3 Content-Previous	11
10. Considérations pour la sécurité	11
11 Remerciements	12
12. Références	12
12.1 Références normatives	12
12.2 Référence pour information	12
Appendice A. CONNEG avec SMTP Direct	12
Appendice B. Utilisation de combinaisons d'extensions	13
B.1 Spécifier les contrainte de conversion suggérées	13
B.2 Spécifier les contraintes de conversion requises	14
B.3 Accepter toutes les formes de contenu	14
B.4 Quand exiger la conversion	14
Appendice C. Enregistrement de champ d'en-tête MIME	14
C.1 Content-Convert	14
C.2 Content-Previous	14
C.3 Content-Features	14
Adresse des auteurs	14
Déclaration complète de droits de reproduction	15

1.	Introduction

Les spécifications Internet définissent normalement les capacités communes d'un service particulier qui sont prises en charge par tous les participants. Cela permet l'envoi des données de base sans savoir quelles capacités supplémentaires sont prises en charge par des receveurs individuels. Cependant, connaître ces capacités permet l'envoi de types de données supplémentaires et de données d'une richesse améliorée. Autrement, un générateur de message va envoyer un contenu sous une forme que le receveur ne peut pas traiter, ou il va envoyer plusieurs formes de données. La présente spécification étend le travail de la [RFC3297], qui permet à un receveur de solliciter d'autre formes de contenu de la part du générateur. La spécification actuelle permet la conversion de contenu MIME par des intermédiaires, au nom du générateur du message et du receveur de message.

1.1	Fondements
MIME permet de distinguer et étiqueter les différents types de contenu [RFC2822], [MEDTYP]. Cependant, un générateur de messagerie électronique ne peut pas savoir si un receveur est capable de prendre en charge (interpréter) un type de données particulier. Pour permettre l'utilisation de base de MIME, un ensemble minimum de types de données est spécifié comme support de base. Comment un générateur sait-il si un receveur peut prendre en charge d'autres types de données ?
Un mécanisme pour décrire les types MIME est spécifié dans la [RFC2912]. La [RFC3297] spécifie un mécanisme qui permet au générateur d'interroger un receveur sur les types qu'il prend en charge en utilisant des messages électroniques dans l'échange de contrôle. Cela permet à un receveur de propager des informations sur ses capacités à un générateur. Pour l'échange de contrôle, l'utilisation de messages électroniques de bout en bout introduit une latence considérable et un certain manque de fiabilité.
Une autre approche est qu'un générateur utilise la "meilleure" forme de données qu'il peut, et inclue les mêmes types d'informations de représentation permises utilisées dans la [RFC3297]. Heureusement, le receveur, ou un intermédiaire, peut traduire cela en une forme prise en charge par un receveur limité. La présente spécification définit un tel mécanisme.  Elle définit un moyen de confronter la forme de contenu de message aux capacités d'un appareil ou système receveur, en utilisant des descripteurs de contenu MIME et l'utilisation facultative d'un mécanisme de négociation fondé sur SMTP [RFC1869], [RFC2821].

1.2	Vue d'ensemble
Un générateur décrit les formes de contenu désirables dans des descripteurs de contenu MIME. Il peut donner la "permission", à tout intermédiaire ou au receveur, de convertir le contenu en une de ces formes. Séparément, un serveur SMTP peut rapporter les capacités de contenu de la cible au client SMTP. Le client est alors capable de convertir le contenu du message en une forme qui soit à la fois prise en charge par le système cible et acceptable au générateur.
Un service de conversion doit faire un compromis entre les directives fournies par le générateur, les directives fournies au nom du receveur, et les capacités de l'intermédiaire qui effectue les conversions. Ceci est compliqué par le besoin de déterminer si les directives sont facultatives ou si elles sont destinées à être des exigences. Les conversions spécifiées comme facultatives sont effectués si possible, mais elles n'altèrent pas la livraison du message. À l'opposé, les spécifications de conversion qui sont traitées comme une exigence vont interdire la livraison si le receveur n'est pas capable de traiter le contenu. Ces possibilités interagissent pour former différents scénarios de traitement, dans le cas où l'intermédiaire ne peut pas satisfaire les désirs du générateur et du receveur:

Tableau 1 : Traitement d'échec

Générateur
\Receveur	Facultatif	Exigé	
Facultatif	Livre le contenu d'origine	Livre le contenu d'origine	
Exigé	Retourne sans livraison	Retourne sans livraison	

Ce tableau reflète une politique qui détermine le traitement d'échec sur la seule base des directives fournies par le générateur. Donc, les informations au nom du receveur sont utilisées pour guider les détails de conversion, mais pas la livraison du message.

Ceci est destiné à continuer les pratiques existantes de la messagerie électronique de livrer le contenu qu'un receveur pourrait n'être pas capable de traiter. Clairement, le tableau ci-dessus pourrait être modifié pour refléter une politique différente. Cependant, cela limiterait la rétro compatibilité subie par les usagers.

La présente spécification fournit des mécanismes pour prendre en charge un service contrôlé de conversion de contenu de messagerie au moment du transit, à travers une série de mécanismes. Ils incluent :
*	un service facultatif ESMTP bond par bond qui utilise les extensions de service CONPERM SMTP, produit par le générateur,
*	un service facultatif ESMTP bond par bond qui utilise les extensions de service CONNEG SMTP, produit au nom du receveur, et
*	trois champs d'en-tête de contenu MIME (Content-Convert, Content-Previous et Content-Features) qui spécifient les champs d'en-tête de contenu appropriés et enregistrent les conversions qui ont été effectuées.

Figure 1 : Exemple d'environnement de relais

+------------+                      +-----------+
| Générateur |                      | Receveur  |
+------------+                      +-----------+
     ||Envoi                      Livraison/\
     \/                                    ||
 +--------+    +-----------------+    +--------+
 | Client |    |   Relais SMTP   |    | Serveur|
 |  SMTP  |--->| Serveur| Client |--->|  SMTP  |
 +--------+    +--------+--------+    +--------+

1.3	Conventions de notation
Dans les exemples, "C:" et "S:" indiquent les lignes envoyées respectivement par le client et le serveur.

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

2.	Applicabilité

La présente spécification définit un mécanisme coopératif qui facilite la transformation précoce du contenu. Le mécanisme peut être utilisé pour économiser la bande passante et pour permettre le rendu sur des appareils receveurs qui ont des capacités limitées. Dans le premier cas, l'hypothèse est que la conversion va produire un plus petit contenu. Dans le second cas, l'hypothèse est que l'appareil receveur peut rendre le contenu sous une forme dérivée de l'originale, mais ne peut rendre celle-ci.

Le mécanisme peut imposer des exigences de ressources significatives aux intermédiaires qui effectuent les conversions. De plus, l'intermédiaire accepte la responsabilité de la conversion avant de savoir si il peut effectuer la conversion. Noter aussi que la conversion n'est pas possible pour les contenus qui ont été signés numériquement ou chiffrés, sauf si l'intermédiaire convertisseur peut décoder et recoder le contenu.

3.	Spécification du service

Ce service intègre deux extensions ESMTP et trois champs d'en-tête de contenu MIIME, afin de permettre une conversion de forme de contenu, autorisée et responsable, par les intermédiaires. Les intermédiaires sont des hôtes ESMTP (clients et serveurs) le long du chemin de transmission entre un générateur et un receveur.

Un générateur spécifie les types de contenu préférés dans le champ d'en-tête de contenu MIME Content-Convert. Les champs d'en-tête de contenu surviennent dans chaque partie de corps MIME à laquelle ils s'appliquent. C'est-à-dire que chaque partie de corps MIME contient son propre enregistrement de directives et d'historique de conversion.

Les préférences du générateur sont élevées au niveau de l'exigence par l'extension de service ESMTP CONPERM. Le mécanisme CONPERM n'est nécessaire que lorsque un générateur exige que soient appliquées des limitations de conversion par le service de transfert de messagerie. Si un type de contenu acceptable ne peut pas être livré, aucune livraison n'a alors lieu. Les capacités du système cible sont communiquées dans les sessions SMTP par l'extension de service ESMTP CONNEG. Ces informations sont utilisées pour restreindre la gamme de conversions qui peuvent être effectuées, mais n'affectent par la livraison.

Lorsque CONPERM est utilisé, les conversions sont effectuées par le premier hôte ESMTP qui peut obtenir à la fois la permission du générateur et les informations sur les capacités prises en charge par le receveur. Si un relais ou client est incapable de transmettre le message à un prochain bond qui prend en charge CONPERM ou d'effectuer la conversion appropriée, il termine alors la transmission du message et retourne une notification d'état de livraison (DSN, Delivery Status Notification) [RFC3461], [RFC3464], [RFC3463] au générateur, avec le code d'état 5.6.3 (Conversion requise mais non prise en charge).

Lorsque un relais ou serveur SMTP effectue une conversion de contenu, il enregistre quelles conversions spécifiques sont faites dans les champs d'en-tête MIME Content-Previous et Content-Features associés à chaque partie de corps MIME convertie.

Si un message est protégé par de fortes techniques d'authentification ou de confidentialité du contenu, un intermédiaire qui convertit un contenu de message DOIT alors s'assurer que le résultat de son traitement est protégé de façon similaire. Autrement, il NE DOIT PAS effectuer la conversion.

Action du générateur : Un générateur spécifie le résultat de la conversion désirée par le champ d'en-tête MIME Content-Convert. Si le générateur inclut un champ d'en-tête Content-Convert, il doit alors aussi inclure un champ d'en-tête Content-Feature, pour indique la forme actuelle du contenu. Les intermédiaires PEUVENT interpréter la présence de ce champ d'en-tête comme l'autorisation d'effectuer des conversions. Lorsque les champs d'en-tête Content-Convert sont le seul moyen de guider les conversions par les intermédiaires, ils ne servent alors que de conseil. L'échec à satisfaire les directives de ces champs d'en-tête n'affecte pas la livraison finale. Lors de l'envoi d'un nouveau message, le générateur PEUT spécifier l'application au service de transit de limitations de conversion en utilisant l'extension de service ESMTP CONPERM. Dans chaque partie de corps MIME pour laquelle la conversion est autorisée, les conversions DOIVENT être limitées à celles spécifiées dans les champs d'en-tête MIME Content-Convert. Si une conversion est nécessaire, mais si une conversion autorisée ne peut pas être effectuée, alors le message sera retourné au générateur. Si CONPERM n'est pas utilisé, alors l'échec à effectuer une conversion autorisée n'affectera pas le traitement normal de livraison.

Figure 2 : Usage de CONPERM

               +------------+
               | Générateur |
               +------------+
                SMTP  ||
                 ou   || CONPERM
               SUBMIT \/
                  +--------+            +----------------+
                  | Client |   SMTP     |  Relais SMTP   |
                  |  SMTP  |----------->| Serveur|       |
                  +--------+  CONPERM   +--------+-------+

Action du receveur : avec le service de transfert de messagerie ESMTP, les capacités qui peuvent être prises en charge au nom du receveur DEVRAIENT être communiquées aux intermédiaires par l'extension de service ESMTP CONNEG.

Figure 3 : Usage de CONNEG

                                        +-----------+
                                        | Receveur  |
                                        +-----------+
                                     Capacités||
                                              \/
               +----------------+         +--------+
               |  Relais SMTP   |  CONNEG |Serveur |
               |       | Client |<--------|  SMTP  |
               +-------+--------+         +--------+

Actions intermédiaires : un intermédiaire PEUT recevoir des directives CONPERM lorsque il reçoit un message, et PEUT recevoir une directive CONNEG avant d'envoyer le message. CONPERM et CONNEG opèrent message par message et sont produits par la demande ESMTP MAIL-FROM. Les informations de réponse CONNEG sont fournies sur la base du receveur, par la réponse au RCPT-TO ESMTP. La conversion DOIT être effectuée par le premier intermédiaire CONPERM qui obtient les informations de capacité CONNEG. Le type de contenu MIME DOIT se conformer au résultat du contenu converti, conformément à [MEDTYP]. Lorsque un intermédiaire obtient des informations de capacité différentes pour différents receveurs du même message, il PEUT soit :
*	créer une seule copie convertie du contenu qui peut être pris en charge par tous les receveurs, soit
*	créer plusieurs copies converties, correspondant aux capacités de sous ensembles des receveurs. Chaque version est alors envoyée séparément au sous ensemble approprié de receveurs, en utilisant des sessions standard SMTP séparées, avec des listes d'adresses standard Rcpt-To de la RFC2821 séparées.

Un enregistrement des conversions est placé dans les champs d'en-tête MIME Content-Previous. La forme actuelle du contenu est décrite dans les champs d'en-tête MIME Content-Features.

Un cas particulier de capacités différentielles se produit lorsque un intermédiaire reçoit des informations de capacité sur certains receveurs, mais pas d'information sur d'autres. Un exemple de ce scénario peut se produire lors de l'envoi d'un message à certains receveurs au sein de sa propre organisation, avec des receveurs situés ailleurs. L'intermédiaire peut avoir des informations de capacité sur les receveurs locaux, mais n'en aura aucune pour les receveurs distants. Ceci est traité comme une variante du traitement c'est-à-dire exigé pour les situations dans lesquelles les conversions permissibles sont l'ensemble nul -- c'est-à-dire, aucune conversion valide n'est possible pour un receveur.

Plutôt que faire simplement échouer la transmission aux receveurs pour lesquels il n'y a pas d'informations de capacité, l'intermédiaire PEUT choisir de partager la liste des adresses en sous ensembles séparés de listes standard Rcpt-To de la RFC2821 et des sessions standard SMTP séparées, et continuer la transmission du contenu original à ces receveurs via l'utilisation continuée du mécanisme CONPERM. Donc, le traitement pour de tels receveurs est effectué comme si aucune transaction CONNEG n'avait eu lieu.

Une fois qu'un intermédiaire a effectué la conversion, il PEUT terminer l'utilisation de CONPERM. Cependant, certains environnements de relais, comme ceux qui redirigent la messagerie sur un nouvel appareil cible, vont bénéficier de plus de conversions. Les intermédiaires PEUVENT continuer d'utiliser CONPERM ou PEUVENT réinitier l'utilisation de CONPERM lorsque ils ont connaissance de possibles variations dans un appareil cible.

Note : une nouvelle version transformée du contenu peut avoir moins d'informations que la version antérieure. Bien sûr, une séquence de transformations peut perdre des informations supplémentaires à chaque étape. Il peut étonnamment en résulter plus de pertes que nécessaire. Par exemple, la transformation x pourrait changer la forme A de contenu en forme B de contenu ; puis la transformation y change B en C. Cependant, il est possible que la transformation y aurait accepté directement la forme A et produit la forme D, qui a plus des informations d'origine que C.

Note : un générateur PEUT valider toutes les conversions faite en demandant  une DSN positive [RFC3461]. Si la demande de DSN inclut le paramètre "RET", l'agent de livraison DEVRAIT retourner une copie exacte du contenu de message livré (converti). Cela va permettre au générateur d'inspecter le résultat de toute conversion.

3.1	Envoi de permission
Un générateur de message qui permet la conversion de contenu aux intermédiaires PEUT utiliser l'extension de service CONPERM ESMTP et les champs d'en-tête MIME Content-Convert pour indiquer quelles conversions sont permises aux intermédiaires. Les autres mécanismes, par lesquels un générateur de message communique cette permission au service de transfert de messages SMTP sortent du domaine d'application de la présente spécification.

Note : Cette option exige qu'un serveur prenne un engagement illimité d'assurer que des conversions acceptables sont effectuées. En particulier, il est possible qu'il soit demandé à un intermédiaire d'effectuer la conversion, mais qu'il soit incapable de le faire. Le résultat sera que l'intermédiaire a qui il a été demandé de faire la conversion va effectuer un message non livré.

Lorsque un client ESMTP est autorisé à participer au service CONPERM, il DOIT interagir avec le serveur SMTP de prochain bond sur :
*	la capacité du serveur d'appliquer les conversions autorisées avec ESMTP CONPERM,
*	les capacités de prise en charge par l'appareil ou système cible, avec ESMTP CONNEG.

La réussite de l'utilisation de CONPERM n'exige pas que la conversion ait lieu le long du chemin de transfert du message. Elle exige plutôt que la conversion ait lieu quand un serveur de prochain bond rapporte des capacités qui peuvent être prises en charge au nom du receveur (avec CONNEG) et que ces capacités n'incluent pas la prise en charge de la représentation actuelle du contenu.

Note : Il est acceptable que chaque serveur SMTP – y compris le serveur du dernier bond – prenne en charge CONPERM, et qu'aucun n'offre CONNEG. Dans ce cas, le message est livré au receveur sous sa forme originale. Toutes les conversions qu'il est possible d'effectuer sont laissées au receveur. Donc, le receveur reçoit la forme originale du contenu, avec une liste explicite des conversions réputées acceptables par le générateur.

Un serveur SMTP PEUT offrir ESMTP CONPERM, sans être capable d'effectuer les conversions, si il sait que les conversions peuvent être effectuées le long du reste du chemin de transfert, ou par l'appareil ou système cible.

3.2	Retour de capacités
Un appareil ou système receveur cible présente des annonces de ses capacités de forme de contenu au service SMTP par des moyens qui sortent du domaine d'application de cette spécification. Noter que permettre à un serveur de produire des informations CONNEG au nom du receveur peut exiger un mécanisme substantiel entre receveur et serveur. Lorsque un serveur ESMTP connaît les capacités d'une cible, il PEUT offrir l'extension de service CONNEG ESMTP.

Note : Un aspect de ce mécanisme, entre le receveur et un serveur ESMTP offrant l'extension de service CONNEG ESMTP pourrait inclure d'offrir des capacités au delà de celles directement prises en charge par le receveur. En particulier, le serveur – ou d'autres intermédiaires entre le serveur et le receveur – pourrait prendre en charge des capacités qu'il peut convertir en capacité d'un receveur. Pour autant que le résultat soit acceptable pour l'ensemble spécifié dans les champs d'en-tête Content-Convert pertinents du message à convertir, les détails de ces conversions font partie du mécanisme receveur/serveur, et sortent du domaine d'application de la présente spécification.

Si un serveur ESMTP de prochain bond répond qu'il prend en charge CONNEG quand un message est traité conformément au mécanisme CONPERM, alors le client SMTP :
1)	DOIT demander les information CONNEG,
2)	DOIT effectuer les conversions requises, si possible, avant d'envoyer le message au serveur SMTP de prochain bond,
3)	DOIT faire échouer le traitement du message, si une conversion du message échoue, et DOIT retourner une DSN d'échec au générateur avec le code d'état 5.6.5  (Échec de conversion).

Lorsque il effectue les conversions, comme spécifié dans les champs d'en-tête MIME Content-Convert, le client DOIT:
1)	Ajouter un champ d'en-tête Content-Previous et un champ d'en-tête Content-Features à chaque corps MIME qui a été converti, et retirer tous les champs d'en-tête Content-Features existants.
2)	Soit :
*	Envoyer une seule copie au serveur SMTP de prochain bond, en utilisant les meilleures capacités prises en charge par tous les receveurs le long de ce chemin,
*	Séparer les transferts en plusieurs sessions, standard RFC2821.Rcpt-To et ESMTP, afin de fournir les meilleures conversions possibles pour les sous ensembles de receveurs.

Si les transferts sont séparés, la session en cours DOIT être terminée, et de nouvelles sessions créées pour chaque sous ensemble.

Les conversions à effectuer sont déterminées par l'intersection de trois listes :
*	les conversions permises par le générateur,
*	les capacités de contenu de la cible,
*	les conversions qui peuvent être effectuées par l'hôte client SMTP.

Échec de conversion
Si le résultat de cette intersection est l'ensemble nul de représentations, pour un destinataire, alors la livraison à cette adresse DOIT être traitée comme un échec de conversion.

Si le traitement est sujet au mécanisme CONPERM et :
*	si l'hôte SMTP de prochain bond n'indique pas qu'il peut représenter les capacités de la cible par CONNEG, mais
*	si il répond qu'il peut prendre en charge CONPERM, alors le client SMTP DOIT envoyer le contenu existant, si toutes les autres exigences de transmission SMTP sont satisfaites.

Si le traitement n'est pas sujet au mécanisme CONPERM, les échecs de conversion n'affectent alors pas la livraison de message.

3.3	Non prise en charge du service par le prochain bond
Si un client participe au mécanisme CONPERM, mais si le serveur SMTP de prochain bond ne prend pas en charge CONPERM ou CONNEG, alors le client SMTP :
1)	DOIT terminer la session avec le serveur SMTP de prochain bond, sans envoyer le message ;
2)	DOIT retourner une DSN au générateur, avec le code d'état 5.6.3 (Conversion requise mais non prise en charge)  [RFC3461], [RFC3464], [RFC3463].

Si un client participe au mécanisme CONPERM et si le serveur SMTP de prochain bond prend en charge CONNEG, mais ne fournit pas de capacités pour une destination individuelle RCPT-TO, le traitement du client SMTP pour ce receveur DOIT être :
1)	soit de traiter la destination comme un échec de conversion,
2)	soit de séparer la destination de la liste d'adresses qui sont traitées conformément à CONNEG, et de continuer à traiter la destination conformément à CONPERM.

4.	Extension SMTP Permission de conversion de contenu
4.1	Définition de l'extension de service Permission de conversion de contenu
1)	Le nom de l'extension de service SMTP est "Permission de conversion de contenu".
2)	La valeur du mot-clé EHLO associée à cette extension est "CONPERM".
3)	Un paramètre utilisant le mot-clé "CONPERM" est ajouté à la commande MAIL-FROM.
4)	Le serveur répond par une acceptation ou un rejet de la prise en charge de CONPERM pour ce message.

4.2	Paramètre CONPERM à MAIL-FROM
Paramètre : CONPERM

Argument : Il n'y a pas d'argument. La spécification des conversions permises est située dans un champ d'en-tête Content-Convert pour chaque partie de corps MIME dans lequel la conversion est permise.

Action du client : Si le serveur a produit un 250-CONPERM au titre de sa réponse EHLO pour la session en cours, et si le client participe au service CONPERM pour ce message – comme en ayant reçu le message avec une exigence CONPERM -- le client DOIT alors produire le paramètre CONPERM dans le MAIL-FROM. Si le serveur ne produit pas de 250-CONPERM, et si le client participe au service CONPERM pour ce message, le client DOIT alors traiter la transmission comme un rejet permanent.

Action du serveur : Si le client spécifie CONPERM dans le MAIL-FROM, mais si le serveur ne prend pas en charge le paramètre CONPERM, le serveur DOIT rejeter la commande MAIL-FROM avec une réponse 504-CONPERM. Si le client produit le paramètre CONPERM dans le MAIL-FROM, le serveur DOIT alors se conformer à cette spécification. Soit il DOIT relayer le message conformément au CONPERM, soit il DOIT convertir le message conformément aux informations de CONNEG.

4.3	Syntaxe
Content-Conversion-Permission =  "CONPERM"

5.	Extension SMTP de négociation de contenu
5.1	Définition de l'extension de service de négociation de contenu
1)	Le nom de l'extension de service SMTP est "Content-Negotiation".
2)	La valeur du mot-clé EHLO associée à cette extension est "CONNEG".
3)	Un paramètre, utilisant le mot-clé "CONNEG", est ajouté à la commande RCPT-TO.
4)	 Le serveur répond avec un rapport indiquant les capacités de contenu qui peuvent être reçues au nom de l'appareil ou système receveur, associées à l'adresse RCPT-TO cible.

5.2	Paramètre CONNEG à RCPT-TO
Paramètre : CONNEG

Argument : il n'y a pas d'arguments.

Action du client : si un message est soumis aux exigences de CONPERM et si le serveur produit un 250-CONNEG, au titre de sa réponse de EHLO pour la session en cours, le client DOIT produire le paramètre CONNEG dans la demande RCPT-TO. Si le message n'est pas soumis aux exigences de CONPERM, et si le serveur produit un 250-CONNEG, le client PEUT produire le paramètre CONNEG avec RCPT-TO. Si le client produit le paramètre CONNEG avec RCPT-TO, il DOIT alors honorer les capacités retournées dan les réponses CONNEG RCPT-TO pour ce message. De plus, il DOIT convertir le contenu du message, si la forme actuelle du contenu n'est pas incluse dans les capacités énumérées, au nom du receveur. Les conversions à effectuer sont déterminées par l'intersection :
*	des conversions permises par le générateur,
*	des capacités de contenu de la cible,
*	des conversions qui peuvent être effectuées par l'hôte client SMTP.
Si le résultat de cette intersection est l'ensemble de représentations nul, le traitement du client dépend alors de si le serveur de prochain bond a offert CONPERM, ainsi que CONNEG : 
1)	si le message sera soumis au CONPERM au prochain bond, le client PEUT transmettre le contenu original au prochain bond et continuer les exigences CONPERM ;
2)	autrement, le client DOIT traiter la conversion comme un échec ;
si le résultat de l'intersection n'est pas nul, le client DEVRAIT convertir les données au "plus haut" niveau de capacité du serveur. La détermination du niveau qui est le plus élevé est laissée à la discrétion de l'hôte qui effectue la conversion.
Chaque partie de corps MIME convertie DOIT avoir un champ d'en-tête Content-Previous qui indique la forme de la précédente partie de corps et un champ d'en-tête Content-Features, indiquant la forme de la nouvelle partie de corps.

Action du serveur : si le client spécifie CONNEG dans le RCPT-TO, mais si le serveur ne prend pas en charge le paramètre CONNEG, le serveur DOIT rejeter la destination RCPT-TO avec une réponse 504. Si le serveur prend en charge le paramètre CONNEG, et si il connaît les capacités de l'appareil ou système cible, il DOIT alors fournir ces informations par CONNEG. Le serveur PEUT fournir une liste plus large que celle prise en charge par le receveur si le serveur peut assurer que la forme de contenu livrée peut être traitée par le receveur, tout en satisfaisant quand même les contraintes de la ou des spécifications du Content-Convert de l'auteur. La réponse à une demande CONNEG RCPT-TO sera une réponse RCPT-TO multi lignes. Pour les réponses de succès (250) au moins la première ligne de la réponse doit contenir des informations RCPT-TO autres que CONNEG. Les lignes de réponse supplémentaires sont pour CONNEG. Pour éviter des problèmes dus aux variations des tailles de ligne de mémoire tampon, la liste totale des paramètres doit être fournie comme une série de lignes, chacune commençant par "250-CONNEG", excepté la dernière ligne, qui est "250 CONNEG". Le contenu de la liste des capacités DOIT se conformer aux spécifications de la [RFC2533] et couvrir la même gamme de spécifications permises dans la [RFC3297].

5.3	Syntaxe
Content-Negotiation =  "CONNEG"
Capability =  { spécification de <filter>, conformément à la [RFC2533] }

6.	Champ d'en-tête MIME Content-Features

Le champ d'en-tête Content-Features décrit les caractéristiques de la version courante du contenu pour la partie de corps MIME dans laquelle se produit le champ d'en-tête. Il y a un champ d'en-tête Content-Features séparé pour chaque partie de corps MIME. La spécification de ce champ d'en-tête est contenue dans la [RFC2912].

7.	Champ d'en-tête MIME Content-Convert

Content-Convert est un champ d'en-tête qui spécifie les conversions préférées pour le contenu associé. Il PEUT être utilisé sans les autres mécanismes définis dans le présent document. Si il est présent, ce champ d'en-tête DOIT être porté non modifié et livré au receveur. En son absence, le générateur du contenu ne donne aucune directive sur les conversions de contenu, et les intermédiaires NE DEVRAIENT PAS effectuer de conversion de contenu.

Dans la notation ABNF étendue, le champ d'en-tête Content-Convert est défini comme suit :

Convert =  "Content-convert:" [RFC3282] permitted

Permitted =  "ANY" / "NONE" / permitted-list

permitted-list =  { liste explicite des formes finales permises, utilisant la syntaxe <filter> de la [RFC2533] }

Si les conversions permises sont spécifiées comme "ANY", les intermédiaire peuvent alors effectuer toutes les conversions qu'ils estiment appropriées.

Si les conversions permises sont spécifiées comme "NONE", les intermédiaire NE DEVRAIENT alors PAS effectuer de conversion pour cette partie de corps MIME, même lorsque l'appareil ou système cible ne prend pas en charge la forme originale du contenu.

Si un champ d'en-tête Content-Convert est présent, un champ d'en-tête Content-Features DOIT alors aussi être présent pour décrire la forme actuelle du contenu.

8.	Champ d'en-tête MIME Content-Previous

Lorsque un intermédiaire a effectué la conversion du contenu associé, il DOIT enregistrer les détails de la précédente représentation, à partir de laquelle la conversion a été effectuée. Ces informations sont placées dans un champ d'en-tête  Content-Previous qui fait partie de la partie de corps MIME avec le contenu converti. Il y a un champ d'en-tête séparé pour chaque partie de corps MIME convertie.

Lorsque un intermédiaire a effectué une conversion, l'intermédiaire DOIT enregistrer les détails du résultat de la conversion en créant ou révisant le champ d'en-tête Content-Features pour la partie de corps MIME convertie.

Dans la notation de la [RFC4234] étendue, le champ d'en-tête Content-Previous est défini comme suit :

previous =  "Content-Previous:" date by type

date = "Date " [RFC3282] date-time [RFC3282] ";" [RFC3282]

by =  "By " [RFC3282] domain [RFC3282] ";" [RFC3282]

type = { caractéristiques de contenu, en utilisant la syntaxe <filter> de la [RFC2533] }

Le champ Date spécifie la date et l'heure à laquelle la représentation indiquée a été convertie en nouvelle représentation.

Le champ By spécifie le nom de domaine ode l'intermédiaire qui a effectué la conversion.

Un intermédiaire PEUT choisir de déduire le champ d'en-tête Content-Previous, pour une partie de corps, d'un champ d'en-tête Content-Features déjà existant dans cette partie de corps, avant que ce champ d'en-tête soit remplacé par la description de la représentation actuelle.

9.	Exemples
9.1	Négociation de CONPERM
   S: 220 example.com IFAX
   C: EHLO example.com
   S: 250- example.com
   S: 250-DSN
   S: 250 CONPERM
   C: MAIL FROM:May@some.example.com CONPERM
   S: 250 <May@some.example.com> générateur ok
   C: RCPT TO:<June@some.example.com>
   S: 250 <June@some.example.com> receveur ok
   C: DATA
   S: 354 okay, envoi des données
   C: <<message RFC 2822 avec type de contenu MIME : image/TIFF-FX
      Per:
      (  image-file-structure=TIFF-minimal
         dpi=400
         image-coding=JBIG
         size-x=2150/254
         paper-size=letter
      )
avec les parties de corps MIME incluant :
      Content-Convert:
         (&(image-file-structure=TIFF-minimal)
           (MRC-mode=0)
           (color=Binary)
           (|(&(dpi=204)
               (dpi-xyratio=[204/98,204/196]) )
             (&(dpi=200)
               (dpi-xyratio=[200/100,1]) )
             (&(dpi=400)
               (dpi-xyratio=1) ) )
           (|(image-coding=[MH,MR,MMR])
             (&(image-coding=JBIG)
               (image-coding-constraint=JBIG-T85)
               (JBIG-stripe-size=128) ) )
           (size-x<=2150/254)
           (paper-size=[letter,A4])
           (ua-media=stationery) )
      >>
   S: 250 message accepté
   C: QUIT
   S: 221 au revoir

9.2	Exemple de négociation de CONNEG
   S: 220 example.com IFAX
   C: EHLO example.com
   S: 250- example.com
   S: 250-DSN
   S: 250 CONNEG
   C: MAIL FROM:<May@some.example.com>
   S: 250 <May@some.example.com> générateur ok
   C: RCPT TO:<June@ifax1.jp> CONNEG
   S: 250-<June@some.example.com> receveur ok
   S: 250-CONNEG (&(image-file-structure=TIFF-minimal)
   S: 250-CONNEG   (MRC-mode=0)
   S: 250-CONNEG   (color=Binary)
   S: 250-CONNEG   (|(&(dpi=204)
   S: 250-CONNEG       (dpi-xyratio=[204/98,204/196]) )
   S: 250-CONNEG     (&(dpi=200)
   S: 250-CONNEG       (dpi-xyratio=[200/100,1]) ) )
   S: 250-CONNEG   (image-coding=[MH,MR,MMR])
   S: 250-CONNEG   (size-x<=2150/254)
   S: 250-CONNEG   (paper-size=[letter,A4])
   S: 250 CONNEG   (ua-media=stationery) )
   C: DATA
   S: 354 okay, envoi des données
   C: <<message RFC 2822 avec type de contenu MIME : image/TIFF-FX
        Per:
        (  image-file-structure=TIFF-minimal
           dpi=400
           image-coding=JBIG
           size-x=2150/254
           paper-size=letter
         )
      >>
   S: 250 message accepté
   C: QUIT
   S: 221 au revoir

9.3	Content-Previous
   Content-Previous:
      Date  Tue, 1 Jul 2001 10:52:37 +0200;
      By    relay.example.com;
      (&(image-file-structure=TIFF-minimal)
        (MRC-mode=0)
        (color=Binary)
        (&(dpi=400)
          (dpi-xyratio=1) )
        (&(image-coding=JBIG)
          (image-coding-constraint=JBIG-T85)
          (JBIG-stripe-size=128) )
        (size-x=2150/254)
        (paper-size=A4)
        (ua-media=stationery) )

10.	Considérations pour la sécurité

Ce service appelle à la divulgation des capacités, au nom des receveurs. Les mécanismes pour déterminer l'identité authentifiée de demandeur et de ceux qui répondent sortent du domaine d'application de la présente spécification. Ces mécanismes sont destinés à permettre la divulgation des informations qui sont sûres pour une distribution publique ; donc, il n'y a pas de besoin inhérent de mesures de sécurité.

Les informations qui devraient avoir une distribution restreinte peuvent toujours être divulguées. Donc, il est de la responsabilité du serveur ESMTP ou du client ESMTP qui divulgue de déterminer si des mesures de sécurité supplémentaires devraient être appliquées à l'utilisation de cette option ESMTP.

L'utilisation de l'option ESMTP CONNEG permet la transformation de contenu par un intermédiaire, le long du chemin de transfert de la messagerie. Lorsque les contenus sont chiffrés, l'intermédiaire ne peut pas effectuer la conversion, parce que il n'est pas supposé avoir accès au matériel de chiffrement secret pertinent. Lorsque le contenu est signé, mais non chiffré, la conversion va invalider la signature. La présente spécification permet un calcul potentiellement illimité par les MTA intermédiaires, selon la nature et la quantité de conversion requise. De plus, cette charge de calcul peut fournir une opportunité d'attaques de déni de service, étant donné que la messagerie Internet permet normalement aux intermédiaires de recevoir les messages provenant de toutes les sources Internet.

La présente spécification assure la conversion de contenu par des intermédiaires non spécifiés. L'utilisation de ce mécanisme comporte des risques significatifs. Bien que les intermédiaires aient toujours la capacité d'effectuer des transformations dommageables, l'utilisation de la présente spécification pourrait résulter en une exploration plus approfondie de ce potentiel et, donc, de plus de mauvais comportements. L'utilisation des intermédiaires est discutée dans la [RFC3238].

CONPERM/CONNEG fournit un mécanisme coopératif, plutôt que de permettre aux intermédiaire des actions qui n'étaient pas possibles antérieurement. Les intermédiaires peuvent déjà faire des conversions de leur propre initiative. Donc, le mécanisme n'introduit pas de problèmes de sécurité essentiels, autres que de divulguer les préférences du receveur.

11	Remerciements

Graham Klyne et Eric Burger ont fourni des corrections et suggestions abondantes. Keith Moore, Giat Hana, et Joel Halpern ont fourni des retours qui ont amélioré l'intégration de la spécification dans la pratique établie de messagerie.

12.	Références
12.1	Références normatives

[MEDTYP]	IANA, "MIME Media Types", < http://www.iana.org/assignments/media-types >

[RFC1869]	J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "Extensions de service à SMTP", novembre 1995. (Obsolète, voir RFC5321, STD0010)

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

[RFC2533]	G. Klyne, "Syntaxe de description des ensembles de caractéristiques des supports", mars 1999. (MàJ par RFC2738, RFC2938) (P.S.)

[RFC2821]	J. Klensin, éditeur, "Protocole simple de transfert de messagerie", STD 10, avril 2001. (Obsolète, voir RFC5321)

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

[RFC2912]	G. Klyne, "Indication des caractéristiques de support pour contenu MIME", septembre 2000. (P.S.)

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

[RFC3297]	G. Klyne, R. Iwazaki, D. Crocker, "Négociation de contenu pour les services de messagerie fondés sur la messagerie électronique", juillet 2002. (P.S.)

[RFC3461]	K. Moore, "Extension de service du protocole simple de transfert de messagerie (SMTP) pour les notifications d'état de livraison (DSN)", janvier 2003. (MàJ par RFC3798, 3885, 5337, 6533, 8098) (D.S.)

[RFC3463]	G. Vaudreuil, "Codes d'état améliorés du système de messagerie", janvier 2003. (MàJ par RFC3886, RFC4468, RFC4865, RFC4954, RFC5248) (D.S.)

[RFC3464]	K. Moore, G. Vaudreuil, "Format extensible de message pour les notifications d'état de livraison", janvier  2003. (MàJ par RFC4865, RFC5337, RFC6533) (D.S.)

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

12.2	Référence pour information

[RFC3238]	S. Floyd, L. Daigle, "Considérations architecturales et de politique de l'IAB pour des services marginaux à connexion libre (OPES)", janvier 2002. (Information)

Appendice A.	CONNEG avec SMTP Direct

Cet Appendice est descriptif. Il fait seulement un exposé sur les questions d'usage permis ou requis par le texte normatif.

Dans certaines configurations, il est possible d'avoir des interactions directes fondées sur la messagerie, où le système du générateur conduit une connexion TCP directe, interactive, avec le système du receveur. Cette configuration permet l'usage du service de négociation de forme de contenu qui se conforme à cette spécification, mais permet des simplifications. Cette seule session SMTP n'a pas la complexité de plusieurs sessions avec relais et n'a donc pas les exigences de propagation de permissions aux intermédiaires.

Le système du générateur fournit des fonctions de niveau utilisateur pour le générateur, et il contient le client SMTP pour envoyer les messages. Donc, l'étape formelle "d'envoi" des messages est un processus qui est interne ou virtuel, au sein du système générateur. Le service du receveur contient les fonctions de niveau utilisateur pour le receveur, et contient le serveur SMTP pour recevoir les messages. Donc, les étapes formelles de "livraison" et "réception" des messages sont internes ou virtuelles, au sein du système receveur.

Figure 4 : DIRECT CONNEG

        Système générateur          Système receveur
        +------------------+       +------------------+
        |  +------------+  |       |   +-----------+  |
        |  | Générateur |  |       |   | Receveur  |  |
        |  +------------+  |       |   +-----------+  |
        |       ||Envoi    |       |      /\Réception |
        |       \/         |       |      ||          |
        |   +---------+    |       |    +--------+    |
        |   | Client  |<---|-------|----| Serveur|    |
        |   |  SMTP   |----|-------|--->|  SMTP  |    |
        |   +---------+    |       |    +--------+    |
        +------------------+       +------------------+

Dans ce cas, CONPERM n'est pas nécessaire parce que le client SMTP fait partie du système générateur et a déjà la permission nécessaire. De même, le serveur SMTP sera certain de connaître les capacités du receveur, parce que le serveur fait partie du système receveur.

Donc, le mode direct de transmission de messagerie peut réaliser la confrontation de capacité et de forme de contenu en ayant :
*	des systèmes générateurs qui se conforment à la présente spécification et un processus de communication entre générateur et receveur qui est le même que celui qui aurait lieu entre un relais SMTP de dernier bond et le serveur SMTP de livraison auquel il est connecté ;
*	c'est-à-dire que le client et le serveur DOIVENT employer CONNEG et le client DOIT effectuer toutes les conversions requises.

Appendice B.	Utilisation de combinaisons d'extensions

La présente spécification définit un certain nombre de mécanismes. Il n'est pas exigé que tous soient utilisés ensemble. Par exemple, la différence entre la liste des conversions préférées – contre la spécification des limitations à appliquer aux conversions – est discutée dans l'Introduction. Cet Appendice décrit plus en détails des scénarios qui peuvent inviter à utiliser moins que l'ensemble complet défini dans cette spécification. Il résume aussi les conditions qui rendent obligatoire qu'un intermédiaire effectue la conversion.

Cet Appendice est descriptif. Il donne seulement un exposé des questions d'usage permis ou exigés par le texte normatif.

Les mécanismes disponibles sont :
1.	Le paramètre CONPERM à Mail-From.
2.	Le paramètre CONNEG à RCPT-TO.
3.	 Le champ d'en-tête MIME Content-Convert.
4.	 Le champ d'en-tête MIME Content-Previous.
5.	 Le champ d'en-tête MIME Content-Features.

B.1	Spécifier les contrainte de conversion suggérées
L'utilisation du champ d'en-tête MIME Content-Convert spécifie les préférences du générateur, si la conversion devait être effectuée. Cela n'impose aucune exigence sur la conversion ; elle est simplement facultative.

B.2	Spécifier les contraintes de conversion requises
Lorsque la spécification MIME Content-Convert est couplée avec l'option ESMTP CONPERM, la spécification du générateur des conversions préférées s'élève alors au niveau d'exigence. Aucune autre conversion n'est permise, sauf celles spécifiées dans le champ d'en-tête Content-Convert.

Noter que la présence des deux mécanismes n'exige pas que les conversions soient effectuées. Cela contraint plutôt les conversions, si elles devaient se produire.

B.3	Accepter toutes les formes de contenu
Bien qu'il soit peu probable qu'un appareil soit jamais capable de traiter tous les types de contenu existants, certains appareils peuvent être facilement mis à niveau (par exemple, en ajoutant des fonctionnalités). Donc, un tel appareil est capable de traiter effectivement tous les contenus.

Pour de tels appareils, il vaut mieux s'abstenir de produire une assertion CONNEG. La demande CONPERM devrait plutôt être propagée à l'appareil cible.

B.4	Quand exiger la conversion
Un nœud est obligé d'effectuer la conversion quand :
1.	au moins un champ d'en-tête MIME Content-Covert est présent dans le message,
2.	ESMTP CONPERM est en vigueur au nœud qui traite le message,
3.	ESMTP CONNEG est aussi en vigueur au même nœud,
4.	la forme actuelle du contenu n'est pas citée dans la liste CONNEG,
5.	au moins une forme de contenu est présente, à la fois dans la liste Content-Convert et la liste CONNEG, et
6.	l'intermédiaire est capable de convertir de la forme actuelle en une des formes citées dans Content-Convert et CONNEG.

Appendice C.	Enregistrement de champ d'en-tête MIME
C.1	Content-Convert
Nom de champ d'en-tête :  Content-Convert
Protocole applicable : Messagerie (RFC 2822)
Statut : Proposition de norme
Auteur/contrôleur des changements : IETF
Document(s) de spécification : RFC 4141.
Informations en rapport : aucune.

C.2	Content-Previous
Nom de champ d'en-tête :  Content-Previous
Protocole applicable : Messagerie (RFC 2822)
Statut : Proposition de norme
Auteur/contrôleur des changements : IETF
Document(s) de spécification : RFC 4141, Section 8
Informations en rapport : aucune.

C.3	Content-Features
Le présent mémoire amende substantiellement la spécification du champ d'en-tête MIME "Content-Features:" enregistré par la [RFC2912]. L'IANA devrait inclure dans la clause "Document de spécification" de cet enregistrement un pointeur sur la RFC 4141.

Adresse des auteurs

Dave Crocker	Kiyoshi Toyoda	
Brandenburg InternetWorking	Panasonic Communications Co., Ltd.	
675 Spruce Drive	4-1-62 Minoshima Hakata-ku, Fukuoka 812-8531 Japan	
Sunnyvale, CA  94086  USA	mél : toyoda.kiyoshi@jp.panasonic.com 	
téléphone : +1.408.246.8253		
mél : dcrocker@bbiw.net 		

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2005).

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

Le présent document et les informations y 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 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 ci-encloses ne violent 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 pourrait ê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 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 actuellement fourni par la Internet Society.