Résumé

  • Dans RFC 2130, trois composantes décrivent normalement le texte sur le fil : le jeu de caractères codés, le schéma de codage en octets et la syntaxe de transfert. La langue, les conventions locales, la culture et la mise en page relèvent d'autres preuves.
  • Les valeurs MIME enregistrées et le couple ISO 10646/UTF-8 étaient des recommandations pour rendre les choix explicites, non l'abolition des autres jeux ni la preuve d'une adoption générale.

La stabilité d'une commande

Prenons une réponse d'erreur SMTP. La commande que la machine analyse et l'explication destinée à un être humain occupent le même échange, mais n'ont pas le même droit de changer. RFC 2130 déconseillait de traduire la mécanique du protocole, en donnant l'exemple d'une variante localisée de MAIL FROM. Une explication lisible par l'utilisateur, elle, pouvait bénéficier d'une langue et d'un jeu de caractères adaptés, à condition qu'une extension les définisse. La question n'était donc pas de choisir entre anglais et multilinguisme, mais de reconnaître qui interprète chaque chaîne.

L'atelier invité par l'IAB s'est tenu les 29 février et 1er mars 1996. Son compte rendu d'avril 1997 est Informational : il ne crée pas de norme Internet. Les participants voyaient les mêmes mots recouvrir des décisions différentes dans le courrier, les annuaires et le Web. Ils cherchaient un cadre qui puisse expliquer une transmission sans casser les protocoles existants.

Trois opérations avant la lecture

Le jeu de caractères codés, ou CCS, attribue des nombres à des caractères abstraits. Le schéma de codage, CES, représente ces valeurs en octets. La syntaxe de transfert, TES, adapte les données encodées aux contraintes d'un canal. ISO 10646, UTF-8 et Base64 illustrent respectivement ces fonctions; les confondre efface la cause d'une erreur. Le rapport compte quatre autres étages : langue, locale pour des usages tels que dates ou monnaies, culture et disposition visuelle.

Il concentre ses prescriptions sur le transport, tout en observant que l'identification de la langue peut améliorer le choix des glyphes et la recherche documentaire. Décoder correctement n'est pas encore présenter correctement.

L'étiquette compte autant que les octets. Dans MIME, charset peut couvrir ensemble le CCS et le CES, tandis que Content-Transfer-Encoding indique la transformation de transport. Le rapport reconnaissait que la pratique MIME ne découpait pas toujours nettement ses catégories théoriques. Il proposait des valeurs enregistrées pour nommer jeux et langues, sauf mécanisme existant, documenté et fiable. Deviner l'encodage d'après le pays d'origine n'en était pas un. Un protocole pouvait aussi fixer son choix, intégrer un signal, l'attacher à l'enveloppe ou négocier; chacun de ces chemins exige une preuve différente.

Noms publics, noms privés, contenu

La distinction se prolonge dans les identifiants. Le rapport rappelait la recommandation de RFC 1958 sur les noms publics largement visibles en ASCII insensible à la casse, notamment les noms DNS et éléments textuels des protocoles. Exiger le même cadre d'un nom de dossier privé dans une boîte aux lettres serait irréaliste. Pour un ancien protocole ASCII, l'arrivée de UTF-8 supposait une négociation de version ou de jeu et une solution compatible de repli. Le contenu des messages, bases de données et pages HTML demandait quant à lui la prise en charge de plusieurs jeux et des informations applicatives pertinentes.

Recommander ISO 10646 comme CCS et UTF-8 comme CES pour les nouveaux protocoles textuels n'était pas imposer un réglage unique à tout l'Internet. Le besoin de compatibilité pouvait conserver le défaut historique; une voie limitée à sept bits pouvait nécessiter une transformation supplémentaire. Le rapport ne fixait pas de TES universelle et ne proscrivait pas les autres jeux. Il éclairait une décision d'ingénierie, sans mesurer le nombre de systèmes qui l'auraient suivie.

Les articles consacrés à RFC 2044, RFC 2066, RFC 2070 et RFC 2152 décrivent respectivement un format d'octets, une négociation Telnet, le décodage HTML et un transport de courrier sur sept bits. Le propre sujet de RFC 2130 est la frontière entre ces contrats et la lecture humaine, non la substitution d'une solution à toutes les autres.

Sources et portée

Les notes de Lu Heng sur la preuve par le réel et le code exécuté sont ici un éclairage rétrospectif, non un témoignage sur les intentions des auteurs. Le texte de 1997 n'établit ni une diffusion universelle ni la lisibilité effective de chaque document multilingue.