Groupe de travail Réseau	G. Klyne, Content Technologies	
Request for Comments : 2912	septembre 2000	
Catégorie : En cours de normalisation	Traduction : Claude Brière de L’Isle	

Indication des caractéristiques de support pour contenu MIME

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "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.

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

Résumé
Dans "Syntaxe de description des ensembles de caractéristiques de supports", un format d’expression est présenté pour décrire les capacités de caractéristiques des supports en utilisant des étiquettes simples de caractéristique du support.

Le présent mémoire définit un en-tête d’extensions multi objets de messagerie Internet (MIME, Multipurpose Internet Mail Extensions) "Caractéristiques-de-contenu:" qui peut être utilisé pour annoter une partie de message MIME en utilisant ce format d’expression, et indique des façons dont il pourrait être utilisé.

Table des Matières

1.	Introduction
1.1	Terminologie et conventions pour le document
2.	Motifs et objectifs
3.	En-tête MIME "Caractéristiques-de-contenu:"
3.1	Espace et retour à la ligne dans les en-têtes longs
3.2	Considérations pour l'utilisation
4.	Exemples
4.1	Message simple
4.2	Message de télécopie
4.3	Multipartie/autres données
4.4	Référence à des données de message externe
4.5	Données compressées
4.6	Multiparties/données en rapport
5.	Considérations pour la sécurité
6.	Remerciements
7.	Références
8.	Adresse de l’auteur
9.	Déclaration complète de droits de reproduction

1.	Introduction

Dans "Syntaxe de description des ensembles de caractéristiques de supports" [1], un format d’expression est présenté pour décrire les capacités de caractéristiques des supports comme une combinaison de simples étiquettes de caractéristique de support, enregistrées conformément à la "Procédure d'enregistrement d'étiquette de caractéristique de support" [2]. Cela donne un format pour que les agents de traitement de message décrivent le contenu de la caractéristique du support des messages qu’ils peuvent traiter.

Le présent mémoire définit un en-tête MIME "Caractéristiques-de-contenu:" qui peut être utilisé pour annoter une partie de message MIME en utilisant ces expressions de caractéristiques. Cet en-tête donne le moyen d’indiquer les caractéristiques en rapport avec le support du contenu de message qui vont plus loin que le type de contenu MIME.
On examine aussi la façon dont il peut être utilisé pour présenter les informations de contenu du support du message qu’il est problématique d’exprimer au sein du cadre MIME de base.

1.1	Terminologie et conventions pour le document

Ce paragraphe définit un certain nombre de termes et autres conventions documentaires, qui sont utilisés avec une signification particulière dans le présent mémoire.

caratéristique de support
Ce sont des informations qui indiquent les facilités supposées disponibles pour que le contenu du message soit correctement restitué ou présenté de quelque façon que ce soit. Les caractéristiques de support ne sont pas destinées à comporter des informations affectant la transmission du message.

ensemble de caractéristiques
C’est un certain ensemble des caractéristiques du support décrites dans une assertion de caractéristique de support, telles que décrites dans "Syntaxe de description des ensembles de caractéristiques de supports" [1]. (Voir dans ce document une définition plus formelle de ce terme.)

expression d’un ensemble de caractéristiques
C’est une chaîne qui décrit un certain ensemble de caractéristiques, formulée conformément aux règles établies dans "Syntaxe de description des ensembles de caractéristiques de supports" [1] (et éventuellement étendues par d’autres spécifications).

La présente spécification utilise la notation et les conventions syntaxiques décrites dans la RFC2234 "BNF augmenté pour les spécifications de syntaxe : ABNF" [3].

Note :	Les commentaires du type de celui-ci donnent des informations supplémentaires non essentielles sur les raisons sous-jacentes au document. De telles informations ne sont pas nécessaires pour construire une mise en œuvre conforme, mais peuvent aider ceux qui souhaitent comprendre le concept plus en profondeur.

2.	Motifs et objectifs

Il est envisagé que l’étiquetage des caractéristiques de support des parties du message puisse être utilisé de la façon suivante :

o	pour fournir des informations plus détaillées de caractéristiques du ssupport sur un contenu de message qui peut être fourni par l’en-tête "Type-de-contenu:".

o	pour fournir des informations sommaires de caractéristiques du support (comportant éventuellement les types de contenu MIME) sur le contenu d’une partie d’un message MIME composite (par exemple "multipartie" ou "message"), sans avoir à ouvrir le contenu propre du message.

o	pour fournir des informations du support sur des données externes référencées par une partie d’un message (par exemple, le type MIME "message/corps-externe"). Ces informations ne seraient pas disponibles par l’examen du contenu du message.

o	pour décrire le contenu d’un message qui est chiffré ou codé en utilisant une structure de fichier spécifique de l’application qui cache le contenu au processeur MIME. Ces informations ne seraient pas non plus généralement disponibles par l’examen du contenu du message.

3.	En-tête MIME "Caractéristiques-de-contenu:"

Un nouveau champ d’en-tête est défini pour étendre les formats autorisés pour "champ-facultatif" [4] avec la syntaxe suivante :

champ-facultatif =/ "Caractéristiques-de-contenu" ":" Expression-de-caractéristique
Expression-de-caractéristique =  filtre	; Voir [1], paragraphe 4.1

où "filtre" est le format d'expression de caractéristique du support défini par la "Syntaxe de description des ensembles de caractéristiques de support" [1].

Cet en-tête donne des informations supplémentaires sur le contenu de message directement contenu ou référencé indirectement dans la partie de message MIME correspondante.

3.1	Espace et retour à la ligne dans les en-têtes longs

Dans certaines circonstances, les expressions de caractéristiques du support peuvent être très longues.

Conformément à "Syntaxe de description des ensembles de caractéristiques de support" [1], une espace blanche est admise entre des éléments lexicaux d'une expression de caractéristique de support. De plus, la RFC822/MIME [4], [5] permet le saut à la ligne de longs en-têtes aux points où des espaces blanches apparaissent pour éviter des restrictions de longueur de ligne.

Donc, il est recommandé que des espaces blanches soient incluses comme il est permis, en particulier dans de longues expressions de caractéristiques de support, pour faciliter le saut à la ligne d'en-tête par les agents qui ne comprennent pas par ailleurs la syntaxe de ce champ.

3.2	Considérations pour l'utilisation
3.2.1	Parties de message simple
Lorsque appliqué à une partie de message MIME simple, l'en-tête devrait apparaître une seule fois et il est utilisé pour convoyer des informations supplémentaires sur le contenu de la partie de message qui va au delà de celles fournies par le champ d'en-tête "Type-de-contenu:" MIME. L'en-tête "Type-de-contenu:" peut indiquer un type de contenu différent de celui donné dans l'en-tête MIME "Type-de-contenu:". C'est possible mais non recommandé lorsque appliqué à une partie de corps non composite : dans tous les cas, le traitement du type de contenu MIME doit être effectué conformément à l'en-tête "Type-de-contenu:".

Note : Une fois que le contenu du message a été livré à une application, il est possible que le  traitement ultérieur soit affecté par les informations de type de contenu indiquées par l'expression de caractéristiques de support. Voir l'exemple 4.5 ci-dessous.

3.2.2	Multiparties et autres composites
Les en-têtes "Type-de-contenu:" peuvent être appliqués à une multipartie MIME, indiquant des informations sur le contenu interne de la multipartie.

Les mises en œuvre ne doivent pas supposer une relation biunivoque entre les en-têtes "Caractéristiques-de-contenu" et les parties de corps contenues. Les en-têtes peuvent apparaître sur une enveloppe multipartie contenante dans un ordre différent de celui des parties de corps auxquelles elles se réfèrent ; un seul en-tête peut se référer à plus d'une partie contenue ; plusieurs en-têtes peuvent se référer à la même partie de corps contenue.

Il est important de mettre en relation les caractéristiques de support spécifiques de parties de corps MIME contenues spécifiques, donc l'en-tête "Caractéristique-de-contenu:" devrait être appliqué directement à la partie de corps concernée, plutôt qu'au composite environnant.

Note :	L'intention est ici de permettre que soient fournies des informations sommaires de caractéristiques de support sans avoir à ouvrir et examiner le contenu interne du message MIME.

Une utilisation similaire peut s'appliquer lorsque le format du message est un composite non MIME ou opaque ; par exemple, "application/zip", ou un message chiffré. Dans ces cas, l'option d'examiner le contenu du message pour découvrir les informations de caractéristique du support n'est pas disponible.

3.2.3	Référence à des données externes
Les informations de caractéristique du support sur des données indirectement référencées par une partie de corps MIME plutôt que contenues au sein d'un message peuvent être convoyées en utilisant un ou plusieurs en-têtes "Caractéristiques-de-contenu:".

Par exemple, des informations sur le support – y compris un ou des types de contenu MIME contenus – sur les données référencées par un "Message/corps-extérieur" MIME peuvent être transportées.
4.	Exemples
4.1	Message simple

Mime-Version: 1.0
Type-de-contenu: texte/plain;charset=US-ASCII
Caractéristique-de-contenu: (& (taille-papier=A4) (ua-media=stationery) )

:
(données)
:

4.2	Message de télécopie

Mime-Version: 1.0
Type-de-contenu: multipartie/mixte; limite="break"
Caractéristique-de-contenu:
        (& (Type="image/tiff")
           (couleur=Binaire)
           (image-fichier-structure=TIFF-S)
           (dpi=200)
           (dpi-xyratio=200/100)
           (taille-papier=A4)
           (codage-image=MH) (MRC-mode=0)
           (ua-media=stationery) )
      --break
Type-de-contenu: image/tiff; nom="coverpage.tiff"
Codage-de-Transfert-de-contenu: base64
Description-du-contenu: Cette partie est une page de couverture
Disposition-du-contenu: pièce-jointe; nom-du-fichiere="coverpage.tiff"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAAAAAAAAAEAAAZAAAAAEAAAD+////AAAAAAAAAAD////////////////////
:
(suite des données)
:
--break

Type-de-contenu: image/tiff; nom="document.tiff"
Codage-de-Transfert-de-contenu: base64
Disposition-du-contenu: pièce-jointe; nom-du-fichier="document.tiff"

AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA
:
(suite des données)
:
--break--

4.3	Multipartie/autres données

Cet exemple illustre trois points :

o	Des informations sur les diverses parties dans un message multiparties/autres données peuvent être rendues disponibles avant le traitement des autres parties de corps. Cela peut faciliter un traitement optimum en une passe des données de multiparties/autres données.

o	Il peut y avoir d'autres solutions en ayant le même type-de-contenu MIME de base, mais qui diffèrent dans les caractéristiques de contenu su'elles utilisent.

o	Il n'y a PAS de correspondance définie entre les en-têtes "Caractéristiques-de-contenu" et les parties de corps contenues.

Mime-Version: 1.0
Type-de-contenu: multiparties/autres-données; limite="break"
Caractéristique-de-contenu: (& (Type="texte/plain") (charset=US-ASCII) )
Caractéristique-de-contenu: (& (Type="texte/html") (charset=ISO-8859-1) (couleur=limitée) )
Caractéristique-de-contenu: (& (Type="texte/html") (charset=ISO-8859-1) (couleur=binaire) )

--break
Type-de-contenu: "texte/plain";charset=US-ASCII
Caractéristique-de-contenu: (couleur=binaire)

:
(données)
:
--break
Type-de-contenu: "texte/plain";charset=US-ASCII
Caractéristique-de-contenu: (couleur=limitée)

:
(données)
:
--break

Type-de-contenu: texte/html;charset=iso-8859-1
Caractéristique-de-contenu: (couleur=binaire)

:
(données)
:
--break
Type-de-contenu: texte/html;charset=iso-8859-1
Caractéristique-de-contenu: (couleur=limitée)

:
(données)
:
--break--

4.4	Référence à des données de message externe

Mime-Version: 1.0
Type-de-contenu: message/corps-externe; type-d'accès=URL; URL="http://www.foo.com/file1.html"

Type-de-contenu: Multipartie/mixte
Caractéristique-de-contenu: (& (Type="texte/plain") (charset=US-ASCII) )
Caractéristique-de-contenu: (& (Type="image/tiff") (couleur=limitée) )

<fin>

4.5	Données compressées

Cets exemple montre comment l'en-tête "Caractéristique-de-contenu" peut être utilisé pour surmonter le problème noté dans l'enregistrement MIME pour "Application/zip" concernant les informations sur le contenu des données.

Mime-Version: 1.0
Type-de-contenu: application/zip
Caractéristique-de-contenu: (& (Type="texte/plain") (charset=US-ASCII) )
Caractéristique-de-contenu: (& (Type="image/tiff") (couleur=limitée) )
Codage-de-transfert-de-contenu: base64

:
(données)
:
<fin>

4.6	Multiparties/données en rapport

(Voir aussi la RFC 2387, "Type de contenu MIME Multipart/Related" [6])

Mime-Version: 1.0
Type-de-contenu: multipart/related; limite="limite-d'exemple";
                    type="texte/html"; début="<foo3@foo1@bar.net>"
Caractéristique-de-contenu: (& (type="texte/html") (charset=US-ASCII) )
Caractéristique-de-contenu: (type="image/gif")

--limite-d'exemple
Type-de-contenu: texte/html;charset=US-ASCII
ID-de-contenu: <foo3@foo1@bar.net>

faisant référence à une ressource dans une autre partie de corps, par exemple par une déclaration telle que :
<IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
ALT="IETF logo">

--limite-d'exemple
Localisation-du-contenu:
http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
Type-de-contenu: IMAGE/GIF
Codage-de-transfert-du-contenu: BASE64

R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...

--limite-d'exemple--

5.	Considérations pour la sécurité

Lorsque appliquée à des données MIIME formatées simples ou multiparties, une expression de caractéristiques de support donne des informations sommaires sur les données du message, qui dans de nombreux cas peuvent être déterminées par examen du contenu du message. Dans certaines circonstances, aucune considération de sécurité supplémentaire ne paraît être soulévée.

Lorsque appliquée aux autres messages composites, en particulier à un contenu de message chiffré, les expressions de caractéristiques peuvent divulguer des informations qui serait autrement indisponibles. Dans ces cas, certaines considérations de sécurité associées à la négociation de contenu du support [1], [2] peuvent être plus pertinentes.

Il est suggéré ici que les descriptions des caractéristiques des supports pourraient être utilement employées avec un contenu chiffré du message. Faisant cela, on veillera à s'assurer que l'objet du chiffrement n'est pas compromis (par exemple, le chiffrement peut être destiné à dissimuler le fait qu'un format de données d'application particulier est utilisé, fait qui peut être révélé par une application inopportune de l'en-tête "Caractéristiques-de-contenu").

Si un en-tête "Caractéristique-de-contenu" est appliqué à un objet multipartie/signé (ou bien sûr en-dehors de toute autre forme de données signées) les informations de caractéristiques de support ne sont pas protégées. Ces informations non protégées pourraient être altérées, ce qui pourrait tromper des mises en œuvre et les amener à faire des choses inappropriées avec le matériel contenu. (Mettre les informations de caractéristiques du support à l'intérieur des informations signées permettrait de surmonter cette difficulté, obligeant en contrepartie les mises en œuvre à analyser la structure interne pour les trouver.)

6.	Remerciements

Cette proposition découle de discussions avec Dan Wing. L’exemple de message de télécopie est tiré d’une proposition de Mike Ruhl. L’exemple en rapport avec multiparties est développé dans la RFC2557 [7].

L’auteur tient à remercier les personnes suivantes pour avoir proposé des commentaires qui ont conduit à des améliorations significatives : Mr Hiroshi Tamura, Ted Hardie, Maurizio Codogno, Jacob Palme, Ned Freed.

7.	Références

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

[2]	K. Holtman, A. Mutz, T. Hardie, "Procédure d'enregistrement d'étiquette de caractéristique de support", RFC2506, mars 1999. (BCP0031)

[3]	D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", RFC2234, novembre 1997. (Obsolète, voir RFC5234)

[4]	D. Crocker, "Norme pour le format des messages de texte de l'ARPA-Internet", RFC0822, STD 11, août 1982.

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

[6]	E. Levinson, "Type de contenu MIME Multipart/Related", RFC2387, août 1998. (P.S.)

[7]	J. Palme, A. Hopmann et N. Shelness, "Encapsulation MIME de documents agrégés, tels que HTML (MHTML)", RFC2557, mars 1999.

8.	Adresse de l’auteur

Graham Klyne
Content Technologies Ltd.
1220 Parkview,
Arlington Business Park
Theale
Reading, RG7 4SA
United Kingdom
téléphone : +44 118 930 1300
fax :   +44 118 930 1301
mél : GK@ACM.ORG

9.	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2000). Tous droits réservés.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soient inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définies dans les processus des normes de l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation à un objet particulier.