11. Questions supplémentaires
Cette section identifie les questions qui ne sont pas couvertes ou non couvertes de manière exhaustive dans le cadre de cet ensemble de spécifications, mais qui nécessiteront une révision continue dans le cadre du déploiement de l'adresse e-mail et de l'internationalisation des en-têtes.
11.1. Impact sur les URI et les IRI
Le schéma [RFC6068], et sa discussion dans la spécification de l'identificateur de ressources internationalement reconnu (IRI) [RFC3987], pourraient devoir être modifiés lorsque ce travail sera terminé et normalisé.
11.2. Utilisation des adresses électroniques comme identifiants
Il existe un certain nombre d'endroits dans l'utilisation contemporaine d'Internet où les adresses e-mail sont utilisées comme identifiants pour les individus, y compris comme identifiants pour les serveurs Web qui prennent en charge certains sites de commerce électronique et dans certains certificats X.509 [RFC5280]. Ces documents ne traitent pas ces utilisations, mais il est raisonnable de s'attendre à ce que certaines difficultés soient rencontrées lorsque des adresses internationalizées seront utilisées pour la première fois dans ces contextes, dont beaucoup ne peuvent même pas gérer la gamme complète d'adresses autorisées aujourd'hui.
11.3. Mots codés, messages signés et rétrogradation
Une caractéristique particulière du format du courrier électronique est sa persistance: les MUA doivent traiter aussi bien les messages envoyés il y a plusieurs décennies que ceux remis quelques secondes auparavant. Les MUA et les logiciels de filtrage, tels que Sieve [RFC5228], devront donc continuer à accepter et à décoder les champs d'en-tête utilisant le mécanisme des « mots codés » [RFC2047] pour représenter des caractères non ASCII. Des extensions de POP3 [RFC1939] et d'IMAP [RFC3501] prévoient la mise à niveau automatique, par le serveur POP3 [RFC5721bis-POP3] ou IMAP [RFC5738bis-IMAP], des messages qui transportent sous forme codée des informations non ASCII, notamment le décodage RFC 2047. Certaines structures de message et certains types de contenu MIME ne permettent toutefois pas cette opération, ou celle-ci aurait des effets secondaires inacceptables.
Par exemple, les parties de message qui sont cryptographiquement signées, en utilisant par exemple S/MIME [RFC5751] ou Pretty Good Privacy (PGP) [RFC3156], ne peuvent pas être mises à niveau du formulaire RFC 2047 vers des caractères UTF-8 normaux sans casser la signature. De même, les parties de message qui sont cryptées peuvent contenir, lorsqu'elles sont décryptées, des champs d'en-tête qui utilisent le codage RFC 2047; de tels messages ne peuvent pas être " complètement " mis à niveau sans accès aux clés cryptographiques.
Des problèmes similaires peuvent survenir si les messages sont signés puis dégradés par la suite, par exemple, comme discuté à la section 8.1, puis une tentative est faite de les mettre à niveau vers la forme originale et de vérifier les signatures. Même les changements très subtils qui peuvent résulter des algorithmes pour dégrader et ensuite améliorer à nouveau peuvent suffire à invalider les signatures s'ils affectent les en-têtes des parties du corps primaires ou MIME. Lorsque les signatures sont présentes, la dégradation doit être effectuée avec extrême soin si du tout.
11.4. Autres utilisations des parties locales
Les parties locales servent parfois à construire des étiquettes de domaine. Par exemple, la partie locale « user » de l'adresse [email protected] peut être convertie en nom d'hôte user.domain.example, avec son espace Web à l'adresse http://user.domain.example, et avec des adresses génériques telles que [email protected].
Ces régimes sont évidemment limités par, entre autres, les règles SMTP pour les noms de domaine et ne fonctionneront pas sans nouvelles restrictions pour les autres parties locales.
11.5. Formats d'encapsulation non standard
Certaines applications utilisent des formats similaires au format application/mbox [RFC4155] au lieu du message/digest form défini dans la RFC 2046, section 5.1.5 [RFC2046] pour transférer plusieurs messages en unités uniques. Dans la mesure où ces applications supposent que tous les messages stockés utilisent le format message/rfc822 décrit dans la RFC 2046, section 5.2.1 [RFC2046] avec des en-têtes de message ASCII, ils ne sont pas prêts pour les extensions spécifiées dans cette série de documents, et des mesures spéciales peuvent être nécessaires pour les détecter et les traiter correctement.