Groupe de travail Réseau

E. Levinson

Requête pour commentaires RFC-2387

Août 1998

Rend obsolète la RFC 2112

 

Catégorie : Proposition de Norme

 

Traduction française : O. Roquigny

mai 2008

 

Le type de contenu MIME Multipart/Related

 

Statut de ce Mémo

Ce document spécifie une proposition de norme de protocole Internet pour la communauté internet, ainsi qu'une requête de discussions et suggestions pour améliorations. Veuillez vous référer à l'édition courante de "Internet Official Protocol Standards" (STD 1) pour connaitre l'état de la norme et le statut de ce protocole. La distribution de ce mémo n'est pas limitée.

 

Notice de droits d'auteur

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

 

Résumé

Le Multipart/Related content-type procure un mécanisme commun pour représenter des objets qui sont un ensemble de parties distinctes MIME, qui sont reliés entre elles pour former un tout. Ce document définit le Multipart/Related content-type et présente des exemples de son utilisation.

 

1 Introduction

Plusieurs applications de MIME, incluant MIME-PEM, et MIME-Macintosh ainsi que d'autres propositions, nécessitent plusieurs morceaux qui prennent leur sens uniquement dans l'ensemble qu'elles composent. Cette composition d'objets, a été créée pour définir les spécificités des différents sous-types de parties distinctes pour chaque nouvel objet. En restant dans la philosophie MIME, offrant un seul mécanisme permettant de résoudre le même problème pour différents contenus, ce document décrit une seule procédure pour de tels ensemble ou objets combinés.

Le Multipart/Related content-type présente la représentation MIME d'objets combinés. L'objet est défini par un paramètre "type". Des paramètres additionnels sont fournis pour indiquer le départ d'une partie spécifique ou de la racine, et des informations auxiliaires qui pourraient être nécessaires, lors du ré assemblage ou de la création de l'objet.

Les entités Multipart/Related MIME peuvent contenir des en-têtes Content-Disposition qui fournissent des suggestions pour le stockage et l'affichage d'une partie distincte MIME. Le traitement de Multipart/Related a priorité sur Content-Disposition ; l'interaction entre eux est commentée en paragraphe 4. La responsabilité pour l'affichage ou le traitement d'entités constituant une partie Multipart/Related, est liée à l'application qui manipule les objets composés.

 

2 Informations d'enregistrement de Multipart/Related

La forme suivante est copiée de la RFC 1590, Appendice A.

To: IANA@isi.edu

Subject: Enregistrement de nouveau média type content-type/subtype

Nom de type média : Multipart

Nom de sous type média : Related

Paramètres requis : Type, un media type/subtype.

Paramètres optionnel : Start
Start-info

Considérations d'encodage : Le type Multipart content-types ne peut être encodé.

Considérations de sécurité : Dépend uniquement du type référencé.

Spécification publiée : RFC-REL (ce document).

Personne & adresse email à contacter pour un supplément d'information :
Edward Levinson
47 Clive Street
Metuchen, NJ 08840-1060
téléphone : +1 908 494 1606
mél : XIson@cnj.digex.net

 

3 Usage prévu

Le type de média Multipart/Related est prévu pour additionner des objets constitués de plusieurs parties relatives entre elles. Pour un objet Multipart/Related, un affichage correct ne peut être accomplit en affichant individuellement les différentes parties constitutives de l'ensemble. Le champ content-type de l'objet Multipart/Related est spécifié par le paramètre de type. Le paramètre "start", s'il est spécifié, pointe via un content-ID, sur la partie contenant l'objet racine. La racine par défaut, est la première partie à l'intérieur du corps de partie Multipart/Related.

Les relations entre les parties d'un objet composé, le distingue des autres types d'objets. Ces relations sont souvent représentées par des liens internes sur les objets composants référençant les autres composants. Au sein d'un simple environnement d'exploitation, les liens sont souvent des noms de fichiers, ces liens peuvent être représentés à l'intérieur d'un message MIME en utilisant les champs content-ID ou la valeur d'autres entêtes "Content-".

 

3.1 Le paramètre de type

Le paramètre de type doit être spécifié, et sa valeur est le type média MIME de la partie racine. Il permet à un "logiciel utilisateur MIME"de déterminer le content-type sans une référence à la partie enclavé. Si la valeur du paramètre type et du content-type de la partie racine sont différentes, alors le comportement du logiciel utilisateur est indéterminé.

 

3.2 Le paramètre start

Le paramètre "start", s'il est présent, est le content-ID de l'objet composé "racine". S'il n'est pas pas présent, la racine est la première partie dans l'entité Multipart/Related. La racine est l'élément que l'application va traiter en premier.

 

3.3 Le paramètre Start-Info

Une Information additionnelle peut être fournie à une application par le paramètre start-info. Il contient soit une chaîne de caractères, soit pointe, via un content-ID, vers une autre entité MIME dans le message. Une utilisation typique pourrait être d'apporter des paramètres de ligne de commande additionnels, ou une entité MIME donnant des informations supplémentaires pour traiter l'objet composé.

Les applications qui utilisent Multipart/Related doivent spécifier l'interprétation du start-info. Les logiciels utilisateurs devraient fournir les valeurs de paramètres à l'application de traitement. Les processus peuvent distinguer une référence start-info depuis un motif ou une chaîne de caractère entourée de guillemets ("), en examinant le premier caractère qui n'est pas une espace blanche (non-white-space), le caractère "<" indique une référence.

 

3.4 Syntaxe

related-param := [ ";" "start" "=" cid ]

[ ";" "start-info" "="

( cid-list / value ) ]

[ ";" "type" "=" type "/" subtype ]

; ordre indépendant

cid-list := cid cid-list

cid := msg-id ; c.f. [822]

value := token / quoted-string ; c.f. [MIME]

; value ne peut pas commencer par "<"

La valeur du paramètre doit être entourée de guillemets ("). Msg-id contient les caractères spéciaux "<", ">", "@", et peut-être d'autres caractères spéciaux. Si msg-id contient des chaînes de caractères entourées de guillemets, ces guillemets doivent être esquivés. De manière similaire, le paramètre type contient le caractère spécial "/".

 

4 Manipuler l'en-tête Content-Disposition

L'entête Content-Disposition [DISP] suggère le style de présentation pour les parties MIME. [DISP] comporte deux styles de présentation, appelés type de disposition, INLINE et ATTACHMENT. Ces styles, utilisés dans une entité multipart, permettent à l'expéditeur de donner des informations de présentation. [DISP] fournit aussi un nom de stockage optionnel (file). L'en-tête Content-Disposition peut apparaître dans une ou plusieurs parties contenues dans une entité Multipart/Related

Utiliser l'en-tête Content-Disposition avec Multipart/Related apporte des informations de présentation aux logiciels utilisateurs qui ne reconnaissent pas Multipart/Related. Ils traiteront le multipart comme Multipart/Mixed et pourraient trouver les informations de Content-Disposition utiles.

Avec Multipart/Related cependant, l'application traitant l'objet composé détermine le style de présentation pour toutes les parties inclues. Dans ce contexte l'en-tête Content-Disposition est redondant ou même trompeur. Donc, les logiciels utilisateurs qui comprennent Multipart/Related devraient ignorer le type de disposition dans une partie Multipart/Related.

Il est possible pour un logiciel utilisateur, capable de manipuler aussi bien les en-têtes Multipart/Related que Content-Disposition, de fournir à l'application invoquée, le paramètre optionnel filename de l'entête Content-Disposition de la partie MIME Multipart/Related. L'utilisation de cette information dépendra de l'application spécifique, et devrait être spécifiée lors d'une description de la manipulation de l'objet composé correspondant. Il serait idéal de faire de telles descriptions dans une RFC décrivant les objets de ce type de média.

 

5 Exemples

5.1 Application/X-FixedRecord

Le Content-Type X-FixedRecord consiste en un ou plusieurs flux d'octets, ainsi que d'une liste de dimensions de chaque enregistrement. La racine qui liste les dimensions de chaque enregistrement à l'intérieur du flux. La liste de dimensions des enregistrements, de type Application/X-FixedRecord, consiste en un ensemble d'entiers (INTEGER) au format ASCII, un par ligne. Chaque entier représente le nombre d'octets du flux d'octets de la partie MIME, constituant le prochain enregistrement.

L'example ci dessous, utilise un simple bloc de données.

Content-Type: Multipart/Related; boundary=example-1

start="<950120.aaCC@XIson.com>";

type="Application/X-FixedRecord"

start-info="-o ps"

 

--example-1

Content-Type: Application/X-FixedRecord

Content-ID: <950120.aaCC@XIson.com>

25
10
34
10
25
21
26
10
--example-1

Content-Type: Application/octet-stream
Content-Description: The fixed length records
Content-Transfer-Encoding: base64
Content-ID: <950120.aaCB@XIson.com>

T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSSBFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFkIHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYSBxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YWNrIHF1YWNrCkUgSSBFIEkgTwo=

--example-1--

 

5.2 Text/X-Okie

Le Text/X-Okie est un langage de balisage permettant l'inclusion d'images avec un texte. Une particularité de cet exemple est l'inclusion de deux images comme parties additionnelles. Elles réfèrent en interne à travers le document encapsulé, via le Content-ID de chaque partie image. L'usage du cid, comme dans cet exemple, peut être utile pour différents types d'objets composés. Cela ne fait pas partie cependant, de la spécification des parties Multipart/Related

Content-Type: Multipart/Related; boundary=example-2;
start="<950118.AEBH@XIson.com>"
type="Text/x-Okie"

--example-2

Content-Type: Text/x-Okie; charset=iso-8859-1;
declaration="<950118.AEB0@XIson.com>"
Content-ID: <950118.AEBH@XIson.com>
Content-Description: Document

{doc}
This picture was taken by an automatic camera mounted ...
{image file=cid:950118.AECB@XIson.com}
{para}
Now this is an enlargement of the area ...
{image file=cid:950118:AFDH@XIson.com}
{/doc}

--example-2

Content-Type: image/jpeg
Content-ID: <950118.AFDH@XIson.com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture A

[encoded jpeg image]

--example-2

Content-Type: image/jpeg
Content-ID: <950118.AECB@XIson.com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture B

[encoded jpeg image]

--example-2--

 

5.3 Content-Disposition

Dans l'exemple ci-dessus, chaque partie image pourrait tout aussi bien posséder un en-tête Content-Disposition. Par exemple,

--example-2
Content-Type: image/jpeg
Content-ID: <950118.AECB@XIson.com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture B
Content-Disposition: INLINE

[encoded jpeg image]

--example-2--

Les logiciels utilisateurs qui reconnaissent Multipart/Related, ignoreront le type disposition de l'en-tête Content-Disposition. Les autres logiciels utilisateurs traiteront le Multipart/Related comme Multipart/Mixed et pourront utiliser les informations de cet en-tête.

 

6 Pré-requis des logiciels utilisateurs

Les logiciels utilisateurs qui ne reconnaissent pas Multipart/Related doivent en accord avec [MIME], traiter l'entité entière comme Multipart/Mixed. Les logiciels utilisateurs MIME qui reconnaissent Multipart/Related mais sont incapables de traiter le type donné, devraient donner à l'utilisateur l'option de supprimer entièrement la partie Multipart/Related.

Les logiciels clients mail (MUA) conformes à MIME, manipulent les types média existants d'une manière simple. Pour les types de médias simples (texte, image, etc.) le corps de l'entité peut être directement passé au processus d'affichage. De manière similaire, les sous-types composites existants peuvent être réduits pour manipuler un ou plusieurs types discrets. Manipuler Multipart/Related diffère en ce que le traitement ne peut être réduit pour manipuler les entités individuelles.

Les sections suivantes décrivent l'information dont l'application de traitement a besoin.

Il est possible qu'une application spécifique "logiciel récepteur" manipule les entités à afficher avant d'invoquer le processus application actuel. L'exemple Okie ci-dessus, en est une illustration ; il pourrait avoir besoin d'un logiciel client pour traiter le document et substituer des noms de fichiers locaux à la place des noms de fichiers de l'expéditeur. Les autres applications peuvent simplement faire appel à une table montrant la correspondance entre les noms de fichiers locaux et ceux de l'expéditeur. Le logiciel récepteur prend la responsabilité de tel traitements.

 

6.1 Pré-requis de données

Les logiciels clients Mail (MUA) conformes à MIME doivent fournir à l'application :

(a) le corps de l'entité MIME et les en-têtes Content-* d'entité,

(b) les paramètres Content-Type d'en-tête du Multipart/Related, et

(c) la correspondance entre chaque nom de fichier local utilisé dans une partie MIME, les données d'en-tête de cette partie MIME, et si présent, le Content-ID de la partie MIME en question.

 

6.2 Stockage d'entités Multipart/Related

Le type de média Multipart/Related est utilisé pour des objets qui ont des liens internes entre les différentes parties du corps. Lorsque les objets sont stockés, les liens nécessitent d'être traités par l'application ou son logiciel client.

 

6.3 Récursion

MIME est une structure récursive. Il est donc possible pour une entité Multipart/Related de contenir d'autres entités Multipart/Related. Quand une entité Multipart/Related est traitée pour l'affichage ou le stockage, chaque entité Multipart/Related doit être traitée comme si elle devait être stockée.

 

6.4 Considérations de Configuration

Il est suggéré que les logiciels client mail (MUA), qui utilisent des mécanismes de configuration, se réfèrent à Multipart/Related comme à Multipart/Related/<type>, où <type> est la valeur du paramètre "type", cf. [CFG] pour un exemple.

 

7 Considérations de sécurité

Les considérations de sécurité relative à Multipart/Related sont identiques à celles sous-jacentes au content-type.

 

8 Remerciements

Cette proposition est le résultat de conversations que l'auteur a eu avec de nombreuses personnes. En particulier, Harald A. Alvestrand, James Clark, Charles Goldfarb, Gary Houston, Ned Freed, Ray Moody, et Don Stinchfield, qui ont fourni aussi bien des encouragements qu'une aide incalculable. L'auteur cependant, ainsi que ses traducteurs, assume la pleine responsabilité pour toute erreur contenue dans ce document.

 

9 Références

[822] Crocker, D., "Standard pour le format des messages texte de l'ARPA internet" - "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, août 1982.

[CID] Levinson, E., et J. Clark, "Message/External-Body Content-ID Access Type", RFC 1873, décembre 1995, Levinson, E., "Message/External-Body Content-ID Access Type", travail en cours.

[CFG] Borenstein, N., "Un mécanisme de configuration des logiciels clients mail pour le format de courrier Multimédia" - "A User Agent Configuration Mechanism For Multimedia Mail Format Information", RFC 1524, septembre 1993.

[DISP] Troost, R., et S. Dorner, "Informations de présentations communicantes dans les messages internet : L'en-tête Content-Disposition" - "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, juin 1995.

[MIME] Borenstein, N., and Freed, N., "Extensions de Mail (MIME) à contenu multiple Partie 1: Format de corps des messages internet" - "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, novembre 1996.

 

9 Adresse de l'auteur

Edward Levinson
47 Clive Street
Metuchen, NJ 08840-1060
USA

tél : +1 908 494 1606
mél : XIson@cnj.digex.com

 

10 Changements depuis la précédente version (RFC 2112)

Correction des urls cid, conformément à la RFC 2111; les parenthèses équerres ont été retirées

 

11 Note concernant le Copyright

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

Ce document et ses traductions, ainsi que les travaux dérivés qui commentent, expliquent, ou assistent à son implémentation, peuvent être modifiés, copiés, publiés, et distribués, en tout ou partie sans restriction d'aucune sorte, pourvu que la mention copyright ci-dessus ainsi que ce paragraphe soient inclus sur toutes les copies, et les travaux dérivés. Cependant, ce document lui-même ne peux être modifié en aucune manière, tel qu'en enlevant la notice de copyright ou les références à l'Internet Society ou d'autres organisations d'Internet, excepté si c'est nécessaire dans le but de développer les standards internet, dans un tel cas les procédures pour le copyright définies dans le contrôle des standards internet doivent être suivies, ou tel que requis pour le traduire dans un langage autre que l'anglais.

Les permissions limitées données ci-dessus sont perpétuelles et ne pourront pas être révoquées par l'Internet Society ou ses successeurs ou ayant-droits.

Ce document et l'information contenues ici est fournie comme une base "en l'état", et L'INTERNET SOCIETY ET L'INTERNET ENGINEERING TASK FORCE REJETENT TOUTE RESPONSABILITÉ, DIRECTE OU IMPLICITE, INCLUANT MAIS NON LIMITÉE, À UNE QUELCONQUE GARANTIE TELLE QUE L'UTILISATION DE L'INFORMATION APPORTÉE ICI N'ENFREINDRA UN DROIT OU UNE GARANTIE DE CONFORMITÉ ET D'USAGE NORMAL POUR UNE UTILISATION PARTICULIÈRE.

 

- Version anglaise de la notice de copyright :

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.