---

We need Your Support. Make a Donation now! or

---

Extensions MIME Valeur de paramètre et Mot codé : jeux de caractères, langages, et continuations

Statut de ce mémoire

Le présent document spécifie une proposition de norme de protocole 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 courante de "Normes officielles de protocoles de l'Internet" (STD 1) pour connaître l'état de normalisation et le statut de ce protocole. La distribution du présent mémoire n'est soumise à aucune restriction.

(La présente traduction incorpore les errata n°476, 477, 478 et 590 des 17/04/2001, 24/11/2001 et09/02/2003)

Notice de droits d'auteur

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

1.   Résumé

Le présent mémoire définit des extensions aux mécanismes type de support de la RFC 2045 et valeur de paramètre de disposition de la RFC 2183 afin de fournir

(1)   un moyen de spécifier les valeurs de paramètre dans des jeux de caractères autres que l'US-ASCII,

(2)   spécifier le langage à utiliser si la valeur est affichée, et

(3)   un mécanisme de continuation pour les valeurs de long paramètre pour éviter les problèmes avec le retour à la ligne de la ligne d'en-tête.

Le présent mémoire définit aussi une extension pour les mots codés définis dans la RFC 2047 pour permettre la spécification du langage à utiliser pour l'affichage ainsi que pour le jeu de caractères.

2.   Introduction

Les extensions de messagerie Internet multi-objets (MIME, Multipurpose Internet Mail Extensions) [RFC-2045, RFC-2046, RFC-2047, RFC-2048, RFC-2049], définissent un format de message pour permettre :

(1)   des corps de message textuels dans des jeux de caractères autres que l'US-ASCII,

(2)   un ensemble extensible de formats différents pour les corps de message non textuels,

(3)   des corps de message multi-parties, et

(4)   des informations d'en-tête textuelles dans des jeux de caractères autres que l'US-ASCII.

MIME est maintenant largement déployé et est utilisé par divers protocoles Internet, y compris, bien sûr, de la messagerie électronique de l'Internet. Cependant, du succès de MIME résulte le besoin de mécanismes additionnels qui n'étaient pas fournis dans la spécification d'origine du protocole.

En particulier, les mécanismes existants de MIME permettent des paramètres de désignation de type de support (champ Type de contenu) ainsi que de disposition (champ Disposition du contenu). Un type de support MIME peut spécifier un nombre quelconque de paramètres associés à tous ses sous-types, et tout sous-type spécifique peut spécifier des paramètres additionels pour son propre usage. Une valeur de disposition MIME peut spécifier un nombre quelconque de paramètres associés, dont le plus important est probablement le paramètre de nom de fichier de la disposition d'une pièce jointe.

Ces noms et valeurs de paramètres vont finir par apparaître dans les champs d'en-tête Type de contenu et Disposition du contenu dans les messages Internet. Cela impose par nature trois limitations cruciales :

(1)   Les lignes dans les champs d'en-tête des messages Internet passent à la ligne selon les règles de passage à la ligne de la RFC 822. Cela rend les valeurs de longs paramètres problématiques.

(2)   Les en-têtes MIME, comme les en-têtes de la RFC 822 où ils apparaissent souvent, sont limités à l'US-ASCII à 7 bits, et les mécanismes de mot codé de la RFC 2047 ne sont pas disponibles pour les valeurs de paramètrs. Cela rend impossible d'avoir des valeurs de paramètre dans des jeux de caractères autres que l'US-ASCII sans spécifier une sorte de codage privé par paramètre.

(3)   Il est récemment devenu évident que les informations de jeu de caractères ne sont pas suffisantes pour afficher de façon appropriée certaines sortes d'informations – les informations de langage sont aussi nécessaires [RFC-2130]. Par exemple, la prise en charge des utilisateurs handicapés peut exiger de lire du texte à voix haute. La langue dans laquelle le texte est écrit est nécessaire pour le faire correctement. Certaines valeurs de paramètre peuvent devoir être affichées, et donc il est nécessaire de prévoir l'inclusion des informations de langage.

Le dernier problème de cette liste concerne aussi la question des mots codés définis par la RFC 2047, car les mots codés sont destinés principalemeet à des besoins d'affichage.

Le présent document définit les extensions qui s'adressent à toutes ces limitations. Toutes ces extensions sont mises en œuvre de façon complètement compatible au niveau syntaxique avec les mises en œuvre MIME existantes. De plus, les extensions sont conçues pour avoir aussi peu d'impact que possible sur les utilisations existantes de MIME.

NOTE IMPORTANTE : Ces mécanismes tendent à être un peu lourds quand ils sont réellement utilisés. À ce titre, ils ne devraient pas être utilisés à la légère ; ils devraient être réservés pour des situations où ils sont vraiment nécessaires.

2.1   Notation des exigences

Le présent document utilise à l'occasion des termes qui apparaissent en lettres majuscules. Lorsque les termes "DOIT", "DEVRAIT", "NE DOIT PAS", "NE DEVRAIT PAS", et "PEUT" apparaissent en lettres capitales, ils sont utilisés pour indiquer des exigences particulières de la présente spécification. Un exposé de la signification de ces termes figure dans la [RFC 2119].

3.   Continuations de valeur d'un paramètre

Les valeurs de paramètre MIME long de type de support ou de disposition n'interagissent pas très bien avec les conventions de retour à la ligne des lignes d'en-tête. En particulier, le retour à la ligne approprié de la ligne d'en-tête dépend du fait qu'il y a des endroits où les espaces blanches linéaires (LWSP, linear whitespace) sont admises, qui peuvent être présentes ou non dans une valeur de paramètre, et qui même présentes, peuvent n'être pas reconnaissables comme telles car la connaissance spécifique de la syntaxe de valeur de paramètre peut n'être pas disponible à l'agent qui fait les retours à la ligne. Le résultat est que les valeurs de long paramètre peuvent finir par être tronquées ou autrement endommagées par des mises en œuvre incorrectes de retour à la ligne.

Un mécanisme est donc nécessaire pour casser les valeurs de paramètre en plus petites unités qui soient justiciables du retour à la ligne. Tout mécanisme de cette sorte DOIT être compatible avec les traitements MIME existants. Cela signifie que :

(1)   le mécanisme NE DOIT PAS changer la syntaxe de type de support et de lignes de disposition MIME, et que

(2)   le mécanisme NE DOIT PAS dépendre de l'ordre des paramètres car MIME déclare que les paramètres ne sont pas sensibles à l'ordre. Noter qu'alors que MIME interdit la modification des en-têtes MIME durant le transport, il est encore possible que les paramètres soient réordonnés lorsque est fait le traitement au niveau de l'agent d'utilisateur.

La solution évidente est alors d'utiliser plusieurs paramètres pour contenir une seule valeur de paramètre et d'utiliser une sorte de nom distinctif pour indiquer quand cela est fait. Et cette solution évidente est exactement ce qui est spécifié ici: Le caractère astérisque ("*") suivi d'un compte décimal est employé pour indiquer que plusieurs paramètres sont utilisés pour encapsuler une seule valeur de paramètre. Le compte commence à 0 et s'incrémente de 1 pour chaque section suivante de la valeur du paramètre. Les valeurs décimales sont utilisées et ni les zéros en tête ni les trous dans la séquence ne sont admis.

La valeur originale du paramètre est récupérée en enchaînant les diverses sections du paramètre, dans l'ordre. Par exemple, le champ Type-de-contenu

Content-Type: message/external-body; access-type=URL;

URL*0="ftp://";

URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"

est sémantiquement identique à

Content-Type: message/external-body; access-type=URL;

URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"

Noter que les guillemets autour des valeurs de paramètre font partie de la syntaxe de la valeur ; Elles NE FONT PAS partie de la valeur elle-même. De plus, il est explicitement permis d'avoir un mélange de champs de continuation entre guillemets et sans guillemets.

4.   Valeur des paramètres Jeu de caractères et Informations de langage

Certaines valeurs de paramètre peuvent devoir être qualifiées avec des informations de jeu de caractères ou de langage. Il est clair qu'un nom distinctif de paramètre est nécessaire pour identifier quand ces informations sont présentes ainsi qu'une syntaxe spécifique pour les informations de la valeur elle-même. De plus, un mécanisme de codage léger est nécessaire pour s'accommoder des informations sur 8 bits dans les valeurs de paramètre.

Les astérisques ("*") sont réutilisés pour fournir l'indicateur de présence des informations de langage et de jeu de caractères et de l'utilisation du codage. Un double guillemet ("'") est utilisé pour délimiter les informations de jeu de caractères et de langage au début de la valeur de paramètre. Les signes de pourcentage ("%") sont utilisés comme fanion de codage, ce qui est en accord avec la RFC 2047.

Précisément, un astérisque à la fin d'un nom de paramètre agit comme un indicateur que les informations de jeu de caractères et de langage peuvent apparaître au début de la valeur de paramètre. Un seul guillemet est utilisé pour séparer les informations de jeu de caractères, de langage, et les informations de valeur réelle dans la chaîne des valeurs de paramètres, et un signe pourcentage est utilisé comme fanion pour les octets codés en hexadécimal. Par exemple :

Content-Type: application/x-stuff;

title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A

Noter qu'il est parfaitement admis de laisser en blanc le champ jeu de caractères ou langage. Noter aussi que les délimiteurs par simple guillemet DOIVENT être présents même lorsque une des valeurs du champ est omise. Cela arrive lorsque soit jeu de caractères soit langage, soit les deux, ne sont pas pertinents pour la valeur de paramètre en question. Cela NE DOIT PAS être fait pour indiquer un jeu de caractères ou un langage par défaut – les définitions de champ de paramètre NE DOIVENT PAS allouer de jeu de caractère ou de langage par défaut.

4.1   Combinaison de jeu de caractères, langage, et continuations de paramètre

Les informations de jeu de caractères et de langage peuvent être combinées avec le mécanisme de continuation de paramètre. Par exemple :

Content-Type: application/x-stuff;

title*0*=us-ascii'en'This%20is%20even%20more%20;

title*1*=%2A%2A%2Afun%2A%2A%2A%20;

title*2="isn't it!"

Noter que :

(1)   Les informations de langage et de jeu de caractères n'apparaissent qu'au début d'une valeur de paramètre donnée.

(2)   Les continuations ne donnent pas la faculté d'utiliser plus d'un jeu de caractère ou langage dans la même valeur de paramètre.

(3)   Une valeur présentée qui utilise plusieurs continuations peut contenir un mélange de segments codés et non codés.

(4)   Le premier segment d'une continuation DOIT être codé si les informations de langage et jeu de caractères sont données.

(5)   Si le premier segment d'une valeur de paramètre continué est codé, les délimiteurs de champ de langage et de jeu de caractères DOIVENT être présents même lorsque les champs sont laissés en blanc.

5.   Spécification du langage dans les mots codés

La RFC 2047 fournit la prise en charge des jeux de caractères non US-ASCII dans les commentaires d'en-tête de message de la RFC 822, les phrases, et tout champ de texte non structuré. Cela est fait en définissant une construction de mot codé qui peut apparaître dans l'un quelconque de ces endroits. Étant donné que ce sont des champs destinés à l'affichage, il est parfois nécessaire d'associer les informations de langage à des mots codés ainsi qu'au simple jeu de caractères. La présente spécification étend la définition d'un mot codé pour permettre l'inclusion de telles informations. Cela est fait simplement en mettant en suffixe la spécification du jeu de caractères avec un astérisque quivi par l'étiquette de langage. Par exemple :

From: =?US-ASCII*EN?Q?Keith_Moore?= <moore@cs.utk.edu>

6.   Traitement des valeurs de paramètre dans IMAP4

Les serveurs IMAP4 [RFC-2060] DEVRAIENT décoder les continuations de valeur de paramètre en générant les attributs fantômes BODY et BODYSTRUCTURE.

7.   Modifications de l'ABNF pour MIME

L'ABNF pour les valeurs de paramètre MIME donné dans la RFC 2045 est :

paramètre := attribut "=" valeur

attribut := jeton   ; La correspondance des attributs est TOUJOURS insensible à la casse.

La présente spécification change cet ABNF en :

paramètre := paramètre-régulier / paramètre-étendu

paramètre-régulierr := nom-de-paramètre-régulier "=" valeur

nom-de-paramètre-régulier := attribut [section]

attribut := 1*attribut-caractère

attribut-caractère := <tout CHAR (US-ASCII) excepté ESPACE, CTL, "*", "'", "%", ou tspecials>

section := section-initiale autres-sections

section-initiale := "*0"

autres-sections := "*" ("1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9") *CHIFFRE)

paramètre-étendur := (nom-initial-étendu "=" valeur-initiale-étendue) / (autres-noms-étendus "=" autres-valeurs-étendues)

nom-initial-étendu := attribut [section-initiale] "*"

autres-noms-étendus := attribut autres-sections "*"

valeur-initiale-étendue := [jeu-de-caractères] "'" [langage] "'" autres-valeurs-étendues

autres-valeurs-étendues := *(ext-octet / attribut-char)

ext-octet := "%" 2(CHIFFRE / "A" / "B" / "C" / "D" / "E" / "F")

jeu-de-caractères := <nom de jeu de caractères enregistré>

langage := <étiquette de langage enregistré [RFC-1766]>

L'ABNF donné dans la RFC 2047 pour les mots codés est :

mot-codé := "=?" jeu-de-caractères "?" codage "?" texte-codé "?="

La présente spécification change cet ABNF en :

mot-codé := "=?" jeu-de-caractères ["*" langage] "?" codage "?" texte-codé "?="

8.   Jeux de caractères qui permettent la spécification du langage

Il est vraisemblable qu'à l'avenir, certains jeux de caractères donneront la faculté d'étiqueter en ligne le langage. De telles facilités sont par nature plus souples que celles définies ici car elles permettent le changement de langage au milieu d'une chaîne.

Quand de telles facilités seront développées, si elles le sont, elles DEVRAIENT être utilisées de préférence à la faculté d'étiquetage de langue spécifiée ici. Noter que tous les mécanismes définis ici permettent l'omission des étiquettes de langue de façon a être capable de s'accommoder de ce possible usage à l'avenir.

9.   Considérations pour la sécurité

La présente RFC n'aborde pas les questions de sécurité et n'est pas estimée soulever de problèmer de séurité qui ne soit déjà endémique de la messagerie électronique et présent dans les mises en œuvre pleinement conformes de MIME.

10.   Références

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

[RFC1766]   H. Alvestrand, "Étiquettes pour l'identification des langues", mars 1995. (Obsolète, voirRFC3066, RFC3282) (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 parRFC2184, 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.)

[RFC2060]   M. Crispin, "Protocole d'accès au message Internet - version 4rev1", décembre 1996. (Remplace RFC1730) (Obsolète, voirRFC3501) (P.S.)

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

[RFC2130]   C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. Atkinson, M. Crispin, P. Svanberg, "Rapport de l'atelier Jeux de caractères de l'IAB tenu du 29 février au 1 er mars 1996", avril 1997. (Information)

[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 parRFC2184, RFC2231) (P.S.)

11.   Adresse des auteurs

12.   Déclaration de copyright

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

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.

---

We need Your Support. Make a Donation now! or

---