|
Groupe de travail Réseau |
R. Troost, New Century Systems |
|
Request for Comments : 2183 |
S. Dorner, QUALCOMM Incorporated |
|
RFC mise à jour : 1806 |
K. Moore, éditeur, Université du Tennessee |
|
Catégorie : En cours de normalisation |
août 1997 |
|
Traduction : Claude Brière de L’Isle |
|
Communication des informations de présentation dans les messages Internet : le champ d'en-tête Contenu-disposition
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.
Résumé
Le présent mémoire apporte un mécanisme par lequel les messages qui se conforment aux spécifications MIME [RFC2045], [RFC2046], [RFC2047], [RFC2048], [RFC2049] peuvent convoyer des informations de présentation. Il spécifie le champ d’en-tête "Contenu-Disposition", qui est facultatif et valide pour toute entité MIME ("message" ou "partie corps"). Deux valeurs sont décrites pour ce champ d’en-tête dans le présent mémoire ; une pour la présentation linéaire ordinaire de la partie corps, et une autre pour faciliter l’utilisation de la messagerie pour transférer des fichiers. On prévoit que d’autres valeurs seront définies à l’avenir, et des procédures sont établies pour étendre cet ensemble de valeurs.
Le présent document est destiné à l’extension de MIME. À ce titre, le lecteur est supposé familier avec les spécifications MIME, et la [RFC0822]. Les informations présentées ici complètent mais ne remplacent pas celles de ces documents.
Le présent document est une révision du protocole expérimental défini dans la RFC1806. Par rapport à la RFC1806, le présent document contient des mises à jour rédactionelles mineures, ajoute de nouveaux paramètres nécessaires pour prendre en charge la partie de corps Transfert de fichier, et fait référence à une spécification distincte pour le traitement des valeurs de paramètres non ASCII et/ou très longs.
MIME spécifie un format standard pour l’encapsulation de plusieurs éléments de données dans un seul message Internet. Le présent document ne traite pas de la question des styles de présentation ; il fournit un cadre pour l’échange de contenu de message, mais laisse les questions de présentation entre les seules mains des mises en œuvre d’agent d’utilisateur de messagerie (MUA, mail user agent).
Deux façons courantes de présenter les messages électroniques multi-parties sont d’une part, comme un document principal avec une liste de pièces jointes séparées, et d’autre part, comme un seul document avec les diverses parties développées (affichées) en ligne. L’affichage d’une pièce jointe est généralement interprété comme requérant une action positive de la part du receveur, alors que les composants de message en ligne sont affichés automatiquement lorsque le message est visionné. Un mécanisme est nécessaire pour permettre à l’envoyeur de transmettre cette sorte d’informations de présentation au receveur ; l’en-tête Contenu-Disposition fournit ce mécanisme, qui permet que chaque composant d’un message soit étiqueté avec une indication de sa sémantique de présentation désirée.
Étiqueter les messages de cette manière sera souvent suffisant pour les formats de base de message. Cependant, dans de nombreux cas, une approche plus puissante et plus souple sera nécessaire. La définition de telles approches sort du domaine d’application du présent mémoire ; cependant, elles peuvent bénéficier de valeurs et paramètres supplémentaires de Contenu-Disposition, qui seront définis ultérieurement.
En plus de permettre à l’envoyeur de spécifier la disposition de la présentation d’un composant de message, il est souhaitable de lui permettre d’indiquer une disposition d’archivage par défaut ; un nom de fichier (filename). Le paramètre facultatif "nom de fichier" sert à cela. De plus, les paramètres date de création (creation-date), date de modification (modification-date), et date de mecture (read-date) permettent la préservation des attributs de fichier lorsque celui-ci est transmis dans un message MIME.
Note : Les mots clés DOIT, NE DOIT PAS, EXIGE, DEVRA, NE DEVRA PAS, DEVRAIT, NE DEVRAIT PAS, RECOMMANDE, PEUT, et FACULTATIF, lorsque ils apparaissent dans ce document, sont à interpréter comme décrit dans la [RFC2119].
Contenu-Disposition est un champ d’en-tête facultatif. En son absence, le MUA peut utiliser la méthode de présentation qu’il estime convenable.
Il est souhaitable que l’ensemble des types de disposition possibles reste petit et bien défini, pour éviter une complexité inutile. Même ainsi, l’évolution de l’usage va vraisemblablement exiger la définition de types ou paramètres de disposition supplémentaires, de sorte que l’ensemble des valeurs de disposition est extensible ; voir plus loin.
Dans la notation BNF étendue de la [RFC0822], le champ d’en-tête Contenu-Disposition est défini comme suit :
disposition := "Contenu-Disposition" ":" type-de-disposition *(";" paramètre-disposition)
type-de-disposition := "en ligne" / "pièce jointe" / jeton-d’extension ; les valeurs ne sont pas sensibles à la casse
paramètre-disposition := paramètre-nom-de-fichier / paramètre-date-de-création / paramètre-date-de-modification / paramètre-date-de lecture / paramètre-taille / paramètre
paramètre-nom-de-fichier := "nom-de-fichier" "=" valeur
paramètre-date-de-création := "date-de-création" "=" date-heure-entre-guillemets
paramètre-date-de-modification := "modification-date" "=" date-heure-entre-guillemets
paramètre-date-de lecture := "date-de lecture" "=" date-heure-entre-guillemets
paramètre-taille := "taille" "=" 1*CHIFFRE
date-heure-entre-guillemets := chaîne-entre-guillemets
; le contenu DOIT être une "date-heure" de la RFC0822
; les zones horaires numériques (+HHMM ou -HHMM) DOIVENT être utilisées
Note sur les longueurs de valeur de paramètre : Une valeur de paramètre courte (longueur ≤ 78 caractères) contenant seulement des caractères non "tspecials" DEVRAIT être représentée par un seul jeton. Une valeur de paramètre courte contenant seulement des caractères ASCII, mais comportant des caractères "tspecials" DEVRAIT être représentée par une "chaîne-entre-guillemets". Les valeurs de paramètre plus longues que 78 caractères, ou avec des caractères non ASCII DOIVENT être codées comme spécifié dans la [RFC2184].
"jeton d’extension", "paramètre", "tspecials" et "valeur" sont définis conformément à la [RFC2045] (qui se refère à la [RFC0822] pour la définition de certains de ces jetons). "chaîne-entre-guillemets" et "CHIFFRE" sont définis dans la [RFC0822].
Une partie de corps devrait être marquée "en ligne" si elle est destinée à être affichée automatiquement avec le message. Les parties de corps en ligne devraient être présentées dans l’ordre dans lequel elles arrivent, sous réserve d’une sémantique normale des messages multi parties.
Des parties de corps peuvent être appelées "pièces jointe" pour indiquer qu’elles sont séparées du corps principal du message électronique, et que leur affichage ne devrait pas être automatique, mais subordonné à quelque action ultérieure de l’usager. Le MUA peut à la place présenter à l’utilisateur d’un terminal à représentation exacte un icone de la pièce jointe, ou, sur des terminaux à caractères, une liste des pièces jointes à partir de laquelle l’usager peut faire une sélection de celles qu’il veut visionner ou mémoriser.
L’envoyeur peut vouloir suggérer un nom de fichier à utiliser si l’entité est détachée et mémorisée dans un fichier séparé. Si le MUA receveur écrit l’entité dans un fichier, le nom de fichier suggéré devrait être utilisé comme base du nom de fichier réel, lorsque c’est possible.
Il est important que le MUA receveur n’utilise pas aveuglément le nom de fichier suggéré. Le nom de fichier suggéré DEVRAIT être vérifié (et éventuellement changé) pour voir si il se conforme aux conventions locales des systèmes de fichier, si il ne se superpose pas à un fichier existant, et si il ne présente pas de problème de sécurité (voir ci-dessous les considérations pour la sécurité).
Le MUA receveur NE DEVRAIT PAS suivre d’informations de chemin de répertoire qui pourraient sembler présentes dans le paramètre nom de fichier. Le nom de fichier devrait être traité seulement comme un composant terminal. Des spécification portables de chemin de répertoire pourraient éventuellement être faites à l’avenir via un paramètre Contenu-Disposition séparé, mais aucune disposition n’est prise pour cela dans le présent projet.
La grammaire actuelle de la [RFC2045] restreint les valeurs de paramètres (et donc des noms de fichiers de Contenu-Disposition) à l’US-ASCII. On reconnaît qu’il est très souhaitable de permettre des jeux de caractères arbitraires dans les noms de fichier, mais la définition des mécanismes nécessaires sort du domaine d’application du présent document. Il est prévu d’amender un jour la spécification de la “valeur” de base de la [RFC1521] pour permettre l’utilisation de caractères non US-ASCII, et qu’à ce moment le même mécanisme devrait être utilisé dans le paramètre Nom de fichier de Contenu-Disposition.
Au delà des limitations à l’US-ASCII, le MUA envoyeur peut souhaiter garder présentes à l’esprit les limitations des systèmes de fichiers courants. Beaucoup ont des restrictions sévères en matière de longueur et de jeu de caractères. Les courts noms de fichier alphanumériques vont vraisemblablement moins exiger de modifications de la part du système receveur.
La présence du paramètre Nom de fichier ne force pas une mise en œuvre à écrire l’entité dans un fichier séparé. Il est parfaitement acceptable qu’une mise en œuvre laisse l’entité faire normalement partie du flux de messagerie sauf si l’utilisateur demande qu’il en soit autrement. Par conséquent, le paramètre peut être utilisé sur toute entité MIME, même celles qui sont "en ligne". Celles-ci ne seront normalement pas écrites dans les fichiers, mais le paramètre pourrait être utilisé pour donner un nom de fichier si l’usager receveur devait choisir d’écrire la partie dans un fichier.
Le paramètre Date de création PEUT être utilisé pour indiquer la date à laquelle a été créé le fichier. Si ce paramètre est inclus, la valeur du paramètre DOIT être une chaîne entre guillemets qui contient une représentation de la date de création du fichier dans le format "date et heure" de la [RFC0822].
Les mises en œuvre UNIX et POSIX sont averties que l’attribut de fichier "st_ctime" de la structure "stat" n’est pas l’heure de création du fichier ; il n’est donc pas approprié comme source de valeur du paramètre Date de création.
Le paramètre Date de modification PEUT être utilisé pour indiquer la date à laquelle le fichier a été modifié pour la dernière fois. Si le paramètre Date de modification est inclus, la valeur du paramètre DOIT être une chaîne entre guillemets qui contient une représentation de la date de la dernière modification du fichier dans le format "date et heure" de la [RFC0822].
Le paramètre Date de lecture PEUT être utilisé pour indiquer la date à laquelle le fichier a été lu pour la dernière fois. Si le paramètre Date de lecture est inclus, la valeur du paramètre DOIT être une chaîne entre guillemets qui contient une représentation de la date de la dernière lecture du fichier dans le format "date-heure" de la [RFC0822].
Le paramètre Taille indique une taille approximative du fichier en octets. Il peut être utilisé, par exemple, pour préallouer de l’espace avant d’essayer de mémoriser le fichier, ou pour déterminer si il y a suffisamment de place.
Dans le cas probable où de nouveaux paramètres ou types de disposition seraient nécessaires, ils devraient être enregistrés auprès de l’Autorité d’allocation des numéros de l’Internet (IANA), de la manière spécifiée à la Section 9 du présent mémoire.
Une fois que de nouveaux types et paramètres de disposition sont définis, il y a bien sûr la probabilité que des mises en œuvre voient des types et paramètres de disposition qu’ils ne comprennent pas. De plus, comme les jetons x sont admis, les mises en œuvre peuvent aussi voir des types et paramètres de disposition entièrement non enregistrés.
Les paramètres non reconnus devraient être ignorés. Les types de disposition non reconnus devraient être traités comme "pièce jointe". Le choix de "pièce jointe" pour les types non reconnus est fait parce qu’un envoyeur qui se donne la peine de produire un en-tête Contenu-Disposition avec un nouveau type de disposition vise vraisemblablement à quelque chose de plus élaboré qu’une présentation en ligne.
Sauf notation contraire dans la définition d’un paramètre, les paramètres Contenu-Disposition sont valides pour toutes les dispositions. (À la différence des paramètres "type de contenu" de MIME, qui sont définis selon le type de contenu.) Donc, par exemple, le paramètre "nom de fichier" signifie toujours le nom du fichier dans lequel la partie devrait être écrite, même si la disposition elle-même n’est pas reconnue.
Si un en-tête Contenu-Disposition est utilisé sur une partie de corps multipartie, il s’applique à la multipartie prise comme un tout, et non aux sous-parties individuelles. Les types de disposition des sous-parties n’ont pas besoin d’être consultés jusqu’à ce que la multipartie elle-même soit présentée. Lorsque la multipartie est affichée, les dispositions des sous parties devraient alors être respectées.
Si la disposition "en ligne" est utilisée, la multipartie devrait être affichée normalement ; cependant, une sous partie "pièce jointe"`devrait exiger une action de la part de l’usager pour s’afficher.
Si la disposition "pièce jointe" est utilisée, la présentation de la multipartie ne devrait pas se poursuivre sans une action explicite de l’usager. Une fois que l’usager a choisi d’afficher la multipartie, les dispositions individuelles de sous parties devraient être consultées pour déterminer comment présenter les sous-parties.
Il est permis d’utiliser Contenu-Disposition sur le corps principal d’un messageselon la [RFC0822].
Voici un exemple d’une partie de corps qui contient une image JPEG qui est destinée à être vue immédiatement par le receveur :
Type de contenu : image/jpeg
Disposition du contenu : en ligne
Description du contenu : juste une petite photo de moi
<jpeg data>
La partie de corps suivante contient une image JPEG qui ne devrait être affichée à l’usager que s’il le demande. Si le JPEG est écrit dans un fichier, celui-ci devrait être nommé "genome.jpg". L’usager receveur pourrait aussi choisir d’établir la date de dernière modification du fichier mémorisé comme date dans le paramètre Date de modification :
Type de contenu : image/jpeg
Contenu-Disposition : pièce jointe ; nom du fichier=genome.jpeg;
Date de modification = "mercredi 12 février1997 16:29:51 -0500";
Description du contenu : carte complète du génome humain
<jpeg data>
Voici un exemple d’utilisation de la disposition "pièce jointe" avec une partie de corps multipartie. L’usager devrait voir immédiatement text-part-1 , puis effectuer une certaine action pour voir multipart-2. Après avoir effectué l’action pour voir multipart-2, l’usager va voir directement text-part-2, et il va lui être demandé d’effectuer une action pour voir jpeg-1. Les sous-parties sont mises en retrait pour améliorer la lisibilité ; elles ne seraient pas en retrait dans un message réel.
Content-Type: multipart/mixed; boundary=outer
Content-Description: multipart-1
--outer
Content-Type: text/plain
Content-Disposition: inline
Content-Description: text-part-1
Du texte vient se placer ici
--outer
Content-Type: multipart/mixed; boundary=inner
Content-Disposition: attachment
Content-Description: multipart-2
--inner
Content-Type: text/plain
Content-Disposition: inline
Content-Description: text-part-2
Du texte vient encore se placer ici.
--inner
Content-Type: image/jpeg
Content-Disposition: attachment
Content-Description: jpeg-1
<jpeg data>
--inner--
--outer--
Contenu-Disposition peut prendre une des deux valeurs, "en ligne" ou "pièce jointe". L’indication "en ligne" dit que l’entité devrait être affichée immédiatement à l’usager, alors que "pièce jointe" signifie que l’usager devrait accomplir une action supplémentaire pour voir l’entité.
Le paramètre "nom de fichier" peut être utilisé pour suggérer un nom de fichier pour mémoriser la partie corps du message, si l’usager souhaite la mémoriser dans un fichier externe.
Il y a des questions de sécurité qui sont impliquées chaque fois que les usagers échangent des données. Bien qu’elles ne doivent pas être minimisées, le présent mémoire ne change en rien le statu quo à cet égard, sauf dans un cas.
Dans la mesure où le présent mémoire donne un moyen pour que l’envoyeur suggère un nom de fichier, un MUA receveur doit prendre garde à ce que le nom de fichier suggéré par l’envoyeur ne représente pas un danger. En prenant l’exemple de UNIX, certains dangers pourraient être :
+ de créer des fichiers de démarrage (par exemple, ".login"),
+ de créer ou substituer des fichiers système (par exemple, "/etc/passwd"),
+ de remplacer n’importe quel fichier existant,
+ de placer des fichiers exécutables dans n’importe quel chemin de recherche de commande (par exemple, "~/bin/more"),
+ d’envoyer le fichier dans un "tuyau" (par exemple, "| sh").
En général, le MUA receveur ne devrait pas nommer ou placer le fichier de façon telle qu’il puisse être interprété ou exécuté sans que l’usager initie explicitement l’action.
Il est très important de noter que cette liste n’est pas exhaustive et n’est destinée qu’à donner un petit ensemble d’exemples. Les utilisateurs doivent être en alerte sur les dangers qui pèsent sur leurs systèmes cibles.
[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.
[RFC2184] N. Freed, K. Moore, "Extensions MIME Valeur de paramètre et Mot codé : jeux de caractères, langages, et continuations", août 1997. (Obsolète, voir RFC2231) (P.S.)
[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.)
[RFC2047] K. Moore, "MIME (Extensions de messagerie Internet multi-objets) Partie trois : extensions d'en-tête de message pour texte non ASCII", novembre 1996. (MàJ par RFC2184, RFC2231) (D.S.)
[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)
[RFC2049] N. Freed, N. Borenstein, "Extensions multi-objets de la messagerie Internet (MIME) Partie cinq : critères de conformité et exemples", novembre 1996. (Remplace RFC1521, RFC1522, RFC1590) (D.S.)
[RFC0822] D. Crocker, "Norme pour le format des messages de texte de l'ARPA-Internet", STD 11, août 1982.
Nous remercions les personnes suivantes de l’aide qu’elles ont apportée durant la préparation de ce projet : Nathaniel Borenstein, Ned Freed, Keith Moore, Dave Crocker et Dan Pritchett
C’est à l’éditeur de la présente version de ce document que doivent être reprochés tous les changements depuis la RFC 1806:
Keith Moore
Department of Computer Science
University of Tennessee, Knoxville
107 Ayres Hall
Knoxville TN 37996-1301
USA
téléphone : +1 (423) 974-5067
Fax : +1 (423) 974-8296
mél : moore@cs.utk.edu
Les auteurs de la RFC1806 sont :
|
Rens Troost |
Steve Dorner |
|
New Century Systems |
QUALCOMM Incorporated |
|
324 East 41st Street #804 |
6455 Lusk Boulevard |
|
New York, NY, 10017 USA |
San Diego, CA 92121 |
|
téléphone : +1 (212) 557-2050 |
USA |
|
Fax : +1 (212) 557-2049 |
mél : sdorner@qualcomm.com |
|
mél : rens@century.com |
|
De nouvelles valeurs de Contenu-Disposition (au delà de "inline" et "attachment") ne peuvent être définies que par des document Internet en cours de normalisation, ou par des documents expérimentaux approuvés par le groupe de pilotage de l’ingénierie de l’Internet (IESG, Internet Engineering Steering Group).
De nouveaux paramètres de contenu-disposition peuvent être enregistrés en fournissant les informations du modèle suivant et en l’envoyant pas messagerie électronique à IANA@IANA.ORG :
To: IANA@IANA.ORG
Subject: Registration of new Content-Disposition parameter
Nom du paramètre Contenu-Disposition :
Valeurs disponibles pour ce paramètre :
(Si me paramètre ne peut admettre qu’un petit nombre de valeurs, faire la liste de chacune de ces valeurs. Autrement, décrire les valeurs que le paramètre oeut admettre.)
Description :
(Quel est l’objet de ce paramètre et comment est-il utilisé ?)
Les changements suivants ont été faits depuis la version précédente de ce document, publiée dans la RFC1806 comme protocole expérimental :
+ Mise à jour des références aux documents MIME. Dans certains cas, cela implique de substituer une référence à une des RFC MIME actuelles par une référence à la RFC1521 ; dans d’autre cas, une référence à la RFC1521 a simplement été remplacée par le mot "MIME".
+ Ajout d’une section sur les procédures d’enregistrement, car aucune des procédures de la RFC2048 ne semblait appropriée.
+ Ajout de nouveaux types de paramètres : creation-date, modification-date, read-date, et size.
+ Incorporation d’une référence à draft-freed-pvcsc-* pour le codage de valeurs de paramètres longs ou non ASCII.
+ Ajout de référence à la RFC2119 pour définir les mots clés DOIT, DEVRAIT, etc..