Résumé

  • RFC 2277 imposait aux spécifications de distinguer le protocole du texte, d'identifier le charset, de pouvoir utiliser UTF-8 et de prévoir le transport d'une information de langue.
  • Ces obligations rendaient les choix auditables par le processus de normalisation ; elles ne prouvaient pas les capacités d'un destinataire, le résultat d'une négociation, le rendu ni la compréhension humaine.

Publié en janvier 1998 comme BCP 18, RFC 2277 n'était pas un nouveau format de texte. Il décrivait la politique appliquée par l'IESG aux protocoles soumis au processus de normalisation. L'annonce contemporaine de l'IESG résumait le seuil : un protocole textuel devait pouvoir utiliser UTF-8 et porter des étiquettes de langue, faute de quoi une dérogation devait être justifiée.

Cette autorité visait le document de spécification. Elle obligeait ses auteurs à exposer leurs décisions. Les éléments qui ressemblaient à des mots devaient être classés : jetons stables du protocole ou texte destiné à l'être humain. Lorsqu'une autre couche recevait la responsabilité de l'internationalisation, le groupe devait s'assurer que cette responsabilité n'était pas simplement abandonnée. Même les noms devaient être décrits comme internationalisés ou limités à US-ASCII.

Le charset avait une fonction précise : nommer les règles qui transforment une suite d'octets en suite de caractères. Toute donnée caractère devait identifier son charset, et tout protocole textuel devait pouvoir employer UTF-8. Les systèmes existants pouvaient conserver un autre défaut et d'autres charsets enregistrés. La politique ne prétendait donc pas qu'une seule valeur avait déjà remplacé tous les contrats antérieurs.

Dans une conversation directe, les parties peuvent négocier une représentation. Pour un courriel différé ou des données stockées, il n'existe souvent aucune conversation : le producteur attache alors une déclaration aux données. Ces deux traces ont des forces différentes. Une négociation montre une préférence proposée et une sélection. Une étiquette stockée montre ce qu'un producteur affirme. Ni l'une ni l'autre ne prouve que les octets sont valides, que le logiciel possède le décodeur ou que les caractères seront visibles.

La politique linguistique était tout aussi soigneusement bornée. Le protocole devait offrir un moyen bien défini de porter la langue, sans exiger que chaque texte fournisse effectivement cette information. RFC 2277 recommandait alors les étiquettes de RFC 1766. Une langue restait distincte d'une locale POSIX, laquelle peut déterminer tri, dates ou monnaie. Le destinataire pouvait suivre ou ignorer l'opinion de l'expéditeur sur ces conventions.

Ainsi, fr ne signifie pas « compris par cette personne ». Une préférence Accept-Language peut orienter un serveur, mais RFC 2068 rappelait que l'intelligibilité dépend de l'utilisateur. Une correspondance par préfixe ne certifie pas que chaque variante est comprise. RFC 1766 précisait en outre qu'une étiquette de langue ne permet pas toujours de choisir correctement le rendu d'un charset, notamment dans un texte mêlant japonais et chinois.

Le mécanisme de gouvernance le plus utile de RFC 2277 se trouve dans sa recommandation d'une section « Internationalization Considerations », près de Security Considerations. Elle rassemble le lieu du texte, les représentations disponibles, le transport de la langue, la négociation et les responsabilités laissées aux autres couches. C'est le reçu d'une décision de conception. Ce n'est pas le reçu d'une implémentation ni celui d'un lecteur.

La nuance est renforcée par la section sécurité du document : un avertissement dans une langue étrangère peut conduire à un comportement inapproprié, et plusieurs versions linguistiques peuvent manquer de cohérence. Même un décodage parfait ne résout donc pas la gouvernance du sens.

L'apport historique de RFC 2277 fut de rendre les choix contestables avant la publication d'une norme. Il faut conserver la même discipline après publication : séparer déclaration, support, sélection, décodage, présentation et compréhension.

Sources et limites

Les sources établissent la politique de 1998, son origine dans l'atelier RFC 2130, les mécanismes contemporains de MIME, HTTP et des étiquettes de langue, ainsi que l'évolution de la définition d'UTF-8. Elles ne mesurent aucun déploiement et n'observent aucun lecteur particulier.