Encapsulation MIME de documents agrégés, tels que HTML (MHTML)

Statut du présent Mémo

La présente RFC spécifie un protocole de normalisation pour la communauté Internet et appelle à des discussions et suggestions pour son amélioration. Prière de se reporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémo n’est soumise à aucune restriction.

Déclaration de Copyright

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

Résumé

HTML [RFC1866] définit un moyen puissant pour spécifier les documents multi supports. Ces documents multi supports consistent en une ressource racine en texte/html (un objet) et d'autres ressources subsidiaires (des objets image, séquence vidéo, appliquette, etc.) référencés par des identifiants de ressource uniformes (URI, Uniform Resource Identifier) au sein d'une ressource racine texte/html. Lorsque un document multi supports HTML est restitué par un navigateur, chacune de ses ressources composantes est restituée individuellement en temps réel à partir d'une localisation, et en utilisant un protocole, spécifié par chaque URI.

Afin de transférer un document multi supports HTML complet dans un seul message électronique, il est nécessaire :

a) d'agréger une ressource racine texte/html et toutes les ressources subsidiaires qu'elle référence en une seule structure de message composite, et

b) de définir le moyen par lequel les URI dans la racine texte/html peuvent se référer aux ressources subsidiaires au sein de cette structure de message composite.

Le présent document

a) définit l'utilisation d'une structure MIME multipart/related pour agréger une ressource racine texte/html et les ressources subsidiaires qu'elle référence, et

b) spécifie un en-tête de contenu MIME (Localisation-de-contenu) qui permet aux URI dans une partie de corps de racine texte/html multipart/related de faire référence aux ressources subsidiaires dans d'autres parties de corps de la même structure multipart/related.

Bien que conçu initialement pour prendre en charge le transfert par messagerie électronique de documents HTML multi-supports multi-ressource complets, ces conventions peuvent aussi être employées pour des ressources restituées par d'autres protocoles de transfert tels que HTTP et FTP pour rendre un document HTML multi-supports multi-ressources complet en un seul transfert ou pour mémorisation et archivage de documents HTML complets.

Les différences entre ce document et la version précédente de cette norme, qui a été publiée comme RFC2110, sont résumées à la section 12.

Table des Matières

1. Introduction

2. Terminologie 3

2.1 Terminologie des exigences de conformité 3

2.2 Autre terminologie

3. Vue d'ensemble du protocole

4. En-tête de contenu MIME Localisation-du-contenu

4.1 En-têtes de contenu MIME

4.2 En-tête Content-Location

4.3 Les URI des agrégats MHTML

4.4 Codage et décodage des URI dans les champs d'en-tête MIME

5. URI de base pour la résolution des URI relatifs

6. Envoi de documents sans objet relié

7. Usage du type de contenu "multipart/related" 7

8. Usage de liens avec d'autres parties de corps

8.1 Principe général

8.2 Résolution des URI dans des parties de corps text/html

8.3 Usage de l'en-tête Content-ID et des URL CID

9. Exemples

9.1 Exemple de corps HTML sans objet lié inclus

9.2 Exemple avec un URI absolu sur une image GIF incorporée

9.3 Exemple avec des URI relatifs à des images GIF incorporées

9.4 Exemple avec un URI relatif et pas de BASE disponible

9.5 Exemple d'utilisation de CID d'URL et d'en-tête Content-ID pour une image GIF incorporée

9.6 Exemple de références permises et interdites entre parties de corps incorporées

10. Problèmes de codage de caractères et problèmes de bout en bout

11. Considérations pour la sécurité

11.1 Considérations pour la sécurité sans rapport avec la mise en antémémoire

11.2 Considérations de sécurité en rapport avec la mise en antémémoire

12. Différences par rapport à la précédente version de cette norme dans la RFC2110

13. Remerciements

14. Références

15. Adresse des auteurs

16. Déclaration de droits de reproduction

1. Introduction

Il y a un certain nombre de formats de document (Langage de balisage Hypertexte [RFC1866], Langage de balisage étendu [XML], Format de document portable [PDF] et Langage de balisage de réalité virtuelle [VRML]) qui spécifient des documents consistant en une ressource racine et un certain nombre de ressources subsidiaires distinctes référencées par des URI au sein de cette ressource racine. Il y a un besoin évident de la capacité à envoyer de tels documents multi-ressources dans des messages électroniques [RFC0821], [RFC0822].

La norme définie dans le présent document spécifie comment agréger de tels documents multi-ressources dans des messages en format MIME [RFC2045] à [RFC2049] précisément dans ce but.

Bien que la présente spécification ait été développée pour satisfaire aux exigences spécifiques d'agrégation des documents multi-ressources HTML, elle peut aussi s'appliquer aux autres représentations de documents multi-ressources liés par des URI. Lorsque c'est le cas, il n'est pas exigé que les mises en œuvre qui revendiquent la conformité à la présente norme soient capables de traiter des représentations de documents liés par des URI autres que ceux dont la racine est HTML.

Cette agrégation en un seul message d'une ressource racine et de ressources subsidiaires auxquelles elle fait référence peut aussi être applicable aux ressources restituées par d'autres protocoles tels que HTTP ou FTP, ou à l'archivage de pages complètes de la Toile comme elles apparaissaient à un moment particulier dans le temps.

Une RFC d'information sera publiée en supplément à la présente norme. Cette RFC d'information exposera la méthode et certains problèmes de mise en œuvre. Les développeurs sont vivement encouragés à lire cette RFC d'information lors du développement des mises en œuvre de la présente norme. Vous la trouverez à l'URL http://www.dsv.su.se/~jpalme/ietf/mhtml.html.

La présente norme spécifie que les parties de corps à référencer peuvent être identifiées par un Content-ID (contenant un identifiant de message) ou par un Content-Location (contenant un URL arbitraire). La raison pour laquelle la présente norme ne recommande pas seulement l'utilisation des Content-ID est qu'il devrait être possible de transmettre des pages existantes de la Toile via la messagerie électronique sans avoir à réécrire le texte source de la page de la Toile. Une telle réécriture présente plusieurs inconvénients, dont l'un est que les sommes de contrôle de sécurité vont probablement être invalidées.

2. Terminologie

2.1 Terminologie des exigences de conformité

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].

Une mise en œuvre n'est pas conforme si elle échoue à satisfaire une ou plusieurs exigences marquées DOIT pour les protocoles qu'elle met en œuvre. Une mise en œuvre qui satisfait à toutes les exigences marquées DOIT et DEVRAIT pour ses protocoles est dite "inconditionnellement conforme" ; celle qui satisfait à toutes les exigences marquées DOIT mais pas toutes celles marquées DEVRAIT pour ses protocoles est dite "conditionnellement conforme."

2.2 Autre terminologie

La plupart des termes utilisés dans ce document sont définis dans d'autres RFC.

URI absolu, Voir Localisateur de ressource uniforme relatif [RFC1808].

CID Voir Identifiant de contenu de message/corps externe[RFC2045].

Content-Base Cet en-tête était spécifié dans la RFC2110, mais a été retiré dans cette nouvelle version de MHTML.

Content-ID Voir Identifiant de contenu de message/corps externe [RFC2045].

Content-Location En-tête de message MIME ou de partie de contenu avec un URI du message MIME ou du corps de partie de contenu, défini au paragraphe 4.2 ci-dessous.

Codage-de-transfert-de-contenu Conversion d'un texte en octets de 7 bits, spécifié à la section 6 de la [RFC2045].

CR (retour chariot) Voir la [RFC0822].

CRLF (retour chariot saut à la ligne) Voir la [RFC0822].

Texte affiché Le texte montré à l'usager qui lit un document avec un navigateur de la Toile. Cela peut être différent du balisage HTML, voir la définition du balisage HTML ci-dessous.

En-tête Champ dans un message ou en-tête de contenu qui spécifie la valeur d'un attribut.

En tête Partie d'un message ou contenu avant le premier CRLFCRLF, qui contient des champs formatés avec des attributs du message ou du contenu.

HTML Voir la spécification HTML 2 [RFC1866].

Objet HTML agrégé Objet HTML avec certains des objets (ou tous les objets) avec lesquels il a des liens hypertextes, directement ou indirectement.

Balisage HTML Fichier contenant des codages HTML comme spécifié dans [HTML] qui peut être différent du texte affiché que voit la personne qui utilise le navigateur. Par exemple, le balisage HTML peut contenir "&lt;" là où le texte affiché contient le caractère "<".

LF (saut à la ligne) Voir la [RFC0822].

MIC (Message Integrity Code) Code d'intégrité de message, codes utilisés pour vérifier qu'un message n'a pas été modifié.

MIME Voir les spécifications MIME, [RFC2045] à [RFC2049].

MUA (Messaging User Agent) Agent d'utilisateur de messagerie.

PDF Format de document portable, voir [PDF].

URI relatif Voir les [RFC1866] et [RFC1808].

URI, absolu et relatif Voir la [RFC1866].

URL Voir la [RFC1738].

URL, relatif Voir Localisateur uniforme de ressource relative [RFC1808].

VRML Voir [VRML] (Virtual Reality Modeling Language, langage de modélisation de réalité virtuelle).

3. Vue d'ensemble du protocole

Un document agrégé est un message codé selon MIME qui contient une ressource racine (objet) ainsi que d'autres ressources qui lui sont liées via des URI. Il peut être demandé à ces autres ressources d'afficher un document multi-supports sur la base de la ressource racine (images en ligne, feuilles de style, appliquettes, etc.) ou d'être les ressources racines d'autres documents muti-supports. Il est important de garder présent à l'esprit que les documents agrégés doivent satisfaire aux différents besoins de plusieurs catégories d'audience.

Les agents d'envoi de messagerie peuvent envoyer des documents agrégés comme un codage de messagerie électronique quotidienne normale. Les agents d'envoi de messagerie peuvent aussi envoyer des documents agrégés lorsque un usager souhaite envoyer de la Toile un document particulier à quelqu'un d'autre. Finalement, les agents d'envoi de messagerie peuvent envoyer des documents agrégés en tant que répondeurs automatiques, donnant accès à des ressources de la Toile mondiale à des clients qui ne sont pas connectés à IP. Il peut aussi y avoir, avec d'autres protocoles tels que HTTP ou FTP, un besoin de restituer des documents agrégés. Les agents receveurs ont eux aussi des besoins qui diffèrent. Certains peuvent être capables de recevoir un document agrégé et de l'afficher juste comme tout autre type de contenu de texte serait affiché. D'autres peuvent devoir passer ce document agrégé à un programme de navigation, et des dispositions doivent être prises pour rendre cela possible.

Finalement surviennent plusieurs autres contraintes du problème. Il est important qu'il soit possible qu'un document soit signé et soit pour cela transmis et affiché sans casser la somme de contrôle d'intégrité de message (MIC) qui fait partie de la signature.

4. En-tête de contenu MIME Localisation-du-contenu

4.1 En-têtes de contenu MIME

Pour résoudre les URI de références à des ressources dans d'autres parties de corps, on définit un en-tête de contenu MIME, Localisation-du-contenu (Content-Location). Cet en-tête peut survenir en tête de tout message ou contenu.

La syntaxe de cet en-tête est, en utilisant les outils de définition de syntaxe de la [RFC2234] :

quoted-pair = ("\" text) ; (paire entre guillemets)

text = %d1-9 / %d11-12 / %d14-127 ; caractères excluant CR et LF

WSP = SP / HTAB ; caractères d'espace (espace blanche, tabulation)

FWS = ([*WSP CRLF] 1*WSP) ; espace de saut à la ligne (folding white space)

ctext = NO-WS-CTL / %d33-39 / %d42-91 / ; Non-white-space contrôle le reste des caractères

%d93-127 ; ; US-ASCII, "(", ")", ou "\" non inclus.

comment = "(" *([FWS] (ctext / quoted-pair / comment)) [FWS] ")" ; (commentaire)

CFWS = *([FWS] comment) (([FWS] comment) / FWS)

content-location = "Content-Location:" [CFWS] URI [CFWS] ; (localisation-de-contenu)

URI = URI absolu |URI relatif

où URI se restreint à la syntaxe des URL définie dans la [RFC1738] "Localisateurs de ressource uniformes jusqu'à ce que l'IETF spécifie d'autres sortes d'URI.

4.2 En-tête Content-Location

Un en-tête de localisation de contenu spécifie un URI qui étiquette le contenu d'une partie de corps dans l'en tête de laquelle il est placé. Sa valeur PEUT être un URI absolu ou relatif. Tout schéma d'URI ou d'URL peut être utilisé, mais l'utilisation de schémas d'URI ou d'URL non normalisés peut comporter des risques que les receveurs ne puissent les traiter correctement.

Un URI dans un en-tête Content-Location n'a pas besoin de se référer à une ressource qui est mondialement disponible à la restitution en utilisant cet URI (après résolution des URI relatifs). Cependant, les URI dans les en-têtes Content-Location (si ils sont absolus, ou peuvent se résoudre en URI absolus) DEVRAIENT toujours être uniques au monde.

Un en-tête Content-Location peut donc être utilisé pour étiqueter une ressource qui n'est pas restituable par certains ou aucun des receveurs d'un message. Par exemple un en-tête Content-Location peut étiqueter un objet qui n'est restituable qu'en utilisant cet URI dans un domaine restreint, tel qu'au sein de l'espace de la Toile interne à une entreprise. Un en-tête Content-Location peut même contenir un URI fictif. Un tel URI n'a pas besoin d'être unique au monde.

Un seul champ d'en-tête Content-Location est permis en tête de tout message ou contenu, en plus d'un en-tête Content-ID (comme spécifié dans la [RFC2045]) et, en tête d'un message, un Message-ID (comme spécifié dans la [RFC0822]). Tout cela constitue des étiquettes différentes, également valides, de parties de corps, et toutes peuvent être utilisées pour satisfaire à une référence à une partie de corps. Il n'est pas permis d'avoir plusieurs champs d'en-tête Content-Location en tête du même message.

Voici un exemple d'une structure multipart/related qui contient des parties de corps avec des étiquettes à la fois de Content-Location et de Content-ID :

Content-Type: multipart/related; boundary="boundary-example"; type="text/html"

--boundary-example

Content-Type: text/html; charset="US-ASCII"

... ... <IMG SRC="fiction1/fiction2"> ... ...

... ... <IMG SRC="cid:97116092811xyz@foo.bar.net"> ... ...

--boundary-example

Content-Type: image/gif

Content-ID: <97116092511xyz@foo.bar.net>

Content-Location: fiction1/fiction2

--boundary-example

Content-Type: image/gif

Content-ID: <97116092811xyz@foo.bar.net>

Content-Location: fiction1/fiction3

--boundary-example--

4.3 Les URI des agrégats MHTML

L'URI d'un agrégat MHTML n'est pas le même que l'URI de sa racine. L'URI de sa racine ne va directement restituer que la ressource racine elle-même, même si cela peut être cause qu'un navigateur de la Toile restitue séparément des ressources reliées en ligne. Si un champ d'en-tête Content-Location est utilisé en tête d'un multipart/related, ce Content-Location DEVRAIT s'appliquer à l'agrégat entier, et non à sa seule partie racine.

Lorsque un URI qui se réfère à un agrégat MHTML est utilisé pour restituer cet agrégat, l'ensemble de ressources restitué peut être différent de l'ensemble de ressources restitué en utilisant les Content-Location de ses parties. Par exemple, la restitution d'un agrégat MHTML peut retourner une ancienne version, alors que la restitution par l'URI racine et ses objets reliés en ligne peut retourner une version plus récente.

4.4 Codage et décodage des URI dans les champs d'en-tête MIME

4.4.1 Codage des URI qui contiennent des caractères inappropriés

Certains documents peuvent contenir des URI qui ont des caractères inappropriés pour un en-tête selon la RFC0822, soit parce que l'URI lui-même a une syntaxe incorrecte selon la [RFC1738], soit que la syntaxe d'URI standard ait été changée pour permettre des caractères qui n'étaient précédemment pas permis dans les en-têtes MIME. Ces URI ne peuvent pas être envoyés directement dans un en-tête de message. Si un tel URI survient, tous les caractères espaces et autres caractères illégaux qu'il contient doivent être codés en utilisant une des méthodes décrites dans la [RFC2047] section 4. Ce codage DOIT n'être fait que dans l'en-tête, et pas dans le texte HTML. Les clients receveurs DOIVENT décoder le codage de la [RFC2047] en tête avant de comparer les URI dans le corps de texte aux URI dans les en-têtes Content-Location.

La valeur du paramètre Jeu de caractère (charset) de "US-ASCII" DEVRAIT être utilisée si l'URI ne contient pas d'octet en dehors de la gamme des 7 bits. Si de tels octets sont présents, la valeur de paramètre de jeu de caractère correcte (déduite, par exemple, d'informations sur le document HTML dans lequel l'URI se trouvait) DEVRAIT être utilisée. Si cela ne peut pas être établi avec certitude, la valeur "UNKNOWN-8BIT" [RFC1428] DOIT être utilisée.

Note : Pour la confrontation des URI dans les parties de corps en text/html avec les URI dans les en-têtes Content-Location, la valeur du paramètre charset est pertinente, mais elle peut être pertinente pour un autre objet, et cet étiquetage incorrect DOIT donc être évité. Attention : La non pertinence du paramètre Jeu de caractère pourrait n'être pas vraie à l'avenir, si différents codages de caractère du même nom de fichier non anglais sont utilisés dans HTML.

4.4.2 Renvoi à la ligne des URI longs

Comme les champs d'en-tête MIME ont une longueur limitée et que de longs URI peuvent résulter des en-têtes Content-Location qui peuvent excéder cette longueur, les en-têtes Content-Location peuvent devoir aller à la ligne.

Le codage exposé au paragraphe 4.4.1 DOIT être effectué avant un tel renvoi à la ligne. Après cela, le renvoi à la ligne peut se faire, en utilisant l'algorithme défini à la [RFC2017] paragraphe 3.1.

4.4.3 Retour en une ligne et décodage des URL reçus dans les champs d'en-tête MIME

À réception, les champs d'en-tête MIME qui font un renvoi à la ligne devrait revenir sur la même ligne, et tout le codage MIME devrait être retiré, pour restituer l'URI original.

5. URI de base pour la résolution des URI relatifs

Les URI relatifs à l'intérieur des contenus de parties de corps MIME sont résolus par rapport à un URI de base en utilisant les méthodes de résolution par rapport aux URI décrites dans la [RFC1808]. Afin de déterminer cet URI de base, la première méthode applicable dans la liste qui suit est appliquée.

(a) Il y a une spécification de base à l'intérieur de la partie de corps MIME qui contient l'URI relatif qui résout les URI relatifs en URI absolus. Par exemple, HTML fournit les éléments de BASE à cet effet.

(b) Il y a un en-tête Content-Location dans l'environnement d'en tête immédiat de la partie de corps et il contient un URI absolu. Cet URI peut servir de base de la même façon qu'un URI demandé peut servie de base pour des URI relatifs au sein d'un fichier restitué via HTTP [RFC1945].

(c) Si nécessaire, l'étape (b) peut être répétée de façon récurrente pour trouver un en-tête Content-Location convenable dans une multipartie environnante ou en tête de message.

(d) Si l'objet MIME est retourné dans une réponse HTTP, utiliser l'URI qui a servi à initier la demande.

(e) Lorsque les méthodes ci-dessus n'ont pas donné un URI absolu, un URL de base de "thismessage:/" DOIT être employé. Cet URL de base a été défini dans le seul but de résolution des références relatives au sein d'une structure multipart/related lorsque aucun autre URI de base n'est spécifié.

Ceci est aussi décrit dans d'autres termes au paragraphe 8.2.

6. Envoi de documents sans objet relié

Si une ressource text/html (un objet) est envoyée sans les ressources subsidiaires, auxquelles elle se réfère, elle PEUT être envoyée par elle-même. Dans ce cas, il n'est pas nécessaire de l'incorporer dans une structure multipart/related.

Une telle ressource text/html peut ne pas contenir d'URI, ou des URI que le receveur s'attend à restituer (si possible) via un protocole spécifié par un URI. Une ressource text/html peut aussi être envoyée avec un lien non résoluble dans des cas particuliers, tels que lorsque deux auteurs échangent des projets de ressources qui ne sont pas terminés.

L'inclusion d'URI qui font référence à des ressources que le receveur doit restituer via un protocole spécifié par un URI peut ne pas fonctionner pour certains receveurs. La cause en est que tous les receveurs de messages électroniques n'ont pas la pleine connexité Internet, ou que les URI qui fonctionnent pour un envoyeur ne vont pas fonctionner pour un receveur. Cela survient, par exemple, lorsque un URI se réfère à une ressource au sein du réseau interne à une entreprise qui n'est pas accessible de l'extérieur de l'entreprise.

7. Usage du type de contenu "multipart/related"

Si un message contient une ou plusieurs parties de corps MIME qui contiennent des URI et aussi, comme parties de corps séparées, des ressources auxquelles se réfèrent ces URI (comme défini, par exemple, dans HTML 2.0 [RFC1866]), la totalité de cet ensemble de parties de corps (parties de corps référentes et parties de corps référées) DEVRAIT être envoyée au sein d'une structure multipart/related telle que définie dans la [RFC2387].

Bien que des en-têtes puissent survenir dans un message qui n'a pas de structure multipart/related associée, la présente norme ne couvre leur utilisation que pour la résolution des URI entre parties de corps à l'intérieur d'une structure multipart/related. La présente norme ne couvre pas le cas où une ressource dans une structure multipart/related incorporée contient des URI qui font référence à des parties de corps MIME dans une autre structure multipart/related, dans laquelle elle est incluse. La présente norme ne couvre pas le cas où une ressource dans une structure multipart/related contient des URI qui font référence à des parties de corps MIME dans une autre structure parallèle ou incorporée, ou dans un autre message MIME, même si des méthodes similaires à celles décrites dans la présente norme sont utilisées. On attire l'attention des mises en œuvre qui emploient de tels URI sur le fait que les agents receveurs qui mettent en œuvre la présente norme peuvent n'être pas capables de traiter de telles références.

Lorsque la partie de corps de début d'une structure multipart/related est un objet atomique, comme une ressource text/html, elle DEVRAIT être employée comme la ressource racine de cette structure multipart/related. Lorsque la partie de corps de début d'une structure multipart/related est une structure multipart/alternative, et que cette structure contient au moins une autre partie de corps qui est un objet atomique convenable, tel qu'une ressource text/html, cette partie de corps DEVRAIT être employée comme ressource racine du document agrégé. On attire cependant l'attention des développeurs sur le fait que certains agents receveurs traitent les structures multipart/alternative comme si elles étaient multipart/mixed (bien que MIME [RFC2045] exige la prise en charge de multipart/alternative).

La [RFC2387] spécifie qu'un paramètre type est obligatoire dans un en-tête "Content-Type: multipart/related", et exige qu'il soit employé pour spécifier le type de l'objet de démarrage multipart/related. Donc, la valeur du paramètre de type devra être "multipart/alternative", lorsque la partie de démarrage est un "Content-type multipart/alternative", même si la ressource racine réelle est du type "text/html". De plus, si l'objet de début multipart/related n'est pas la première partie de corps dans une structure multipart/related, la [RFC2387] exige de plus que son Content-ID DOIT être spécifié comme la valeur d'un paramètre de démarrage dans l'en-tête "Content-Type: multipart/related".

Pour le rendu d'une ressource dans une structure multipart/related, les références d'URI au sein de cette ressource peuvent être satisfaites par des parties de corps au sein de la même structure multipart/related (voir le paragraphe 8.2). Ceci est utile :

(a) Pour les receveurs qui n'ont qu'une messagerie électronique mais pas d'accès Internet complet.

(b) Pour les receveurs qui pour d'autres raisons, telles qu'un pare-feu ou l'utilisation de liaisons internes à l'entreprise, ne peuvent pas restituer des ressources référencées par des URI via des protocoles spécifiés par des URI.

Note : Ce qui signifie que vous pouvez, via e-mail, envoyer des objets text/html qui comportent des URI que le receveur ne peut pas résoudre via HTTP, ou d'autres URI exigeant la connexité.

(c) Pour envoyer un document dont le contenu est préservé même si les ressources auxquelles se réfèrent les URI incorporés sont ensuite changés ou supprimés.

(d) Pour les ressources qui ne sont pas disponibles pour une restitution fondée sur le protocole.

(e) Pour accélérer l'accès.

Lorsque un MUA envoie des objets qui ont été restitués à partir de la Toile, il DEVRAIT conserver leurs URI de la Toile. Il NE DEVRAIT PAS transformer ces URI en une autre forme d'URI avant de les transmettre. Cela va permettre au MUA receveur à la fois de vérifier les MIC inclus avec le message et de vérifier les documents par rapport à leur contrepartie de la Toile, si c'est approprié.

Dans certains cas cela ne va pas fonctionner – par exemple, si une ressource contient des URI comme paramètres pour des objets et appliquettes. Dans un tel cas, il vaut mieux réécrire le document avant de l'envoyer. Ce problème est exposé plus en détails dans la RFC d'information qui sera publiée en complément à la présente norme.

Au sein d'une structure multipart/related, chaque partie de corps DOIT avoir, si il en est une d'allouée, une valeur d'en-tête Content-ID différente et des valeurs de champ d'en-tête Content-Location qui se résolvent en un URI différent.

Deux parties de corps dans la même structure multipart/related ne peuvent avoir la même valeur relative d'en-tête Content-Location que si elles deviennent différentes lorsque qu'elles se résolvent en URI absolus.

8. Usage de liens avec d'autres parties de corps

8.1 Principe général

Une partie de corps, comme une partie de corps text/html, peut contenir des URI qui se réfèrent à des ressources qui sont incluses comme parties de corps dans le même message – plus précisément, comme parties de corps au sein de la même structure multipart/related. De telles ressources liées à des URI sont souvent destinées à être affichées en ligne chez la personne qui regarde la partie de corps référencée ; par exemple, des objets référencés avec l'attribut SRC de l'élément IMG dans HTML 2.0 [RFC1866]. De nouveaux éléments et attributs ayant cette propriété sont proposés dans le développement en cours de HTML (par exemples, appliquettes, trames, profils, OBJET, classid, codebase, données, SCRIPT). Un envoyeur pourrait aussi vouloir envoyer un ensemble de documents HTML que le lecteur puisse traverser, et qui sont en rapport avec l'attribut href de l'élément A.

Si un usager restitue et affiche une page de la Toile formée d'une ressource text/html, et des ressources subsidiaires auxquelles elle fait référence, et sauvegarde simplement la ressource text/html, cet usager ne sera pas capable ultérieurement de restituer et afficher la page de la Toile comme elle apparaissait lorsque elle a été sauvegardée. Le format décrit dans la présent norme peut être utilisé pour archiver et restituer toutes les ressources requises pour afficher la page de la Toile, comme elle apparaissait à l'origine à un moment donné dans un fichier agrégé.

Afin d'envoyer ou de mémoriser de tels messages complets, il est nécessaire de spécifier comment un URI dans une partie de corps peut faire référence à une ressource dans une autre partie de corps.

8.2 Résolution des URI dans des parties de corps text/html

La résolution des URI en ligne, restitués, et d'autre sortes, dans les parties de corps en text/html, est effectuée de la façon suivante :

(a) Déplier les valeurs d'en-tête sur plusieurs lignes conformément à la [RFC2017]. Cependant, NE PAS traduire les codages de caractère de l'espèce décrite dans la [RFC1738]. Exemple : ne pas transformer "a%2eb/c%20d" en "a/b/c d".

(b) Retirer tous les codages MIME, tels que les codages de transfert de contenu et d'en-tête comme défini dans MIME partie 3 [RFC2047]. Cependant, NE PAS traduire les codages de caractères de l'espèce décrite dans la [RFC1738]. Exemple : ne pas transformer "a%2eb/c%20d" en "a/b/c d".

(c) Essayer de résoudre tous les URI relatifs dans le contenu HTML et dans les en-têtes Content-Location en utilisant la procédure décrite à la section 5 ci-dessus. Le résultat de cette résolution peut être un URI absolu, ou un URI absolu avec la base "thismessage:/" comme spécifié à la section 5.

(d) Pour chaque URI de référence dans une partie de corps text/html, comparer la valeur de l'URI de référence après résolution comme décrit dans (a) et (b), avec l'URI déduit des en-têtes Content-ID et Content-Location pour les autres parties de corps au sein de la même structure Multipart/related ou environnante. Si les chaînes sont identiques, octet par octet, l'URI de référence se rapporte alors à cette partie de corps. Cette comparaison ne réussira que si les deux URI sont identiques. Cela signifie que si un des deux URI doit être comparé à un URI absolu fictif avec la base "thismessage:/", l'autre doit aussi être un URI absolu fictif, et non réductible à un URI absolu réel.

(e) Si (d) échoue, essayer de restituer l'hyperlien de la ressource de l'URI de référence par une recherche Internet ordinaire. La résolution des URI de type URL "mid" ou "cid" en autres parties de contenu, en dehors de la même structure multipart/related, ou dans d'autres messages envoyés séparément, n'est pas couverte par la présente norme, et n'est donc ni encouragée ni interdite.

8.3 Usage de l'en-tête Content-ID et des URL CID

Lorsque des URI qui emploient un schéma CID (Content-ID) comme défini dans la [RFC1738] et la [RFC2045] sont utilisés pour faire référence à d'autres parties de corps dans une structure MHTML multipart/related, ils DOIVENT être confrontés seulement à des valeurs d'en-tête Content-ID, et pas à des valeurs d'en-tête Content-Location avec CID:. Donc, même si les deux en-têtes suivants sont identiques par leur signification, seule la valeur de Content-ID sera confrontée, et la valeur de Content-Location sera ignorée.

Content-ID: <foo@bar.net>

Content-Location: CID: foo@bar.net

Note : Les Content-ID DOIVENT être uniques au monde [RFC2045]. Il n'est donc pas permis de les rendre uniques seulement au sein d'un message ou au sein d'une seule structure multipart/related.

9. Exemples

Attention : Les exemples ne sont fournis que pour illustrer notre propos. Si il y a contradiction entre le texte explicatif et les exemples de cette norme, c'est le texte explicatif qui est normatif.

Notation : Les exemples contiennent des retours à la ligne pour montrer la structure, les objets réels ne devraient pas être présentés de cette façon.

9.1 Exemple de corps HTML sans objet lié inclus

Le premier exemple est la plus simple forme d'un message HTML. Ce message ne contient pas d'objet HTML agrégé, mais simplement un message avec une seule partie de corps HTML. Cette partie de corps contient un URI, mais les messages ne contiennent pas la ressource à laquelle cet URI se réfère. Pour restituer la ressource à laquelle se réfère l'URI, le client receveur aurait besoin d'un accès IP à l'Internet, ou d'une passerelle de messagerie électronique.

From: foo1@bar.net

To: foo2@bar.net

Subject: Un simple exemple

Mime-Version: 1.0

Content-Type: text/html; charset="iso-8859-1"

Content-Transfer-Encoding: 8bit

<HTML>

<head></head>

<body>

<h1>Acute accent</h1>

Les deux lignes suivantes semblent avoir le même rendu d'écran :<p>

E avec accent aigu devient É.<br>

E avec accent aigu devient &Eacute;.<p>

Essayez de cliquer sur <a href="http://www.ietf.cnri.reston.va.us/">

ici .</a><p>

</body></HTML>

9.2 Exemple avec un URI absolu sur une image GIF incorporée

Le second exemple est un message HTML qui comporte une seule image, référencée en utilisant le mécanisme Content-Location.

From: foo1@bar.net

To: foo2@bar.net

Subject: Un simple exemple

Mime-Version: 1.0

Content-Type: multipart/related; boundary="boundary-example"; type="text/html"; start="<foo3@foo1@bar.net>"

--boundary-example

Content-Type: text/html;charset="US-ASCII"

Content-ID: <foo3@foo1@bar.net>

... texte du document HTML, qui peut contenir un URI 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="Logo de l'IETF">

--boundary-example

Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo.gif

Content-Type: IMAGE/GIF

Content-Transfer-Encoding: BASE64

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

--boundary-example--

9.3 Exemple avec des URI relatifs à des images GIF incorporées

Dans cet exemple, un champ d'en-tête Content-Location dans la partie en tête la plus externe sera une base pour tous les URL relatifs, qui sont aussi à l'intérieur du texte HTML envoyé.

From: foo1@bar.net

To: foo2@bar.net

Subject: Un simple exemple

Mime-Version: 1.0

Content-Location: http://www.ietf.cnri.reston.va.us/

Content-Type: multipart/related; boundary="boundary-example"; type="text/html"

--boundary-example

Content-Type: text/html; charset="ISO-8859-1"

Content-Transfer-Encoding: QUOTED-PRINTABLE

... texte du document HTML, qui pourrait contenir des URI se référant à des ressources dans d'autres parties de corps, par exemple par des déclarations telles que :

<IMG SRC="images/ietflogo1.gif" ALT="IETF logo1">

<IMG SRC="images/ietflogo2.gif" ALT="IETF logo2">

<IMG SRC="images/ietflogo3.gif" ALT="IETF logo3">

Exemple d'un signe de copyright codé avec Quoted-Printable : =A9

Exemple d'un signe de copyright transposé en balise HTML : &#168;

--boundary-example

Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo1.gif

; Note – Un Content-Location absolu n'exige pas de base

Content-Type: IMAGE/GIF

Content-Transfer-Encoding: BASE64

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

--boundary-example

Content-Location: images/ietflogo2.gif

; Note - Un Content-Location relatif se résout avec la base spécifiée dans l'en tête Multipart/Related

; Content-Location

Content-Transfer-Encoding: BASE64

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

--boundary-example

Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo3.gif

Content-Transfer-Encoding: BASE64

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

--boundary-example--

9.4 Exemple avec un URI relatif et pas de BASE disponible

From: foo1@bar.net

To: foo2@bar.net

Subject: Un simple exemple

Mime-Version: 1.0

Content-Type: multipart/related; boundary="boundary-example"; type="text/html"

--boundary-example

Content-Type: text/html; charset="iso-8859-1"

Content-Transfer-Encoding: QUOTED-PRINTABLE

... Le texte du document HTML, qui pourrait contenir un URI faisant référence à une ressource dans une autre partie de corps, par exemple par une déclaration telle que :

<IMG SRC="ietflogo.gif" ALT="Logo de l'IETF">

Exemple d'un signe de copyright codé avec Quoted-Printable : =A9

Exemple d'un signe de copyright transposé sur une balise HTML : &#168;

--boundary-example

Content-Location: ietflogo.gif

Content-Type: IMAGE/GIF

Content-Transfer-Encoding: BASE64

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

--boundary-example--

9.5 Exemple d'utilisation de CID d'URL et d'en-tête Content-ID pour une image GIF incorporée

From: foo1@bar.net

To: foo2@bar.net

Subject: Un simple exemple

Mime-Version: 1.0

Content-Type: multipart/related; boundary="boundary-example" ; type="text/html"

--boundary-example

Content-Type: text/html; charset="US-ASCII"

... texte du document HTML qui pourrait contenir un URI faisant référence à une ressource dans une autre partie de corps, par exemple par une déclaration telle que :

<IMG SRC="cid:foo4@foo1@bar.net" ALT="IETF logo">

--boundary-example

Content-Location: CID:something@else ; cet en-tête est indifférent

Content-ID: <foo4@foo1@bar.net>

Content-Type: IMAGE/GIF

Content-Transfer-Encoding: BASE64

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

--boundary-example--

9.6 Exemple de références permises et interdites entre parties de corps incorporées

Cet exemple montre dans quels cas les références sont admises entre plusieurs parties de corps multipart/related dans un message.

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"

Content-ID: <foo3@foo1@bar.net>

La référence d'image ci-dessous sera résoute avec l'image dans la partie de corps suivante.

<IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"

ALT="Logo de l'IETF avec un arrière plan noir">

La référence d'image ci-dessous ne peut pas être résolue au sein de ce message MIME, car elle contient une référence provenant d'une partie de corps externe dans une partie de corps interne, ce qui n'est pas accepté par cette norme.

<IMG SRC=images/ietflogo2e.gif"

ALT="IETF logo with transparent background">

La référence d'ancre immédiatement ci-dessous va être résoute par la partie de corps text/html incorporée en dessous :

<A HREF="http://www.ietf.cnri.reston.va.us/more-info>

More info</A>

La référence d'ancre immédiatement ci-dessous va être résoute par la partie de corps text/html incorporée en dessous :

<A HREF="http://www.ietf.cnri.reston.va.us/even-more-info>

Even more info</A>

--boundary-example-1

Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo.gif

Content-Type: IMAGE/GIF

Content-Transfer-Encoding: BASE64

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

--boundary-example-1

Content-Location: http://www.ietf.cnri.reston.va.us/more-info

Content-Type: multipart/related; boundary="boundary-example-2"; type="text/html"

--boundary-example-2

Content-Type: text/html;charset="US-ASCII"

Content-ID: <foo4@foo1@bar.net>

La référence d'image ci-dessous va être résoute avec l'image dans la multipart/related environnante au dessus.

<IMG SRC="images/ietflogo.gif"

ALT="Logo de l'IETF avec arrière plan blanc">

La référence d'image ci-dessous va être résoute avec l'image à l'intérieur de la multipart/related incorporée actuelle en dessous.

<IMG SRC=images/ietflogo2e.gif"

ALT="Logo de l'IETF avec un arrière plan transparent">

--boundary-example-2

Content-Location: http:images/ietflogo2.gif

Content-Type: IMAGE/GIF

Content-Transfer-Encoding: BASE64

R0lGODlhGAGgANX/ACkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nzc3t7e4SEhIyMjJSUlJycnKWlpa2trbW1tcDAwM7Ozv/eQnNzjHNzlGtrjGNjhFpae1pa etc...

--boundary-example-2--

--boundary-example-1

Content-Location: http://www.ietf.cnri.reston.va.us/even-more-info

Content-Type: multipart/related; boundary="boundary-example-3" ; type="text/html"

--boundary-example-3

Content-Type: text/html;charset="US-ASCII"

Content-ID: <4@foo@bar.net>

La référence d'image ci-dessous va être résoute avec l'image à l'intérieur de la multipart/related incorporée actuelle en dessous.

<IMG SRC=images/ietflogo2d.gif"

ALT="Logo de l'IETF avec des ombres">

La référence d'image ci-dessous va être résoute conformément à la présente norme car les références entre structures multipart/related parallèles ne sont pas acceptées.

<IMG SRC=images/ietflogo2e.gif"

ALT="Logo de l'IETF avec un arrière plan transparent">

--boundary-example-3

Content-Location: http:images/ietflogo2d.gif

Content-Type: IMAGE/GIF

Content-Transfer-Encoding: BASE64

R0lGODlhGAGgANX/AMDAwCkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nzc3t7e4SEhIyMjJSUlJycnKWlpa2trbW1tb29vcbGxs7OztbW1t7e3ufn5+/v etc...

--boundary-example-3--

--boundary-example-1--

10. Problèmes de codage de caractères et problèmes de bout en bout

Pour le codage des caractères dans les documents HTML et autres documents de texte en flux d'octets compatibles MIME, les mécanismes suivants sont pertinents

- HTML [RFC1866], [RFC2070] comme application de [SGML] permet que les caractères soient notés par des entités de caractères aussi bien que par des références numériques de caractères (par exemple "Lettre minuscule latine avec accent aigu" peut être représenté par "&aacute;" ou "&#225;") dans le balisage HTML.

- Les documents HTML, en commun avec d'autres documents du Content-Type MIME "text", peuvent être représentés dans MIME en utilisant un parmi plusieurs codages de caractères. La valeur du paramètre MIME Content-Type "charset" indique le codage particulier utilisé. Pour la signification exacte et l'utilisation du paramètre "charset", prière de voir la section 4 de la [RFC2046].

Noter que le paramètre "charset"se réfère seulement au codage de caractère de MIME. Par exemple, la chaîne "&aacute;" peut être envoyée dans MIME avec "charset=US-ASCII", alors que le caractère brut "Lettre minuscule latine avec accent aigu" ne le peut pas.

Les mécanismes ci-dessus sont bien définis et documenté, et donc ne seront pas plus développés ici. En envoyant un message, tous les mécanismes mentionnés ci-dessus PEUVENT être utilisés, et toute combinaison de ces mécanismes PEUT survenir lors de l'envoi du document en format MIME. Les agents d'utilisateur receveurs (en conjonction avec tout navigateur de la Toile qu'ils peuvent utiliser pour afficher le document) DOIVENT être capables de traiter toute combinaison de ces mécanismes.

Noter aussi que :

- Tout document incluant des documents HTML qui contient des valeurs d'octet en dehors de la gamme de 7 bits a besoin qu'un codage de transfert de contenu soit appliqué avant la transmission sur certains protocoles de transport ; voir la section 5 de la [RFC2045].

- La norme MIME [RFC2046] précise que les documents de messagerie électronique de "Content-Type: Text/" DOIVENT être en forme canonique avant l'application d'un codage de transfert de contenu, c'est à dire que les renvois à la ligne sont codés comme des CRLF, et non par des CR ou des LF nus, ou n'importe quoi d'autre. Ceci est une différence avec la [RFC1945] dont le paragraphe 3.6.1 permettait d'autres représentations de renvois à la ligne.

Noter que ceci peut causer des problèmes de vérification d'intégrité sur la base des sommes de contrôle qui peuvent n'être pas préservées en passant un document de l'environnement HTTP à celui de MIME. Si un document doit être converti d'une façon telle qu'une vérification d'intégrité fondée sur une somme de contrôle devienne invalide, cet en-tête de vérification d'intégrité DEVRAIT être retiré du document.

D'autres sources de problèmes sont le codage de contenu utilisé dans HTTP mais qui n'est pas permis dans MIME, et les jeux de caractères qui ne sont pas capables de représenter les sauts à la ligne par des CRLF. On trouvera une bonne récapitulation des différences entre HTTP et MIME par rapport au type de contenu "text" à l'appendice C de la [RFC1945].

Certains mécanismes de transport peuvent spécifier un paramètre "charset" par défaut si aucun n'est fourni [RFC1945], |RFC2045]. Comme la valeur par défaut diffère selon les mécanismes, lorsque HTML est transféré par messagerie électronique, le paramètre "charset" DEVRAIT être inclus plutôt que de se reposer sur une valeur par défaut.

11. Considérations pour la sécurité

11.1 Considérations pour la sécurité sans rapport avec la mise en antémémoire

Il est possible que l'envoyeur d'un message représente mal la source d'une partie de corps multipart/related chez le receveur du message en l'étiquetant avec un URI Content-Location qui fait référence à une autre ressource. Donc, les receveurs de messages ne devraient interpréter les URL de Content-Location que comme étiquetant une partie de corps pour la résolution des références provenant de parties de corps dans la même structure de message multipart/related, et non comme la source d'une ressource, sauf si cela peut être vérifié par d'autres moyens.

Les URI, en particulier les URI de fichiers, si ils sont utilisés sans changement dans un message, peuvent révéler par inadvertance des informations qui n'étaient pas destinées à être révélées en dehors d'un contexte de sécurité particulier. Les envoyeurs de message devraient faire attention en construisant des messages qui contiennent les nouveaux champs d'en-tête, définis par la présent norme, qu'ils ne révèlent pas d'informations qui sortent des contextes de sécurité auxquels elles appartiennent.

Certains serveurs de ressources cachent les mots de passe et les tickets (jetons d'accès à des informations qui ne devraient pas être révélées aux autres) et autres informations sensibles dans des champs non visibles ou des URI au sein d'une ressource text/html. Si une telle ressource text/html est transmise dans un message électronique, ces informations sensibles peuvent être révélées par inadvertance à d'autres.

Comme les documents HTML peuvent contenir des instructions directement exécutables (c'est à dire en JavaScript) ou faire indirectement référence à un contenu exécutable (spécification "INSERT", Java) il est excessivement dangereux qu'un agent d'utilisateur receveur exécute un contenu reçu dans un message électronique sans porter une attention prudente aux restrictions sur les capacités de ce contenu exécutable.

Les messages formatés en HTML peuvent être utilisés pour examiner le comportement de l'usager, par exemple pour rompre l'anonymat, d'une façon invasive pour la vie privée des individus. Si vous envoyez un message avec un lien en ligne avec un objet qui n'est pas lui-même inclus dans le message, les messageurs ou navigateurs receveurs peuvent demander cet objet au moyen de HTTP. La transaction HTTP va alors révéler qui lit le message. Par exemple, une personne qui veut trouver qui est derrière une identité d'usager anonyme, ou à partir de quelle station de travail un usager lit son message, peut le faire en envoyant un message avec une liaison en ligne puis observer à partir d'où cette liaison est utilisée pour demander l'objet.

11.2 Considérations de sécurité en rapport avec la mise en antémémoire

Il y a un problème bien connu avec la mise en antémémoire de ressources directement restituées de la Toile. Une ressource restituée d'une antémémoire peut différer de celle re-restituée de sa source. Ce problème, se manifeste aussi lorsque une copie d'une ressource est délivrée dans une structure multipart/related.

Lors du traitement (rendu) d'une partie de corps text/html dans une structure MHTML multipart/related, tous les URI dans cette partie de corps text/html qui font référence à des ressources subsidiaires au sein de la même structure multipart/related DEVRONT être satisfaits par ces ressources et non par des ressources provenant de toute autre source locale ou distante.

Donc, si un envoyeur souhaite qu'un receveur restitue toujours une ressource référencée par un URI à partir de sa source, une copie étiquetée par un URI NE DOIT PAS être incluse dans la même structure multipart/related.

De plus, comme la source d'une ressource reçue dans une structure multipart/related peut être mal représentée (voir au paragraphe 11.1 ci-dessus) si une ressource reçue dans une structure multipart/related est mémorisée dans une antémémoire, elle NE DOIT PAS être restituée à partir de cette antémémoire autrement que par une référence contenue dans une partie de corps de la même structure multipart/related. Manquer à respecter cette directive permettrait à une structure multipart/related d'être employée comme cheval de Troie. Par exemple, pour injecter des ressources falsifiées (c'est-à-dire, une mauvaise représentation d'un site concurrent de la Toile) dans une antémémoire généralement accessible d'un receveur.

12. Différences par rapport à la précédente version de cette norme dans la RFC2110

La spécification a été modifiée pour montrer que les formats décrits ne s'appliquent pas qu'aux multiparties MIME dans la messagerie électronique, mais aussi aux multiparties MIME transférées à travers d'autres protocoles tels que HTTP ou FTP.

Afin de respecter la [RFC1808], les en-têtes Content-Location dans les Content-Heading en multiparties peuvent maintenant être utilisés comme base de résolution des URI relatifs dans leurs parties composantes, mais seulement si aucun URI de base ne peut être déduit de la partie composante elle-même. Les URI de base dans les champs d'en-tête Content-Location dans les en-têtes internes ont la priorité sur les URI de base des en têtes multiparties externes.

L'en-tête Content-Base, qui était présent dans la RFC2110, a été retiré. Une mise en œuvre prudente peut choisir d'accepter cet en-tête en entrée pour la compatibilité avec les mises en œuvre de la RFC2110, mais DOIT ne jamais envoyer d'en-tête Content-Base, car cet en-tête ne fait plus partie de la présente norme.

Un paragraphe 4.4.1 a été ajouté pour spécifier comment traiter le cas de l'envoi d'une partie de corps dont l'URI n'est pas en accord avec la syntaxe d'URI correcte.

Le traitement des URI relatifs et absolus pour la correspondance entre les parties de corps a été fusionné en une seule description, en spécifiant que les URI relatifs,qui ne peuvent pas être résolus autrement, devraient être traités comme si on leur avait donné l'URL "thismessage:/".

13. Remerciements

Harald T. Alvestrand, Richard Baker, Isaac Chan, Dave Crocker, Martin J. Duerst, Lewis Geer, Roy Fielding, Ned Freed, Al Gilman, Paul Hoffman, Andy Jacobs, Richard W. Jesmajian, Mark K. Joseph, Greg Herlihy, Valdis Kletnieks, Daniel LaLiberte, Ed Levinson, Jay Levitt, Albert Lunde, Larry Masinter, Keith Moore, Gavin Nicol, Martyn W. Peck, Pete Resnick, Jon Smirl, Einar Stefferud, Jamie Zawinski, Steve Zilles et plusieurs autres personnes nous ont aidé à préparer le présent document. Nous portons seuls la responsébilité de toute erreur qui pourrait subsister dans le document.

14. Références

[HTML3.2] Dave Raggett: HTML 3.2 Reference Specification, W3C Recommendation, janvier 1997, à l'URL http://www.w3.org/TR/REC-html32.html

[PDF] Tim Bienz and Richar Cohn: "Portable Document Format Reference Manual", Addison-Wesley, Reading, MA, USA, 1993, ISBN 0-201-62628-4.

[RFC0821] J. Postel, "Protocole simple de transfert de messagerie", STD 10, août 1982.

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

[RFC1036] M. Horton et R. Adams, "Norme pour l'échange de messages USENET", décembre 1987. (Remplacée par RFC5536)

[RFC1123] R. Braden, éditeur, "Exigences pour les hôtes Internet – Application et prise en charge", STD 3, octobre 1989.

[RFC1321] R. Rivest, "Algorithme de résumé de message MD5", avril 1992. (Information)

[RFC1738] T. Berners-Lee et autres, "Localisateurs uniformes de ressource (URL)", décembre 1994. (P.S., remplacée par les RFC 4248 et 4266)

[RFC1808] R. Fielding, "Localisateurs relatifs de ressource uniforme", juin 1995.

[RFC1866] T. Berners-Lee, D. Connolly, "Langage de balisage Hypertext - 2.0", novembre 1995. (Obsolète, voir RFC2854) (Historique)

[RFC1945] T. Berners-Lee, R. Fielding, H. Frystyk, "Protocole de transfert Hypertext -- HTTP/1.0", mai 1996. (Information)

[RFC2017] N. Freed, K. Moore, A. Cargille, "Définition du type d'accès de corps extérieur MIME d'URL", octobre 1996. (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.)

[RFC2070] F. Yergeau, G. Nicol, G. Adams, M. Duerst, "Internationalisation du langage de balisage Hypertext", janvier 1997. (Obsolète, voir RFC2854) (Historique)

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2183] R. Troost, S. Dorner, K. Moore, éd., "Communication des informations de présentation dans les messages Internet : le champ d'en-tête Contenu-disposition", août 1997. (MàJ par RFC2184, RFC2231) (P.S.)

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

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

[INFO] J. Palme, "Sending HTML in MIME, an informational supplement to the RFC: MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", Travail en cours.

[SGML] ISO 8879. Information Processing -- Text and Office - Standard Generalized Markup Language (SGML), 1986. URL:http://www.iso.ch/cate/d16387.html

[VRML] Gavin Bell, Anthony Parisi, Mark Pesce, "Virtual Reality Modeling Language (VRML) Version 1.0 Language Specification." mai 1995, http://www.vrml.org/Specifications/ .

[XML] Extensible Markup Language, publié par le World Wide Web Consortium, URL http://www.w3.org/XML/

15. Adresse des auteurs

Pour contacter les éditeurs, écrire de préférence à Jacob Palme.

Président du groupe de travail :

Einar Stefferud

mél : stef@nma.com

16. Déclaration de droits de reproduction

Copyright (C) The Internet Society (1999). 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 copyright ci-dessus et le présent paragraphe soient inclus dans toutes 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 les besoins 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 y 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.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.