Groupe de travail Réseau |
N. Freed, Sun Microsystems |
Request for Comments : 4288 |
J. Klensin |
BCP n° 13 |
décembre 2005 |
RFC rendue obsolète : 2048 |
|
Catégorie : Bonnes pratiques actuelles |
Traduction Claude Brière de L'Isle |
Spécifications du type de support et procédures d'enregistrement
Statut du présent 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 définit les procédures pour la spécification et l'enregistrement des types de supports à utiliser dans MIME et les autres protocoles de l'Internet.
Table des Matières
1.1 Conventions utilisées dans le présent document
2. Préliminaires de l'enregistrement de type de support
3. Arbres d'enregistrement et noms de sous-type
3.3 Arbre personnel ou factice
3.5 Arbres d'enregistrement supplémentaires
4. Exigences pour l'enregistrement
4.2.5 Types de support Application
4.2.6 Types de support multipartie et message
4.2.7 Types de niveau supérieur supplémentaires
4.4 Exigences de canonisation et de format
4.5 Recommandations d'interopérabilité
4.7 Exigences spécifiques des types de supports XML
4.9 Non exigences d'usage et de mise en œuvre
4.11 Informations suplémentaires
5.1 Révision communautaire préliminaire
5.4 Réviseurs de types de supports
6. Commentaires sur les enregistrements de types de supports
7. Localisation de la liste des types de supports enregistrés
8. Procédures de l'IANA pour l'enregistrement des types de supports
11. Considérations pour la sécurité
12. Considérations relatives à l'IANA
14.2 Références pour information
Appendice A. Types de support anciens
Appendice B. Changements depuis la RFC 2048
Les protocoles récents de l'Internet ont été conçus avec soin pour être facilement extensibles dans certain domaines. En particulier, de nombreux protocoles, y compris MIME [RFC2045], sont capables de porter des contenus arbitraires étiquetés. Un mécanisme est nécessaire pour étiqueter un tel contenu et un processus d'enregistrement est nécessaire pour ces étiquettes, pour s'assurer que l'ensemble de telles valeurs est développé de façon ordonnée, bien spécifiée, et publique.
Le présent document définit les procédures de spécification et d'enregistrement des types de supports qui utilisent l'Autorité d'allocation des numéros de l'Internet (IANA, Internet Assigned Numbers Authority) comme registraire central.
Note historique
Le processus d'enregistrement du type de support a été initialement défini pour enregistrer les types de supports à utiliser dans le contexte de l'environnement de la messagerie Internet asynchrone. Dans cet environnement de messagerie, il est besoin de limiter le nombre de types de supports possibles, pour augmenter la probabilité de l'interopérabilité lorsque les capacités du système de messagerie distant ne sont pas connues. Comme les types de supports sont utilisés dans de nouveaux environnements dans lesquels la prolifération des types de supports n'est pas un obstacle à l'interopérabilité, la procédure d'origine s'est révélée excessivement restrictive et devait être généralisée. Cela a été initialement fait dans la [RFC2048], mais la procédure qui y est définie faisait partie de l'ensemble des documents MIME. La procédure de spécification et d'enregistrement des types de support est maintenant placée dans ce document distinct, pour rendre clair qu'elle est indépendante de MIME.
Il peut être souhaitable de restreindre l'utilisation des types de supports à des environnements spécifiques ou d'interdire leur utilisation dans d'autres environnements. La présente révision essaye pour la première fois d'incorporer de telles restrictions des enregistrements de types de supports dans un système. Voir au paragraphe 4.9 le développement de cette question.
1.1 Conventions utilisées dans le présent document
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF"sont à interpréter comme décrit dans la [RFC2119].
La présente spécification utilise la notation de forme Backus-Naur augmentée (ABNF) [RFC4234], y compris les règles centrales définies dans l'Appendice A du présent document.
2. Préliminaires de l'enregistrement de type de support
L'enregistrement d'un ou de nouveaux types de supports commence par la construction d'une proposition d'enregistrement. L'enregistrement peut survenir au sein de plusieurs arbres d'enregistrement différents qui ont des exigences différentes, comme on l'expliquera plus loin. En général, une nouvelle proposition d'enregistrement est diffusée et revue de la façon appropriée à l'arborescence impliquée. Le type de support est alors enregistré si la proposition est acceptable. Les sections qui suivent décrivent les exigences et procédures utilisées pour chacun des différents arbres d'enregistrement.
3. Arbres d'enregistrement et noms de sous-type
Afin d'augmenter l'efficacité et la souplesse du processus d'enregistrement, différentes structures de noms de sous-types peuvent être enregistrées pour s'accommoder des exigences naturelles différentes pour, par exemple, un sous-type qui va être recommandé pour une large prise en charge et mise en œuvre par la communauté de l'Internet, ou un sous-type qui est utilisé pour déplacer les fichiers associés à des logiciels propriétaires. Les paragraphes suivants définissent des "arbres" d'enregistrement qui sont distingués par l'utilisation de noms à facettes, par exemple, des noms de la forme "arbre.sous-arbre...sous-type". Noter que certains types de supports définis avant le présent document ne se conforment pas aux conventions de dénomination décrites ci-dessous. Voir à l'Appendice A pour des précisions.
L'arborescence standard est destinée aux types d'intérêt général pour la communauté de l'Internet. Les enregistrements dans l'arborescence standard DOIVENT être approuvés par l'IESG et DOIVENT correspondre à une publication formelle par un organisme de normalisation reconnu. Dans le cas d'enregistrement pour l'IETF elle-même, la proposition d'enregistrement DOIT être publiée comme RFC. Les RFC d'enregistrement dans l'arborescence standard peuvent être des RFC autonomes "d'enregistrement seul", ou elles peuvent être incorporées dans des spécifications plus générales de toutes sortes.
Les types de supports dans l'arborescence standard sont normalement notés par des noms qui ne sont pas explicitement à facettes, c'est-à-dire, qu'ils ne contiennent pas de caractères point (".").
Le "possesseur" d'un enregistrement de type de support dans l'arborescence standard est supposé être l'organisme de normalisation lui-même. La modification ou l'altération de la spécification exige le même niveau de traitement (par exemple, en cours de normalisation) que celui exigé pour l'enregistrement initial.
L'arbre de fabricant est utilisé pour les types de supports associés à des produits disponibles sur le marché. "Fabricant" ou "producteur" sont des termes compris comme équivalents et de sens très large dans ce contexte.
Un enregistrement peut être placé dans l'arbre de fabricant par quiconque a besoin d'échanger des fichiers associés à un produit particulier. Cependant, l'enregistrement appartient formellement au fabricant ou à l'organisation qui produit le logiciel ou format de fichier qui est enregistré. Les changements à la spécification seront effectués à leur demande, comme expliqué dans les paragraphes suivants.
Les enregistrements dans l'arbre de fabricant seront distingués par la facette de tête "vnd.". Elle peut être suivie, à la discrétion de l'enregistreur, par un nom de sous-type de support à partir d'un producteur bien connu (par exemple, "vnd.mudpie") ou par une désignation approuvée par l'IANA- du nom du producteur qui est suivi par une désignation de type de support ou de produit (par exemple, vnd.bigcompany.funnypictures).
Bien que la publication et la révision des types de supports à enregistrer dans l'arbre de fabricant ne soient pas exigées, l'utilisation de la liste de diffusion ietf-types@iana.org pour la révision est fortement encouragée pour améliorer la qualité de ces spécifications. Les enregistrements dans l'arbre de fabricant peuvent être soumis directement à l'IANA.
3.3 Arbre personnel ou factice
Les enregistrements pour les types de supports de création expérimentale ou au titre de produits qui ne sont pas distribués commercialement peuvent être enregistrés dans l'arbre personnel ou factice. Les enregistrements sont distingués par la facette de tête "prs.".
Le propriétaire des enregistrements "personnels" et des spécifications associées est la personne ou entité qui fait l'enregistrement, ou à qui la responsabilité a été transférée comme décrit ci-dessous.
Bien que la communication au public et la révision des types de supports à enregistrer dans l'arbre personnel ne soit pas exigée, l'utilisation de listes de types ietf pour la révision est fortement conseillée pour améliorer la qualité de ces spécifications. Les enregistrements dans l'arbre personnel sont soumis directement à l'IANA.
Pour des raisons pratiques et de symétrie avec ce schéma d'enregistrement, les noms de sous-types avec "x." comme première facette peuvent être utilisés pour les mêmes besoins que pour les noms qui commencent en "x-". Ces types sont non enregistrés, expérimentaux, et pour une utilisation exclusive avec l'accord actif des parties qui les échangent.
Cependant, avec les procédures d'enregistrement simplifiées décrites ci-dessus pour les arbres de fabricant et personnel, il sera rarement, sinon jamais, nécessaire d'utiliser les types expérimentaux non enregistrés. Donc, l'utilisation des formes "x-" et "x." est déconseillée.
Les types dans cette arborescence NE DOIVENT PAS être enregistrés.
3.5 Arbres d'enregistrement supplémentaires
De temps en temps, et en fonction des besoins de la communauté, l'IANA peut, selon l'avis et avec le consentement de l'IESG, créer de nouvelles arborescences d'enregistrement de niveau supérieur. Il est explicitement supposé que ces arborescences peuvent être créées pour l'enregistrement et la gestion externes par des organismes permanents bien connus; par exemple, des sociétés scientifiques peuvent enregistrer des types de supports spécifiques des sciences qu'elles couvrent. En général, la qualité de révision des spécifications pour un de ces arbres d'enregistrement supplémentaires est supposée être équivalente à celle des enregistrements de l'arborescence standard. L'établissement de ces nouvelles arborescences sera annoncée par la publication d'une RFC approuvée par l'IESG.
4. Exigences pour l'enregistrement
Les propositions d'enregistrement de types de supports sont toutes supposées êtres conformes aux diverses exigences exposées dans les paragraphes qui suivent. Noter que des exigences spécifiques varient parfois selon les arborescences d'enregistrement, là encore, précisées dans les paragraphes qui suivent.
Les types de supports DOIVENT fonctionner comme un format de support réel. L'enregistrement de choses qui seraient plutôt un codage de transfert, comme un jeu de caractères, ou comme une collection d'entités distinctes d'un autre type, n'est pas permis. Par exemple, bien qu'il existe des applications pour décoder le codage de transfert en base64 [RFC2045], le base64 ne peut pas être enregistré comme type de support.
Cette exigence s'applique sans considération de l'arborescence d'enregistrement impliquée.
Tous les types de supports enregistrés DOIVENT avoir des types et noms de sous-types alloués. La combinaison de ces noms sert à identifier de façon univoque le type de support, et le format du nom de sous-type identifie l'arborescence d'enregistrement. Les noms de type et de sous-types sont tous deux insensibles à la casse.
Les noms de types et de sous-types commençant par "X-" sont réservé pour les utilisations expérimentales et NE DOIVENT PAS être enregistrés. Cette restriction est parallèle à la restriction sur l'arborescence x., comme exposé au paragraphe 3.4.
Les noms de types et de sous-types DOIVENT se conformer à l'ABNF suivant :
nom-de-type = nom-enregistré
nom-de-sous-type = nom-enregistré
nom-enregistré = 1*127reg-name-chars
reg-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "." / "+" / "-" / "^" / "_"
Noter que cette syntaxe est un peu plus restrictive que celle permise par l'ABNF de la [RFC2045].
Conformément aux règles spécifiées dans la [RFC3023], les sous-types de supports qui ne représentent pas des entités XML NE DOIVENT PAS recevoir un nom se terminant par le suffixe "+xml". De façon plus générale, les constructions "+suffixe" devraient être utilisées avec prudence, sachant la possibilité de conflits avec des définitions de suffixes futures.
Bien qu'il soit possible que soient alloués des noms supplémentaires à un type de support donné, l'utilisation de noms différents pour identifier le même type de support est déconseillée.
Cette exigence s'applique sans considération de l'arborescence d'enregistrement impliquée.
Le choix d'un nom de type de niveau supérieur DOIT tenir compte de la nature du type de support impliqué. De nouveaux sous-types de types de niveau supérieur DOIVENT se conformer aux restrictions du type de niveau supérieur, s'il en est. Les paragraphes suivants décrivent chaque ensemble initial des types de niveau supérieur et les restrictions qui leur sont associées. De plus, divers protocoles, y compris, mais sans s'y limiter, MIME, PEUVENT imposer des restrictions supplémentaires aux types de supports qu'ils peuvent transporter. (Voir dans la [RFC2046] des informations supplémentaires sur les restrictions imposées par MIME.)
Le type de support "text" est destiné à l'envoi de matériel principalement de forme textuelle. Un paramètre "charset" (jeu de caractères) PEUT être utilisé pour indiquer le jeu de caractères du corps du texte pour les sous-types "text", notamment ceux qui incluent le sous-type "text/plain" (texte en clair), qui est un sous-type générique pour le texte en clair défini dans la [RFC2046]. Si il est défini, un paramètre "charset" de texte DOIT être utilisé pour spécifier un nom de jeu de caractères défini conformément aux procédures établies dans la [RFC2978].
Le texte en clair ne fournit ni ne permet pas les commandes de formatage, les spécifications d'attributs de police, les instructions de traitement, les directives d'interprétation, ou le marquage du contenu. Le texte en clair est vu simplement comme une séquence linéaire de caractères, éventuellement interrompue par des sauts de ligne ou des sauts de page. Le texte en clair PEUT permettre l'empilage de plusieurs caractères à la même position dans le texte. Le texte en clair dans les écritures comme l'arabe et l'hébreu peut aussi inclure des facilités qui permettent un mélange arbitraire de segments de texte avec des directions d'écriture opposées.
Au delà du texte en clair, il y a de nombreux formats pour représenter ce qui peut être appelé du "texte enrichi". Une caractéristique intéressante de nombre de ces représentations est qu'elles sont dans une certaine mesure lisibles même sans le logiciel qui les interprète. Il est utile de les distinguer, au plus haut niveau, de données illisibles comme les images, l'audio, ou le texte représenté sous une forme non lisible. En l'absence d'un logiciel d'interprétation approprié, il est raisonnable de présenter les sous-types de "text" à l'utilisateur, alors qu'il n'est pas raisonnable de le faire avec la plupart des données non textuelles. De telles données textuelles formatées devraient être représentées en utilisant des sous-types de "text".
Les type de support de "image" indiquent que le contenu spécifie une ou plusieurs images distinctes qui exigent un matériel approprié pour les afficher. Le sous-type désigne le format spécifique de l'image.
Un type de support "audio" indique que le contenu contient des données audio.
Un type de support de "vidéo" indique que le contenu spécifie une image qui varie dans le temps, éventuellement avec des couleurs et du son coordonné. Le terme "vidéo" est utilisé dans son sens le plus générique, plutôt qu'en référence à une technologie ou format particulier, et n'est pas destiné à exclure de sous-types tels que des dessins animés à codage compact.
Noter que bien qu'en général le présent document déconseille fortement le mélange de plusieurs supports dans un même corps, il est reconnu que beaucoup de formats dits de vidéo comportent une représentation d'audio synchronisé et/ou de texte, et ceci est explicitement permis pour les sous-types de "vidéo".
Le type de support "application" est à utiliser pour des données discrètes qui ne rentrent dans aucun des types de supports, et en particulier pour des données à traiter par un type de programme d'application. Ce sont des informations qui doivent être traitées par une application avant qu'elles ne soient visibles ou utilisables par un usager. Les utilisations prévues pour le type de support "application" incluent, mais sans s'y limiter, les transferts de fichiers, les spreadsheets, les présentations, les données de programmation, et les langages pour le matériel "actif" (de calcul). (Ces dernier, en particulier, peuvent poser des problèmes de sécurité qui doivent être compris par les mises en œuvre, et sont examinés en détails dans l'exposé sur le type de support "application/ PostScript" dans la [RFC2046].)
Par exemple, un programmeur de réunion pourrait définir une représentation standard d'informations sur les dates de réunion proposées. Un agent d'utilisateur intelligent utilisera ces informations pour conduire un dialogue avec l'utilisateur, et pourra alors envoyer du matériel supplémentaire sur la base de ce dialogue. Plus généralement, il y a eu plusieurs langages "actifs" développés dans lesquels des programmes dans un langage spécialisé convenable sont transportés jusqu'à une localisation distante et lancés automatiquement dans l'environnement du receveur. De telles applications peuvent être définies comme sous-types du type de support "application".
Le sous-type "application" va souvent être soit le nom, soit inclure une partie du nom de l'application pour laquelle les données sont destinées. Cela ne signifie cependant pas que tout nom de programme d'application puisse être librement utilisé comme sous-type de "application".
Multipartie et message sont des types composites, c'est à dire qu'ils fournissent un moyen d'encapsuler zéro, un ou plusieurs objets, étiqueté chacun avec son propre type de support.
Tous les sous-types de multipartie et de message DOIVENT se conformer aux règles de syntaxe et autres exigences spécifiées dans la [RFC2046].
Dans certains cas, un nouveau type de support peut ne pas "tenir" dans un type de contenu de niveau supérieur actuellement défini. On pense que de tels cas sont assez rares. Cependant, si un tel cas se présente, un nouveau type de niveau supérieur peut être défini pour le traiter. Une telle définition DOIT être faite par une RFC soumise à normalisation ; aucun autre mécanisme ne peut être utilisé pour définir des types de contenu de niveau supérieur supplémentaires.
Les types de supports PEUVENT choisir d'utiliser un ou plusieurs paramètres de type de support, ou certains paramètres peuvent être automatiquement disponibles pour le type de support par le fait qu'ils sont un sous-type d'un type de contenu qui définit un ensemble de paramètres applicables à tous ses sous-types. Dans l'un et l'autre cas, les noms, valeurs, et signification de tous les paramètres DOIVENT être complètement spécifiés lorsque un type de support est enregistré dans l'arborescence standard, et DEVRAIT être spécifié aussi complètement que possible lorsque les types de supports sont enregistrés dans les arborescences de fabricant ou personnelle.
Les noms de paramètres ont comme noms et valeurs de type de support la syntaxe suivante :
nom-de-paramètre = nom-enregistré
Noter que cette syntaxe est un peu plus restrictive que ce qui est permis par l'ABNF de la [RFC2045] amendée par la [RFC2231].
Il n'y a pas de syntaxe définie pour les valeurs de paramètres. Les enregistrements DOIVENT donc spécifier la syntaxe de valeur de paramètre. De plus, certains transports imposent des restrictions à la syntaxe de valeur de paramètre, et il faut donc faire attention à limiter l'usage de syntaxes potentiellement problématiques ; par exemple, les paramètres avec de pures valeurs binaires, bien que permis dans certains protocoles, devraient probablement être évités.
De nouveaux paramètres NE DEVRAIT PAS être définis comme un moyen d'introduire de nouvelles fonctionnalités dans des types enregistrés dans l'arborescence standard, bien que de nouveaux paramètres PUISSENT être ajoutés pour porter des informations supplémentaires qui ne changent pas par ailleurs la fonctionnalité existante. Un exemple en serait un paramètre "révision" pour indiquer un niveau de révision d'une spécification externe comme JPEG. Un comportement similaire est conseillé pour les types de supports enregistrés dans les arborescences de fabricant ou personnelle mais n'est pas exigé.
4.4 Exigences de canonisation et de format
Tous les types de supports enregistrés DOIVENT employer un seul format de données canonisées, sans considération de l'arborescence d'enregistrement.
Une spécification précise et librement disponible du format de chaque type de support DOIT exister pour tous types enregistrés dans l'arborescence standard et DOIT au minimum être référencée par la proposition d'enregistrement du type de support, si elle n'y est pas en fait incluse elle même.
Les spécifications des particularités de format et de traitement peuvent ou non être librement disponibles pour les types de supports enregistrés dans l'arborescence des fabricants, et il est explicitement permis à de telles propositions d'enregistrement de limiter leur spécification aux logiciels et versions qui produisent ou traitent de tels types de supports. Les références aux spécifications de format, ou leur inclusion dans les propositions d'enregistrement est conseillée mais non exigée.
L'enregistrement des spécifications de format est encore exigé pour l'arborescence personnelle, mais elles peuvent soit être publiées comme RFC soit déposées par ailleurs auprès de l'IANA. Les spécifications déposées doivent satisfaire aux mêmes critères que celles dont il est exigé qu'elles enregistrent un accès TCP bien connu, en particulier, elles n'ont pas besoin d'être rendues publiques.
Certains types de supports impliquent l'utilisation de technologie brevetées. L'enregistrement de types de supports impliquant des technologie brevetées est spécifiquement permis. Cependant, les restrictions avancées dans la [RFC2026] sur l'utilisation de technologies brevetées dans les protocoles en cours de normalisation de l'IETF doivent être respectées lorsque la spécification d'un type de support fait partie d'un protocole en cours de normalisation. De plus, d'autres organismes de normalisation qui utilisent l'arborescence standard peuvent avoir leurs propres règles en ce qui concerne les droits de propriété intellectuelle qui doivent être observés dans leurs enregistrements.
4.5 Recommandations d'interopérabilité
Les types de supports DEVRAIENT interopérer à travers autant de systèmes et applications que possible. Cependant, certains types de supports vont inévitablement avoir des problèmes d'interopération à travers des plates-formes différentes. Les problèmes avec des versions différentes, l'ordre des octets, et les spécificités du traitement des passerelles peuvent, et vont, survenir.
L'interopérabilité universelle des types de supports n'est pas exigée, mais les problèmes d'interopérabilité connus DEVRAIENT être identifiés chaque fois que possible. La publication d'un type de support ne requiert pas une revue exhaustive de son interopérabilité, et la section de considérations d'interopérabilité est l'objet d'une évaluation permanente.
Ces recommandations s'appliquent sans considération de l'arborescence d'enregistrement impliqué.
Une analyse des questions de sécurité DOIT être effectuée pour tous les types enregistrés dans l'arborescence standard. Une analyse similaire est conseillée, mais non exigée pour les types de supports enregistrés dans les arborescences de fabricant ou personnelle. Cependant, sans considération de la nature de l'analyse de sécurité qui a été ou non faite, toutes les descriptions de questions de sécurité DOIVENT être aussi précises que possible sans considération de l'arborescence d'enregistrement. En particulier, la déclaration qu'il "n'y a pas de problème de sécurité associé à ce type" NE DOIT PAS être confondue avec "les problèmes de sécurité associés à ce type n'ont pas été vérifiés".
Il n'est absolument pas exigé que les types de supports enregistrés dans une des arborescences soient sécurisés ou absolument sans risque. Néanmoins, tous les risques connus pour la sécurité DOIVENT être identifiés dans l'enregistrement d'un type de support, là encore, sans considération de l'arborescence d'enregistrement.
La section des considérations pour la sécurité de tout enregistrement est soumise à une évaluation permanente et à modification, et en particulier PEUT être étendue par l'utilisation des mécanismes de "commentaires sur les types de supports" décrits à la Section 6 ci-dessous.
Certaines des questions qui devraient être regardées dans une analyse de sécurité d'un type de support sont :
o Les types de supports complexes peuvent inclure des dispositions qui donnent des directives qui instituent des actions sur les fichiers ou autres ressources d'un receveur. Dans de nombreux cas, des dispositions sont prises pour que le générateur spécifie des actions arbitraires sans restriction qui peuvent avoir des effets dévastateurs. Voir un exemple de telles directives dans l'enregistrement du type de support application/postscript dans la [RFC2046] et de la façon dont il devrait être décrit dans un enregistrement de type de support.
o Tous les enregistrements DOIVENT déclarer si ils emploient ou non un tel "contenu actif", et si ils le font, ils DOIVENT déclarer quelles mesures sont prises pour protéger les utilisateurs du type de support contre les dommages éventuels.
o Les types de supports complexes peuvent inclure des dispositions pour donner des directives qui instituent des actions qui, bien que non directement dommageables pour le receveur, peuvent résulter en la divulgation d'informations qui vont faciliter une attaque ultérieure ou violer d'une certaine manière la confidentialité du receveur. Là encore, l'enregistrement du type de support application/postscript illustre comment peuvent être traitées de telles directives.
o Un type de support qui emploie la compression peut fournir une opportunité d'envoi d'une petite quantité de données qui, lorsque elles sont reçues et évaluées, se développent énormément pour consommer toutes les ressources du receveur. Tous les types de supports DEVRAIENT déclarer si ils emploient ou non la compression, et s'ils l'emploient, ils devraient exposer quelles mesures doivent être prises pour éviter de telles attaques.
o Un type de support pourrait être ciblé sur des applications qui requièrent une sorte d'assurance de sécurité mais ne fournissent pas elles-mêmes les mécanismes de sécurité nécessaires. Par exemple, un type de support pourrait être défini pour la mémorisation d'informations médicales confidentielles qui à son tour exige un service de confidentialité externe, ou qui serait conçu pour une utilisation exclusive en environnement sécurisé.
4.7 Exigences spécifiques des types de supports XML
Un certain nombre d'exigences supplémentaires sont spécifiques des enregistrements des types de supports XML. Ces exigences sont spécifiées dans la [RFC3023].
Certains transports imposent des restrictions sur le type de données qu'ils peuvent transporter. Par exemple, la messagerie Internet était traditionnellement limitée à du texte US-ASCII à 7 bits. Les schémas de codage sont souvent utilisés pour contourner de telles limitations de transport.
Il est donc utile de noter au titre de son enregistrement en quelles sortes de données un type de support peut consister. Un champ "considérations de codage" est fourni à cet effet. Les valeurs possibles pour ce champ sont :
7 bits : Le contenu du type de support consiste uniquement en texte US-ASCII à 7 bits délimité par des CRLF.
8 bits : Le contenu du type de support consiste uniquement en texte à 8 bits délimité par des CRLF.
binaire : Le contenu consiste en séquences d'octets sans restriction.
tramé : Le contenu consiste en une série de trames ou de paquets sans tramage interne ni indicateurs d'alignement. Des informations hors bande supplémentaires sont nécessaires pour interpréter correctement les données, y compris, mais pas nécessairement limité, à la connaissance des frontières entre les trames successives et la connaissance du mécanisme de transport. Noter que les types de supports de cette sorte ne peuvent pas être simplement mémorisés dans un fichier ou transportés comme un simple flux d'octets ; donc, de tels types de supports ne conviennent pas pour une utilisation dans de nombreux protocoles traditionnels. Un transport communément utilisé avec le codage tramé est le protocole de transport en temps réel (RTP, Real-time Transport Protocol). Des règles supplémentaires pour les codages tramés définis pour le transport qui utilise RTP sont données dans la [RFC3555].
Des restrictions supplémentaires sur le texte à 7 bits et à 8 bits figurent dans la [RFC2046].
4.9 Non exigences d'usage et de mise en œuvre
Dans l'environnement de messagerie asynchrone, où les informations sur les capacités de l'agent de messagerie distant sont fréquemment indisponibles à l'envoyeur, l'interopérabilité maximum est atteinte en restreignant les types de supports utilisés à ceux de format "commun" dont on s'attend à ce qu'ils soient largement mis en œuvre. Cela a été affirmé dans le passé comme une raison de la limitation du nombre de types de supports possibles, et il en résulte des obstacles et des délais significatifs au processus d'enregistrement de ces types de supports.
Cependant, le besoin de types de supports "communs" n'exige pas de limiter l'enregistrement de nouveaux types de supports. Si un ensemble limité de types de supports est recommandé pour une application particulière, cela devrait être affirmé par une déclaration d'applicabilité distincte, spécifique de l'application et/ou de l'environnement.
Donc, la prise en charge et la mise en œuvre universelle d'un type de support N'EST PAS une exigence d'enregistrement. Cependant, si un type de support est explicitement destiné à une utilisation limitée, cela DOIT être noté dans son enregistrement. Le champ "Restrictions d'utilisation" est fourni à cette fin.
Les propositions d'enregistrements de types de supports dans l'arborescence standard par l'IETF elle-même DOIVENT être publiées comme RFC. La publication de RFC de propositions de types de support de fabricants et personnelles est conseillée mais pas exigée. Dans tous les cas, l'IANA gardera des copies de toutes les propositions de types de support et les "publiera" au titre de l'arborescence d'enregistrement des types de supports elle-même.
Comme déclaré précédemment, les enregistrements dans l'arborescence standard pour les types de supports définis dans les documents produits par d'autres organismes de normalisation DOIVENT être décrits par une spécification de norme formelle produite par cet organisme. De telles spécifications DOIVENT contenir un gabarit d'enregistrement de type de support approprié tiré de la Section 10. De plus, les droits de reproduction sur le gabarit d'enregistrement DOIVENT permettre à l'IANA de le copier dans le registre de l'IANA.
En dehors des enregistrements de l'IETF dans l'arborescence standard, l'enregistrement d'un type de données n'implique pas l'endossement, l'approbation, ou la recommandation par l'IANA ou par l'IETF ou même la certification que la spécification est adéquate. Pour devenir une norme de l'Internet, un protocole ou objet de données doit passer par le processus de normalisation de l'IETF. C'est un processus trop difficile et trop long pour un enregistrement pratique des types de supports.
L'arborescence standard existe pour les types de supports qui exigent effectivement une révision de substance et un processus d'approbation par un organisme de normalisation reconnu. Les arborescences de fabricant et personnel existent pour les types de supports qui n'exigent pas un tel processus. Il est prévu que les déclarations d'applicabilité pour des applications particulières soient publiées de temps en temps par l'IETF, recommandant la mise en œuvre et la prise en charge des types de supports qui se sont révélés être particulièrement utiles dans ces contextes.
Comme exposé plus haut, l'enregistrement d'un type de niveau supérieur requiert le traitement de production d'une norme dans l'IETF et donc, la publication d'une RFC.
4.11 Informations supplémentaires
Diverses sortes d'informations facultatives DEVRAIENT être incluses dans la spécification d'un type de support si elles sont disponibles :
o Les numéros magiques (longueur, valeurs d'octet). Les numéros magiques sont des séquences d'octet qui sont toujours présentes à un endroit donné dans le fichier et peuvent donc être utilisées pour identifier les entités comme étant d'un type de support donné.
o La ou les extensions de nom de fichier couramment utilisées sur une ou plusieurs plates-formes pour indiquer qu'un certain fichier contient un type de support donné.
o Le ou les codes de type de fichier d'OS Mac (4 octets) utilisés pour étiqueter les fichiers qui contiennent un type de support donné.
o Les informations sur la façon dont les identifiants de fragment/ancre [RFC3986] sont construits pour les utiliser en conjonction avec ce type de support.
Dans le cas d'un enregistrement dans l'arborescence standard, ces informations supplémentaires PEUVENT être fournies dans la spécification formelle du type de support. Il est suggéré que cela soit fait en incorporant le formulaire d'enregistrement IANA de type de support dans la spécification elle-même.
La procédure d'enregistrement de type de support n'est pas un processus formel de normalisation, mais plutôt une procédure administrative destinée à permettre les commentaires et les vérifications de bonne tenue par la communauté sans introduire de délais excessifs.
Le processus normal de l'IETF devrait être suivi pour tous les enregistrements de l'IETF dans l'arborescence standard. L'envoi d'un Projet Internet est la première étape nécessaire, suivie par l'envoi à la liste de diffusion ietf-types@iana.org comme indiqué plus loin.
Les enregistrements dans les arborescences de fabricant et personnelle devraient être soumises directement à l'IANA, en théorie après les avoir envoyés pour révision à la liste ietf-types@iana.org.
Les enregistrements proposés dans l'arborescence standard par d'autres organismes de normalisation devraient être communiqués à l'IESG (à iesg@ietf.org) et à la liste des types ietf (à ietf-types@iana.org). L'envoi préalable comme Projet Internet n'est pas exigé pour ces enregistrements, mais cela peut être utile pour l'IESG, et est donc conseillé.
5.1 Révision communautaire préliminaire
L'avis d'un potentiel enregistrement de type de support dans l'arborescence standard DOIT être envoyé à la liste de diffusion "ietf-types@iana.org" pour révision. Cette liste de diffusion a été établie pour les besoins de la révision des propositions de types de supports et d'accès. L'enregistrement dans d'autres arborescences PEUT être envoyé aussi à la liste pour révision.
L'intention de l'envoi public à la liste est de solliciter des commentaires et des retours sur le choix des noms de type/sous-type, la non ambiguïté des références par rapport aux informations de versions et de profilage externe, et une révision de toutes considérations d'interopérabilité ou de sécurité. Le postulant peut soumettre un enregistrement révisé ou abandonner complètement l'enregistrement à tout moment.
Les types de support enregistrés dans l'arborescence standard DOIVENT être approuvés par l'IESG avant l'enregistrement.
Pourvu que le type de support satisfasse à toutes les exigences pertinentes et ait obtenu toutes les approbations nécessaires, l'auteur peut soumettre la demande d'enregistrement à l'IANA. Les demandes d'enregistrement peuvent être envoyées à iana@iana.org. Un formulaire électronique est aussi disponible pour les demandes d'enregistrement.
http://www.iana.org/cgi-bin/mediatypes.pl
L'envoi à ietf-types@iana.org ne constitue pas la soumission de l'enregistrement à l'IANA.
Lorsque l'enregistrement fait partie d'une demande de publication de RFC ou d'un enregistrement dans l'arborescence standard soumise à l'IESG, une coordination étroite entre l'IANA et l'IESG signifie que l'approbation par l'IESG soumet en fait l'enregistrement à l'IANA. Il n'y a pas besoin d'une autre demande d'enregistrement de tels cas.
5.4 Réviseurs de types de supports
Les enregistrements soumis à l'IANA seront passés au réviseur de types de supports. Le réviseur de types de supports, qui est nommé par les directeurs de zone d'application de l'IETF, va revoir l'enregistrement pour s'assurer qu'il satisfait aux exigences établies dans le présent document. Les enregistrements qui ne satisfont pas à ces exigences seront renvoyées pour révision au soumettant.
On peut faire appel des décisions prises par le réviseur de types de supports devant l'IESG en utilisant la procédure spécifiée dans la [RFC2026] paragraphe 6.5.4.
Une fois qu'un enregistrement de type de support a passé la révision, l'IANA va enregistrer le type de support et rendre l'enregistrement de type de support disponible à la communauté.
6. Commentaires sur les enregistrements de types de supports
Les commentaires sur les types de supports enregistrés peuvent être soumis par les membres de la communauté à l'IANA. Ces commentaires seront révisés par les réviseurs de types de supports et ils seront communiqués au "propriétaire" du type de support si possible. Ceux qui soumettent des commentaires peuvent demander que leur commentaire soit joint à l'enregistrement de type de support lui-même, et si l'IANA l'approuve, le commentaire sera rendu accessible conjointement avec l'enregistrement de type.
7. Localisation de la liste des types de supports enregistrés
La liste des enregistrements de types de supports est tenue par l'IANA à l'adresse :
http://www.iana.org/assignments/media-types/
8. Procédures de l'IANA pour l'enregistrement des types de supports
L'IANA n'enregistrera les types de supports dans l'arborescence standard qu'en réponse à une communication de l'IESG déclarant qu'un enregistrement donné a été approuvé. Les types fabriquant et personnel seront enregistrés automatiquement par l'IANA sans aucun processus d'approbation formelle pour autant que les conditions minimales suivantes soient satisfaites :
o Les types de supports DOIVENT fonctionner comme un format de support réel. En particulier, les jeux de caractères et les codages de transfert NE DOIVENT PAS être enregistrés comme types de supports.
o Tous les types de supports DOIVENT avoir des types et noms de sous-types formés correctement. Tous les noms de type DOIVENT être définis par des RFC en cours de normalisation. Toutes les paires de nom type/sous-type DOIVENT être uniques et DOIVENT contenir le préfixe d'arborescence approprié.
o Les types enregistrés dans l'arborescence personnelle DOIVENT fournir une spécification de format ou un pointeur sur une spécification de format.
o Tous les types de supports DOIVENT avoir une section raisonnable de considérations pour la sécurité. (Il n'est ni possible ni nécessaire que l'IANA mène une enquête de sécurité complète sur les enregistrements de type de support. Néanmoins, l'IANA a autorité pour identifier le matériel évidemment incorrect et le retourner au soumettant pour révision.)
Les enregistrements dans l'arborescence standard DOIVENT satisfaire aux exigences supplémentaires qui ont pour origine l'IETF elle-même ou un autre organisme de normalisation reconnu comme tel par l'IETF.
Une fois qu'un type de support a été publié par l'IANA, son propriétaire peut demander un changement de sa définition. La descriptions des différentes arborescences d'enregistrement ci-dessus désigne les "propriétaires" de chaque type d'enregistrement. La même procédure qui serait appropriée pour la demande originale d'enregistrement est utilisée pour traiter une demande de changement.
Les changements devraient n'être demandés que lorsque il y a de sérieuses omissions ou erreurs dans la spécification publiée. Lorsque la révision est demandée, une demande de changement peut être refusée si elle devrait rendre invalides dans la nouvelle définition des entités qui étaient valides sous la précédente définition.
Le propriétaire d'un type de support peut passer sa responsabilité à une autre personne ou agence en informant l'IANA et la liste des types ietf ; cela peut être fait sans discussion ou révision.
L'IESG peut réallouer la responsabilité d'un type de support. Le cas le plus courant en sera pour permettre de faire des changements à des types dont l'auteur de l'enregistrement est décédé, déplacé ou injoignable ou est autrement incapable de faire des changements qui sont importants pour la communauté.
Les enregistrements de type de support ne peuvent pas être supprimées ; les types de supports dont on estime qu'ils ne sont plus appropriés peuvent être déclarés OBSOLETE par un changement de leur champ "utilisation prévue" ; de tels types de supports seront clairement marqués dans les listes publiées par l'IANA.
À : ietf-types@iana.org
Objet : Enregistrement du type de support XXX/YYY
Nom du Type :
Nom du sous-type :
Paramètres exigés :
Paramètres facultatifs :
Considérations de codage :
Considérations de sécurité :
Considérations d'interopérabilité :
Spécification publiée :
Applications qui utilisent ce type de support :
Informations supplémentaires :
Numéros magiques :
Extensions de fichier :
Codes de type de fichier Macintosh :
Adresse de la personne à contacter pour des informations complémentaires :
Utilisation prévue :
(UTILISATION COMMUNE, LIMITÉE ou OBSOLETE.)
Restrictions d'usage :
(Toutes restrictions sur l'endroit où le type de support peut être utilisé viennent ici.)
Auteur :
Contrôleur des changements :
(Toutes les autres informations que l'auteur estime intéressantes peuvent être ajoutées en dessous de cette ligne.)
On trouvera un exposé sur les codes de type de fichier Macintosh et leur objet dans [MacOSFileTypes]. On est de plus prié de s'abstenir d'écrire "aucune" ou des mentions similaires lorsque aucune extension de fichier ou type de fichier Macintosh n'est spécifié, car "aucune" peut être confondu avec une valeur de code réelle.
11. Considérations pour la sécurité
Les exigences de sécurité pour les enregistrements de type de support sont exposées au paragraphe 4.6.
12. Considérations relatives à l'IANA
L'objet du présent document est de définir les registres de l'IANA pour les types de support.
Les auteurs actuels tiennent à reconnaître leurs dettes à 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 est de celles qui auraient recueilli sont agrément, mais comme il est impossible de vérifier cet accord, nous avons dû à regret retirer son nom de la liste de co-auteurs.
[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.)
[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.
[RFC2978] N. Freed et J. Postel, "Procédures d'enregistrement des jeux de caractère par l'IANA", BCP 19, octobre 2000.
[RFC3023] M. Murata, S. St.Laurent et D. Kohn, "Types de support XML", janvier 2001.
[RFC3555] S. Casner et P. Hoschka, "Enregistrement de type MIME pour les types de charge utile RTP", juillet 2003.
[RFC3986] T. Berners-Lee, R. Fielding et L. Masinter, "Identifiant de ressource uniforme (URI) : Syntaxe générique", STD 66, janvier 2005.
[RFC4234] D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", octobre 2005. (Remplacé par 5234)
14.2 Références pour information
[MacOSFileTypes] Apple Computer, Inc., "Mac OS: File Type and Creator Codes, and File Formats", Apple Knowledge Base Article 55381, June 1993, <http://www.info.apple.com/kbnum/n55381>.
[RFC2026] S. Bradner, "Le processus de normalisation de l'Internet -- Révision 3", (BCP0009) octobre 1996. (Remplace RFC1602, RFC1871) (MàJ parRFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378)
[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-89)
[RFC2231] N. Freed, K. Moore, "Extensions MIME Valeur de paramètre et Mot codé : jeux de caractères, langages, et continuations", novembre 1997. (P.S.)
Appendice A. Types de support anciens
Un certain nombre de types de supports, enregistrés avant 1996, auraient dû, s'il avaient été enregistrés selon les lignes directrices du présent document, être placés dans les arbres de fabricant ou personnels. Le réenregistrement de ces types pour refléter les arborescences appropriées est conseillé mais pas exigé. Les principes de propriété et de contrôle des modifications soulignés dans le présent document s'appliquent à ces types comme si ils avaient été enregistrés dans les arborescences décrites ci-dessus.
Appendice B. Changements depuis la RFC 2048
o Les procédures de spécification et d'enregistrement de type de support ont été retirées de l'ensemble des documents MIME pour être placées dans cette spécification distincte.
o Les diverses URL et adresses dans ce document ont été changées de telle sorte qu'elles se réfèrent toutes à iana.org plutôt qu'à isi.edu. De plus, beaucoup des URL ont été changées de façon à utiliser HTTP, au lieu de 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 L'arborescence IETF non articulée est maintenant appelée l'arborescence standard, et les règles d'enregistrement pour cette arborescence ont été assouplies pour permettre son utilisation par d'autres organisations de normalisation.
o Le texte qui décrit la procédure d'enregistrement de type de support a été précisé.
o Les règles et exigences pour la construction des sections de considérations pour la sécurité ont été étendues et précisées.
o La RFC 3023 est maintenant référencée comme source des informations supplémentaires concernant l'enregistrement des types de supports XML.
o Plusieurs des références dans ce document ont été mises à jour pour se référer aux versions actuelles des spécifications pertinentes.
o Une note a été ajoutée pour déconseiller l'allocation de plusieurs noms à un même type de support.
o Les sections de considérations pour la sécurité et relatives à l'IANA ont été ajoutées.
o Les questions concernant les droits de reproduction sur les gabarits d'enregistrement de type de support produits par d'autres organismes de normalisation ont été traitées en exigeant que l'IANA soit autorisée à copier le gabarit d'enregistrement dans le registre.
o Les exigences de base de l'enregistrement pour les divers types de niveau supérieur ont été déplacées de la RFC 2046 à ce document.
o Une syntaxe est maintenant spécifiée pour les noms de type de support, de sous-type, et de paramètres.
o Une longueur maximum de 127 est imposée sur tous les noms de types et de sous-types de supports.
o Une note a été ajoutée pour prévenir contre l'utilisation excessive des constructions "+suffixe" dans les noms de sous-types.
o Le champ Considérations de codage a été étendu pour permettre la valeur "tramé".
o Une référence décrivant les codes de type Macintosh a été ajoutée.
o La révision des listes de types ietf d'enregistrement dans l'arborescence standard est maintenant exigée plutôt que seulement recommandée.
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 copyright
Copyright (C) The Internet Society (2006).
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 qui y sont 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 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 l’activité de soutien administratif (IASA) de l’IETF.