Groupe de travail Réseau	E. Levinson
Request for Comments : 2392 	août 1998
RFC rendue obsolète : 2111	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Localisateur de ressource uniforme d'identifiant de contenu et d'identifiant de message

Statut de ce mémoire
Le présent document spécifie un protocole en cours de normalisation de l’Internet 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 (1998). Tous droits réservés.

Résumé
Les schémas de localisateur de ressource uniforme (URL, Uniform Resource Locator) "cid:" et "mid:" permettent la référence à des messages et aux parties de corps de messages. Par exemple, dans un seul message multi parties, une partie de corps HTML pourrait inclure des références incorporées aux autres parties du même message.

Changements par rapport à la RFC 2111
On a précisé l'exemple de la page 3 sur la conversion des URL cid en identifiants de contenu. L'exemple utilise maintenant un URL cid au lieu d'un mid.
On a corrigé les exemples de messages pour avoir la forme correcte d'identifiant de contenu ; ils utilisent maintenant des crochets angulaires. Ajout d'un en-tête Message-ID au second exemple.

 	1.	Introduction

L'utilisation de la [RFC2045] dans la messagerie électronique pour porter des pages de la Toile et leurs images associées exige qu'un schéma d'URL permette au HTML de se référer aux images ou autres données incluses dans le message. Le localisateur de ressource uniforme Content-ID (identifiant de contenu) "cid:", sert à cela.

De la même façon, les lecteurs de "Net News" utilisent des identifiants de message pour relier les messages en relations. L'URL "Message-ID" fournit un schéma, "mid:" (identifiant de message) pour se référer à de tels messages comme à une "resource".

Les schémas d'URL "mid" et "cid" fournissent des identifiants pour les messages et leurs parties de corps. Le schéma "mid" utilise (une partie de) l'identifiant de message d'un message électronique pour se référer à un message spécifique. Le schéma "cid" se réfère à une partie de corps spécifique d'un message ; son utilisation est généralement limitée aux références aux autres parties de corps dans le même message que la partie de corps référante. Le schéma "mid" peut aussi se référer à une partie de corps spécifique au sein d'un message désigné, en incluant l'adresse de l'identifiant de contenu.

Note sur la terminologie : les termes "partie de corps" et "entité MIME" sont utilisées de façon interchangeable. Ils se réfèrent aux en-têtes et corps d'un message MIME, soit du message lui-même, soit des parties de corps contenues dans un message multi parties.

 	2.	Schémas d'URL MID et CID

La [RFC1738] réserve les schémas "mid" et "cid" respectivement à l'identifiant de message et à l'identifiant de contenu. Le présent mémoire définit la syntaxe de ces URL. Parce qu'ils utilisent les mêmes éléments syntaxiques, ils sont présentés ensemble.

Les URL prennent la forme

content-id = url-addr-spec

message-id = url-addr-spec

url-addr-spec = addr-spec 	; codage d'URL de l'addr-spec de la RFC 822 

cid-url = "cid" ":" content-id

mid-url = "mid" ":" message-id [ "/" content-id ]

Notes : dans la messagerie électronique de l'Internet, le champ addr-spec dans un en-tête Content-ID [RFC2045] ou Message-ID [RFC0822] est enclos entre des crochets angulaires (<>). Comme addr-spec dans un Message-ID ou Content-ID pourrait contenir des caractères non autorisés dans un URL, de tels caractères (incluant "/", qui est réservé dans le schéma "mid") doivent être codés en hexadécimal en utilisant le mécanisme d'échappement %hh décrit dans la [RFC1738].

Un URL "mid" avec seulement un "message-id" se réfère à un message entier. Avec l'ajout de "content-id", il se réfère à une partie de corps au sein d'un message, comme le fait un URL "cid". L'identifiant de contenu d'une partie de corps MIME doit être unique au monde. Cependant, dans de nombreux systèmes qui mémorisent des messages, les parties de corps ne sont pas indexées indépendamment de leur contexte (message). La forme longue d'URL "mid" a été conçue pour fournir le contexte nécessaire pour assurer l'interopérabilité avec de tels systèmes.

Une mise en œuvre qui se conforme à la présente spécification doit prendre en charge la forme longue d'URL "mid" (message-id/content-id). Les mises en œuvre conformes peuvent choisir, mais ne sont pas obligées, de tirer parti de l'unicité des identifiants de contenu et interpréter un URL "cid" comme se référant à toute partie de corps au sein de la mémorisation de message.

Dans des circonstances limitées (par exemple, au sein de multipart/alternate) un seul message peut contenir plusieurs parties de corps qui ont le même identifiant de contenu. Cela se produit, par exemple, quand des données identiques peuvent être accédées par différentes méthodes. Dans ce cas, les mises en œuvre conformes doivent utiliser les règles de l'entité MIME contenante (par exemple, multipart/alternate) pour choisir la partie de corps à laquelle se réfère l'identifiant de contenu.

Un URL "cid" est converti en l'en-tête de message "identifiant de contenu" correspondant [RFC2045] en retirant le préfixe "cid:", en convertissant le caractère codé avec % en son caractère US-ASCII équivalent, et en enclosant les parties restantes entre une paire de crochets angulaires "<" et ">".

Par exemple, "cid:foo4%25foo1@bar.net" correspond à "Content-ID: <foo4%foo1@bar.net>"

Inverser le processus et convertir les caractères spéciaux d'URL en leurs codage en pourcentage (%) produit le cid original.

Un URL "mid" est converti en identifiant de message ou une paire Message-ID/Content-ID de façon similaire.

Les deux message-id et content-id doivent être uniques au monde. C'est-à-dire que deux messages différents ne vont jamais avoir la même spécification d'adresse d'identifiant de message (Message-ID addr-spec) ; deux parties de corps différentes ne vont jamais avoir la même spécification d'adresse d'identifiant de contenu (Content-ID addr-spec). Une technique courante utilisée par de nombreux systèmes de messagerie est d'utiliser un horodatage avec le nom de domaine de l'hôte local, par exemple, 950124.162336@XIson.com.

Quelques exemples

Le message suivant contient une partie de corps HTML qui se réfère à une image contenue dans une autre partie de corps. Les deux parties de corps sont contenues dans une entité MIME Multipart/Related. L'étiquette HTML IMG contient un cidurl qui pointe sur l'image :

From: foo1@bar.net
To: foo2@bar.net
Subject: Un simple exemple
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example-1"; type=Text/HTML

--boundary-example-1
Content-Type: Text/HTML; charset=US-ASCII

sur l'autre partie de corps, par exemple avec une déclaration comme :
<IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo">

--boundary-example-1
Content-ID: <foo4*foo1@bar.net>
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...

--boundary-example-1--

Le message suivant pointe sur un autre message (heureusement toujours dans la mémoire de messages du receveur).

From: bar@none.com
To: phooey@all.com
Subject: Voici comment le faire
Message-ID: <970701.32784@VIers.none.com>
Content-type: text/html; charset=usascii

<Une HREF= "mid:960830.1639@XIson.com/partA.960830.1639@XIson.com"> au message précédent </A>, montre comment l'approche que tu proposes peut être utilisée pour accomplir ...

 	3.	Considérations sur la sécurité

Les URL définis ici fournissent un mécanisme d'adressage ou de référence. Les valeurs de ces URL n'en divulgent pas plus sur l'environnement de leurs créateurs que les valeurs correspondantes de Message-ID et Content-ID. Lorsque on se soucie de la divulgation de l'origine d'un message utilisant les URL mid et cid, on doit prendre des précautions pour s'assurer que des informations confidentielles ne sont pas divulguées. Ces précautions devraient déjà être en place pour traiter l'utilisation existante de Message-ID et Content-ID dans la messagerie.

 	4.	Références

[RFC0822]	D. Crocker, "Norme pour le format des messages de texte de l'ARPA-Internet", STD 11, août 1982. (Obsolète, voir RFC5322)

[RFC1738]	T. Berners-Lee et autres, "Localisateurs uniformes de ressource (URL)", décembre 1994. (P.S., Obsolète, voir les RFC4248 et 4266 ; MàJ par RFC8089)

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

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

 	5.	Remerciements

Le concept original des URL "mid" et "cid" faisait partie de la vision de Tim Berners-Lee de la Toile mondiale. Les idées et la conception du présent document ont largement bénéficié des discussions avec Harald Alvestrand, Dan Connolly, Roy Fielding, Larry Masinter, Jacob Palme, et d'autres dans le groupe de travail MHTML.

 	6.	Adresse de l'auteur

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

téléphone : +1 908 549 3716
mél : XIson@cnj.digex.net 

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

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

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.