3. Modifications des champs d'en-tête de message

Afin de permettre des caractères Unicode non ASCII dans les valeurs de champs, la définition d'en-tête de [RFC5322] est étendue pour prendre en charge le nouveau format. Les sections suivantes spécifient les modifications nécessaires à l'ABNF du RFC 5322.

Les règles de syntaxe non mentionnées ci-dessous restent définies comme dans [RFC5322].

Notez que ce protocole ne modifie pas les règles du RFC 5322 relatives à la définition des noms de champs d'en-tête. Les corps des champs d'en-tête peuvent contenir des caractères Unicode, mais les noms des champs d'en-tête eux-mêmes doivent être composés uniquement de caractères ASCII.

Notez également que les messages dans ce format nécessitent l'utilisation de l'extension SMTPUTF8 [RFC6531] pour être transférés via SMTP.

3.1. Syntaxe et normalisation UTF-8

Les caractères UTF-8 peuvent être définis en termes d'octets à l'aide de l'ABNF suivante [RFC5234], tirée de [RFC3629]:

UTF8-non-ascii  =   UTF8-2 / UTF8-3 / UTF8-4

UTF8-2          =   <Defined in Section 4 of RFC3629>

UTF8-3          =   <Defined in Section 4 of RFC3629>

UTF8-4          =   <Defined in Section 4 of RFC3629>

Voir [RFC5198] pour une discussion de la normalisation Unicode; la forme de normalisation NFC [UNF] devrait (SHOULD) être utilisée. En réalité, si l'on veut faire correctement de l'internationalisation, l'un des objectifs les plus souvent cités est de permettre aux personnes d'écrire correctement leur nom. Comme de nombreuses parties locales de boîtes aux lettres reflètent des noms de personnes, ce principe s'applique aussi aux boîtes aux lettres. La forme de normalisation NFKC [UNF] ne devrait pas (SHOULD NOT) être utilisée, car elle peut perdre des informations nécessaires pour orthographier correctement certains noms dans certaines circonstances inhabituelles.

3.2. Extensions syntaxiques au RFC 5322

Les règles suivantes étendent la syntaxe ABNF définie dans [RFC5322] et [RFC5234] afin de permettre du contenu UTF-8.

VCHAR   =/  UTF8-non-ascii

ctext   =/  UTF8-non-ascii

atext   =/  UTF8-non-ascii

qtext   =/  UTF8-non-ascii

text    =/  UTF8-non-ascii
              ; note that this upgrades the body to UTF-8

dtext   =/  UTF8-non-ascii

Les modifications qui précèdent signifient que les constructions suivantes autorisent désormais l'UTF-8:

1. Le texte non structuré (unstructured text), utilisé dans des champs d'en-tête tels que "Subject:" ou "Content-description:".

2. Toute construction utilisant des atomes, y compris mais sans s'y limiter les parties locales des adresses et des Message-ID. Cela inclut les adresses des clauses "for" des champs d'en-tête "Received:".

3. Les chaînes entre guillemets (quoted strings).

4. Les domaines (domains).

Notez que les noms de champs d'en-tête ne figurent pas dans cette liste; ils restent limités à l'ASCII.

3.3. Utilisation d'UTF-8 sur 8 bits dans les Message-ID

Les implémenteurs d'algorithmes de génération de Message-ID peuvent (MAY) préférer restreindre leur sortie à l'ASCII, car cela présente certains avantages, par exemple lors de la construction des champs d'en-tête "In-reply-to:" et "References:" dans des fils de discussion de listes de diffusion où certains expéditeurs utilisent des adresses internationalisées et d'autres non.

3.4. Effets sur les limites de longueur de ligne

La section 2.1.1 de [RFC5322] limite les lignes à 998 caractères et recommande que les lignes soient limitées à 78 caractères seulement. Cette spécification porte la première limite à 998 octets. (Notez qu'en ASCII, les octets et les caractères sont effectivement identiques, mais ce n'est pas vrai en UTF-8.) La limite de 78 caractères reste définie en termes de caractères, et non d'octets, car elle vise à traiter des problèmes de largeur d'affichage et non de longueur de ligne.

3.5. Modifications des restrictions d'encodage des types de messages MIME

Cette spécification met à jour la section 6.4 de [RFC2045]. [RFC2045] interdit d'appliquer un encodage de transfert de contenu à tout sous-type de "message/". Cette spécification assouplit cette règle -- elle permet aux types MIME nouvellement définis d'autoriser l'encodage de transfert de contenu, et elle autorise l'encodage de transfert de contenu pour message/global (voir la section 3.7).

Contexte: normalement, le transfert de message/global s'effectue dans des canaux 8-bit-clean, et les parties de corps ont des encodages "identity", c'est-à-dire qu'aucun décodage n'est nécessaire.

Mais dans le cas où un message contenant un message/global est rétrogradé de 8 bits à 7 bits comme décrit dans [RFC6152], un encodage peut devoir être appliqué au message. Si le message voyage plusieurs fois entre un environnement 7 bits et un environnement mettant en oeuvre ces extensions, plusieurs niveaux d'encodage peuvent se produire. Cela devrait être rarement observé en pratique, et la complexité potentielle des autres façons de traiter le problème est jugée supérieure à la complexité consistant à autoriser des encodages imbriqués lorsque cela est nécessaire.

3.6. Utilisation des mots codés MIME

La facilité des mots codés MIME [RFC2047] permet de placer du texte non ASCII, mais uniquement dans un sous-ensemble des emplacements autorisés par cette extension. En outre, les mots codés sont nettement plus complexes puisqu'ils autorisent l'utilisation de jeux de caractères arbitraires. En conséquence, les mots codés ne devraient pas (SHOULD NOT) être utilisés lors de la génération des champs d'en-tête des messages employant cette extension. Les agents peuvent (MAY), lorsqu'ils intègrent du contenu provenant d'un autre message, convertir l'usage des mots codés en usage direct de l'UTF-8.

Notez qu'il faut prendre soin de décoder les mots codés, car les résultats obtenus après remplacement d'un mot codé par son équivalent décodé en UTF-8 peuvent être syntaxiquement invalides. Les processeurs qui choisissent de décoder les mots codés ne doivent pas (MUST NOT) générer de champs syntaxiquement invalides.

3.7. Le type de média message/global

Les messages internationalisés dans ce format ne doivent (MUST) être transmis que comme autorisé par [RFC6531] ou au sein d'un environnement non SMTP prenant en charge ces messages. Un message est un "message/global" si:

• il contient des valeurs d'en-tête UTF-8 sur 8 bits telles que spécifiées dans ce document, ou

• il contient des valeurs UTF-8 sur 8 bits dans les champs d'en-tête des parties de corps.

Le contenu d'une partie message/global est par ailleurs identique à celui d'une partie message/rfc822.

Si un objet de ce type est envoyé à un système 7 bits uniquement, un encodage de transfert de contenu approprié doit (MUST) lui être appliqué. (Notez qu'un système conforme à MIME qui ne reconnaît pas message/global est censé le traiter comme "application/octet-stream" comme décrit à la section 5.2.4 de [RFC2046].)

L'enregistrement est le suivant:

Type name: message

Subtype name: global

Required parameters: none

Optional parameters: none

Encoding considerations: tout encodage de transfert de contenu est autorisé. Les encodages de transfert de contenu 8 bits ou binaires sont recommandés là où ils sont autorisés.

Security considerations: voir la section 4.

Interoperability considerations: ce type de média fournit une fonctionnalité similaire au type de contenu message/rfc822 pour les messages électroniques dotés d'en-têtes internationalisés. Lorsqu'il est nécessaire d'intégrer ou de renvoyer un tel contenu dans un autre message, il existe généralement la possibilité d'utiliser ce type de média et de laisser le contenu inchangé, ou de convertir le contenu en message/rfc822. Chacun de ces choix interopérera avec la base installée, mais avec des propriétés différentes. Les systèmes qui ne connaissent pas les en-têtes internationalisés traiteront généralement une partie message/global comme une pièce jointe inconnue, alors qu'ils comprendront la structure d'un message/rfc822. Toutefois, les systèmes qui comprennent message/global offriront une fonctionnalité supérieure au résultat d'une conversion en message/rfc822. Le choix le plus interopérable dépend du logiciel déployé.

Published specification: RFC 6532

Applications that use this media type: les serveurs SMTP et les clients de messagerie qui prennent en charge la génération ou l'analyse de multipart/report. Les clients de messagerie qui transfèrent en pièce jointe des messages dont les en-têtes sont internationalisés.

Additional information:

Magic number(s): none

File extension(s): l'extension ".u8msg" est suggérée.

Macintosh file type code(s): un identifiant de type uniforme (UTI) "public.utf8-email-message" est suggéré. Il est conforme à "public.message" et à "public.composite-content", mais pas nécessairement à "public.utf8-plain-text".

Person & email address to contact for further information: voir la section des adresses des auteurs de ce document.

Intended usage: COMMON

Restrictions on usage: il s'agit d'un type de média structuré qui intègre d'autres types de médias MIME. Un encodage de transfert de contenu 8 bits ou binaire devrait (SHOULD) être utilisé, sauf si ce type de média est envoyé sur un transport 7 bits uniquement.

Author: voir la section des adresses des auteurs de ce document.

Change controller: IETF Standards Process