Groupe de travail Réseau

Extensions multi-objet de messagerie Internet (MIME) Partie quatre : Procédures d'enregistrement

Le présent document spécifie les bonnes pratiques actuelles de l'Internet pour la communauté de l'Internet, et appelle à des discussions et suggestions pour son amélioration. La distribution du présent mémoire n'est soumise à aucune restriction.

Le présent document spécifie les procédures d'enregistrement de l'IANA pour les types d'accès de corps externe et les codage de transfert de contenu MIME.

Table des Matières

1. Introduction

1.1 Conventions utilisées dans le document

2. Types d'accès de corps externes

2.1 Exigences d'enregistrement

2.2 Procédure d'enregistrement

2.3 Localisation de la liste des types d'accès enregistrés

2.4 Procédures de l'IANA pour enregistrer les types d'accès

3. Codages de transfert

3.1 Exigences de codage de transfert

3.2 Procédure de définition de codage de transfert

3.3 Procédures de l'IANA pour l'enregistrement de codage de transfert

3.4 Localisation de la liste de codages de transfert enregistrés

4. Considérations pour la sécurité

5. Considérations relatives à l'IANA

6. Remerciements

7. Références

7.1 Références normatives

7.2 Références pour information

Appendice A Changements par rapport à la RFC 2048

Adresse des auteurs

Déclaration complète de droits de reproduction

Les récents protocoles de l'Internet ont été conçus avec soin pour être facilement extensibles dans certains domaines. En particulier, MIME [RFC2045] est un cadre ouvert et peut s'accommoder de types d'objets, jeux de caractères, et méthodes d'accès, supplémentaires sans aucun changement du protocole de base. Un processus d'enregistrement est nécessaire, cependant, pour assurer que l'ensemble de ces valeurs est développé de façon ordonnée, bien spécifiée, et publique.

Le présent document définit les procédures d'enregistrement qui utilisent l'Autorité d'allocation des numéros de l'Internet (IANA) comme registre central pour ces valeurs.

Note : L'enregistrement des types de supports et des jeux de caractères à utiliser dans MIME est spécifié dans des documents séparés, les [RFC4288] et [RFC2978] et n'est pas traité ici.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC2119].

La [RFC2046] définit le type de support "message/external-body", par lequel une entité MIME peut agir comme pointeur sur les données de corps réelles au lieu d'inclure les données directement dans le corps de l'entité. Chaque référence de message/external-body spécifie un type d'accès, qui détermine le mécanisme utilisé pour restituer les données de corps réelles. La RFC 2046 définit un ensemble initial de types d'accès mais permet l'enregistrement de types d'accès supplémentaires pour s'accommoder de nouveaux mécanismes de restitution.

Les spécifications de types d'accès nouveaux DOIVENT se conformer aux exigences décrites ci-dessous.

Chaque type d'accès DOIT avoir un nom unique. Ce nom apparaît dans le paramètre access-type dans le champ d'en-tête de type de contenu "message/external-body" et DOIT se conformer à la syntaxe de paramètre MIME de type de contenu.

Tous les protocoles, transports, et procédures utilisés par un certain type d'accès DOIVENT être décrits, soit dans la spécification du type d'accès lui-même, soit dans une autre spécification publiquement disponible, en détail suffisant pour que le type d'accès soit mis en œuvre par tout utilisateur compétent. L'utilisation de méthodes secrètes et/ou propriétaires dans un type d'accès est expressément interdite. La restriction imposée par la [RFC2026] sur la normalisation des algorithmes brevetés doit être aussi respectée.

Tous les types d'accès DOIVENT être décrits par une RFC. La RFC peut être pour information plutôt que sur la voie de la normalisation, bien que la révision et l'approbation de la voie de la normalisation soient encouragées pour tous les types d'accès.

Toutes les questions de sécurité connues qui résultent de l'utilisation du type d'accès DOIVENT être entièrement et exactement décrites. Il n'est pas exigé que le type d'accès soit sûr ou qu'il soit exempt de risques, mais il est exigé que les risques connus soient identifiés. La publication d'un nouveau type d'accès n'exige pas une revue exhaustive de la sécurité, et la section des considérations sur la sécurité est sujette à évaluation continue. Des considérations de sécurité supplémentaires DEVRAIENT être traitées par la publication de versions révisées de la spécification de type d'accès.

L'enregistrement d'un nouveau type d'accès commence par la publication de la spécification comme projet Internet.

Une spécification de type d'accès proposé est envoyée à la liste de diffusion "ietf-types@iana.org" pour une période de deux semaines. Cette liste de diffusion a été établie pour les besoins de relecture des accès et types de support proposés. Les types d'accès proposés ne sont pas formellement enregistrés et ne doivent pas être utilisés.

L'intention de l'envoi au public est de solliciter des commentaires et des retours sur la spécification de type d'accès et une revue de toutes les considérations sur la sécurité.

Lorsque la période de deux semaines est achevée, le réviseur du type d'accès, qui est appointé par le ou les directeurs de zone d'application de l'IETF, transmet la demande à iana@iana.org ou la rejette parce que des objections significatives ont été soulevées sur la liste de diffusion.

Les décisions prises par le réviseur doivent être adressées à la liste de diffusion des "ietf-types" dans les 14 jours. Les décisions prises par le réviseur peuvent aller en appel devant l'IESG comme spécifié dans la [RFC2026].

Une fois que le type d'accès a passé la relecture ou a subi avec succès l'appel devant l'IESG, l'IANA va enregistrer le type d'accès et rendre l'enregistrement disponible à la communauté. La spécification de type d'accès doit aussi être publiée comme RFC.

L'identité du réviseur du type d'accès est communiquée à l'IANA par l'IESG. C'est alors seulement que l'IANA agit soit en réponse aux définitions de type d'accès qui sont approuvées par le réviseur du type d'accès et transmises pour enregistrement à l'IANA, soit en réponse à une communication de l'IESG disant qu'un appel de définition de type d'accès a renversé la décision du réviseur du type d'accès.

Les codages de transfert sont des transformations appliquées aux types de supports MIME après conversion à la forme canonique du type de support. Les codages de transfert sont utilisés à plusieurs fins :

o De nombreux transports, en particulier les transports de messages, peuvent seulement traiter des données consistant en lignes de texte relativement courtes. Il peut y avoir de sévères restrictions sur les caractères qui peuvent être utilisés dans ces lignes de texte. Certains transports se restreignent à un petit sous ensemble de l'US-ASCII, et d'autres ne peuvent pas traiter certaines séquences de caractères. Les codages de transfert sont utilisés pour transformer des données binaires en une forme textuelle qui puisse survivre à de tels transports. Des exemples de cette sorte de codage de transfert incluent le base64 et les codages de transfert "quoted-printable" définis dans la [RFC2045].

o Les images, l'audio, la vidéo, et même les entités d'application sont parfois assez grosses. Des algorithmes de compression sont souvent efficaces pour réduire la taille de grosses entités. Les codages de transfert peuvent être utilisés pour appliquer des algorithmes de compression d'objet général sans perte aux entités MIME.

o Les codages de transport peuvent être définis comme moyen de représenter des formats de codage existants dans un contexte MIME.

IMPORTANT : La normalisation d'un grand nombre de codages de transfert différents est vue comme une barrière significative à une large interopérabilité et est expressément déconseillée. Néanmoins, la procédure suivante a été définie afin de fournir le moyen de définir des codages de transfert supplémentaires, si la normalisation est en fait justifiée.

Les spécifications de codage de transfert DOIVENT se conformer aux exigences décrites ci-dessous.

Chaque codage de transfert DOIT avoir un nom unique. Ce nom apparaît dans le champ d'en-tête Content-Transfer-Encoding et DOIT se conformer à la syntaxe de ce champ.

Tous les algorithmes utilisés dans un codage de transfert (par exemple, conversion en forme imprimable, compression) DOIVENT être décrits en totalité dans la spécification de codage de transfert. L'utilisation d'algorithmes secrets et/ou propriétaires dans des codages de transfert normalisés est formellement interdite. Les restrictions imposées par la [RFC2026] sur la normalisation d'algorithmes brevetés DOIVENT aussi être respectées.

Tous les codages de transfert DOIVENT être applicables à une séquence de toute longueur d'octets arbitraire. La dépendance à des formes d'entrées particulières n'est pas permise.

On devrait noter que les codages 7bit et 8bit ne se conforment pas à cette exigence. Mis à part le caractère indésirable d'avoir des codages spécialisés, l'intention ici est d'interdire l'ajout de codages supplémentaires similaires ou redondants avec 7bit et 8bit.

Il n'y a pas d'exigence qu'un codage de transfert particulier produise une forme particulière de résultat codé . Cependant, le format du résultat pour chaque codage de transfert DOIT être documenté de façon complète. En particulier, chaque spécification DOIT déclarer clairement si le format de résultat se tient toujours dans les limites de 7bit ou 8bit ou est simplement de pures données binaires.

Tous les codages de transfert DOIVENT être pleinement réversibles sur toute plateforme ; il DOIT être possible à tous de récupérer les données d'origine en effectuant l'opération de décodage correspondante. Noter que cette exigence exclut effectivement l'utilisation de toutes les formes de compression à pertes ainsi que toutes les formes de chiffrement comme codage de transfert.

Tous les codages de transfert DOIVENT fournir certaines sortes de nouvelles fonctionnalités. Un certain degré de recouvrement de fonctionnalités avec des codages de transfert définis antérieurement est acceptable, mais tout nouveau codage de transfert DOIT aussi offrir quelque chose qu'aucun autre codage de transfert ne fournit.

Dans toute la mesure du possible, les codages de transfert NE DEVRAIENT PAS contenir de problème de sécurité connu. Néanmoins, tout problème de sécurité connu qui résulterait de l'utilisation du codage de transfert DOIT être complètement et pleinement décrit. Si des questions de sécurité supplémentaires se font jour après la publication et l'enregistrement initiaux, ils DEVRAIENT être traités par la publication de versions révisées de la spécification du codage de transfert.

La définition d'un nouveau codage de transfert commence par la publication de la spécification comme projet Internet. Le projet DOIT définir le codage de transfert précisément et complètement, et il DOIT aussi fournir une justification substantielle de la définition et la normalisation d'un nouveau codage de transfert. Cette spécification DOIT alors être présentée à l'IESG pour examen. L'IESG peut :

o rejeter directement la spécification comme étant inappropriée pour la normalisation,

o allouer la spécification à un groupe de travail existant de l'IETF pour approfondissement,

o approuver la formation d'un groupe de travail de l'IETF pour travailler sur la spécification conformément aux procédures de l'IETF, ou

o accepter la spécification telle quelle pour être traitée comme soumission individuelle sur la voie de la normalisation.

Les spécifications de codage de transfert sur la voie de la normalisation suivent les règles normales de l'IETF pour les documents sur la voie de la normalisation. Un codage de transfert est considéré comme défini et disponible pour l'utilisation une fois qu'il est sur la voie de la normalisation.

Il n'y a pas besoin de procédure particulière pour enregistrer les codages de transfert auprès de l'IANA. Tous les enregistrements légitimes de codage de transfert DOIVENT apparaître comme une RFC sur la voie de la normalisation, il est donc de la responsabilité de l'IESG de notifier à l'IANA quand un nouveau codage de transfert a été approuvé.

Les exigences de sécurité pour les types d'accès sont discutées au paragraphe 2.1.4. Les exigences de sécurité pour les codages de transfert sont discutées au paragraphe 3.1.7.

Le seul objet du présent document est de définir les registres de l'IANA pour les types d'accès et les codages de transfert. Les procédures de l'IANA pour ces registres sont spécifiées respectivement au paragraphe 2.4 et au paragraphe 3.3.

Les auteurs actuels tiennent à reconnaître leur dette à l'égard du regretté Dr. Jon Postel, dont le modèle général de procédures d'enregistrement de l'IANA et les contributions spécifiques ont donné forme aux prédécesseurs du présent document [RFC2048]. Nous espérons que la version actuelle aurait reçu son accord, mais comme il est impossible de le vérifier, nous avons eu le regret de devoir retirer son nom de la liste des co-auteurs.

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

[RFC2048] N. Freed, J. Klensin et J. Postel, "Extensions multi-objets de la messagerie Internet (MIME) Partie 4 : Procédures d'enregistrement", BCP 13, novembre 1996. (Rendue obsolète par les RFC 4288-4289)

[RFC2978] N. Freed et J. Postel, "Procédures d'enregistrement des jeux de caractère par l'IANA", BCP 19, octobre 2000.

o Les procédures d'enregistrement de type de support sont maintenant décrites dans un document séparé [RFC4288].

o Les divers URL et adresses dans ce document ont été changés pour se référer toutes à iana.org plutôt qu'à isi.edu. De plus, beaucoup d'URL ont été changés pour utiliser HTTP ; ils utilisaient anciennement FTP.

o Une grande partie du document a été précisée à la lumière de l'expérience du fonctionnement avec ces procédures.

o Plusieurs des références de ce document ont été mises à jour pour se référer à la version actuelle des spécifications.

o L'option d'allouer la tâche de travailler sur un nouveau codage de transfert à un groupe de travail existant a été ajoutée à la liste des actions possibles que peut effectuer l'IESG.

o Les sections de considérations sur la sécurité et des considérations relatives à l'IANA ont été ajoutées.

o L'enregistrement des jeux de caractères à utiliser dans MIME est spécifié dans la [RFC2978] et n'est plus traité par le présent document.

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 contenues sont fournis 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.

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

Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.

Groupe de travail Réseau	N. Freed, Sun Microsystems
Request for Comments : 4289	J. Klensin
BCP : 13	décembre 2005
RFC rendue obsolète : 2048
Catégorie : Bonnes pratiques actuelles	Traduction Claude Brière de L'Isle

Ned Freed	John C. Klensin
Sun Microsystems	1770 Massachusetts Ave, #322
3401 Centrelake Drive, Suite 410	Cambridge, MA 02140
Ontario, CA 92761-1205	USA
USA	mél : klensin+ietf@jck.com
téléphone : +1 909 457 4293
mél : ned.freed@mrochek.com