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	

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

Statut de ce mémoire
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.

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

Résumé
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.1 Conventions utilisées dans le document	2
2. Types d'accès de corps externes	2
2.1 Exigences d'enregistrement	2
2.2 Procédure d'enregistrement	2
2.3 Localisation de la liste des types d'accès enregistrés	3
2.4 Procédures de l'IANA pour enregistrer les types d'accès	3
3. Codages de transfert	3
3.1 Exigences de codage de transfert	3
3.2 Procédure de définition de codage de transfert	4
3.3 Procédures de l'IANA pour l'enregistrement de codage de transfert	5
3.4 Localisation de la liste de codages de transfert enregistrés	5
4. Considérations pour la sécurité	5
5. Considérations relatives à l'IANA 	5
6. Remerciements	5
7. Références	5
7.1 Références normatives	5
7.2 Références pour information	5
Appendice A Changements par rapport à la RFC 2048	6
Adresse des auteurs	6
Déclaration complète de droits de reproduction	6

1.	Introduction

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.

1.1	Conventions utilisées dans le document
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].

2.	Types d'accès de corps externes

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.

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

2.1.1	Exigences de désignation
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.

2.1.2	Exigences de spécification des mécanismes
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.

2.1.3	Exigences de publication
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.

2.1.4	Exigences de sécurité
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.

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

2.2.1	Présenter le type d'accès à la communauté
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é.

2.2.2	Révision du type d'accès
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].

2.2.3	Enregistrement par l'IANA
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.

2.3	Localisation de la liste des types d'accès enregistrés
Les enregistrements de type d'accès font l'objet d'une liste de l'IANA sur la page suivante de la Toile : http://www.iana.org/assignments/access-types 

2.4	Procédures de l'IANA pour enregistrer les types d'accès
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.

3.	Codages de transfert

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.

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

3.1.1	Exigences de désignation
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.

3.1.2	Exigences de spécification d'algorithme
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.

3.1.3	Exigences de domaine d'entrée
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.

3.1.4	Exigences de gamme de résultats
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.

3.1.5	Exigences d'intégrité et généralité des données
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.

3.1.6	Exigences des nouvelles fonctionnalités
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.

3.1.7	Exigences de sécurité
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.

3.2	Procédure de définition de 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.

3.3	Procédures de l'IANA pour l'enregistrement de codage de transfert
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é.

3.4	Localisation de la liste de codages de transfert enregistrés
La liste des enregistrements de codage de transfert se trouve à :

http://www.iana.org/assignments/transfer-encodings 

4.	Considérations pour la sécurité

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.

5.	Considérations relatives à l'IANA 

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.

6.	Remerciements

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.

7.	Références
7.1	Références normatives

[RFC2045]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", novembre 1996. (D. S., MàJ par 2184, 2231, 5335.)

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

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

[RFC4288]	N. Freed et J. Klensin, "Spécifications du type de support et procédures d'enregistrement", BCP 13, décembre  2005.

7.2	Références pour information

[RFC2026]	S. Bradner, "Le processus de normalisation de l'Internet -- Révision 3", (BCP0009) octobre 1996. (Remplace RFC1602, RFC1871) (MàJ par RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378, RFC6410)

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

Appendice A	Changements par rapport à la RFC 2048

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.

Adresse des auteurs

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 		

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

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