Résumé
- RFC 3536 distinguait les octets encodés, les caractères abstraits, les systèmes d’écriture, les langues et les glyphes choisis par le moteur de rendu : aucun de ces niveaux ne prouve automatiquement le suivant.
- Ce glossaire de 2003 était informatif, incomplet et non normatif ; RFC 6365 l’a rendu obsolète en 2011. Son enseignement demeure : une forme lisible atteste un rendu, pas la langue ni le sens reçu.
Dans une gare, un panneau peut afficher un nom avec une typographie nette, sans bavure ni carré de remplacement. L’opérateur conclut volontiers que « les caractères passent ». Pourtant, la chaîne a pu employer une mauvaise étiquette d’encodage, normaliser sans trace, deviner la langue ou choisir une police de secours. Le panneau prouve qu’un moteur a trouvé une forme. Il ne prouve ni les octets de départ, ni la langue annoncée, ni la lecture faite par le voyageur.
Publié en mai 2003, RFC 3536 portait un titre volontairement modeste : Terminology Used in Internationalization in the IETF. Ce n’était ni une norme de codage, ni un profil d’interopérabilité. Les auteurs réunissaient un vocabulaire parce que les discussions techniques mélangeaient des réalités différentes. Ils précisaient que les définitions n’étaient pas normatives, que l’inventaire n’était pas complet et que le consensus manquait encore sur certains mots, notamment « langue ». La page d’errata figée ne présente aucune entrée ; cette absence ne transforme pas le glossaire en doctrine définitive.
Le trajet commence par les données codées. Des bits forment des octets ; un jeu de caractères indique comment ces octets conduisent à des caractères abstraits. RFC 3536 décrit le charset comme l’association d’un répertoire codé et d’un schéma d’encodage, désignée par un nom enregistré auprès de l’IANA. UTF-8, documenté pour l’Internet par RFC 3629, répond à cette question de décodage. Il ne dit pas si la phrase obtenue est du français, du wolof ou du japonais, ni si elle est correcte.
Le caractère se situe déjà ailleurs que son apparence. C’est un élément abstrait identifié par un nom et des propriétés. Le glyphe est une forme produite par le rendu. La police, le contexte et les règles de façonnage déterminent cette forme. Un caractère peut recevoir plusieurs glyphes ; plusieurs séquences peuvent paraître identiques ; une forme isolée peut rester ambiguë. L’œil observe donc un résultat sans pouvoir remonter, à lui seul, à la séquence qui l’a produit.
L’écriture ne suffit pas davantage à nommer la langue. Un même système graphique sert plusieurs langues, et une langue peut s’écrire dans plusieurs systèmes. La détection d’une écriture aide le moteur de rendu, mais elle ne fournit pas la langue. Les balises décrites par RFC 3066, puis par le cadre plus complet de RFC 5646, transportent une déclaration linguistique distincte. Une balise bien formée reste une métadonnée : elle ne certifie ni la qualité de la prose, ni son classement juste, ni sa compréhension.
RFC 2277 avait posé le but humain : un protocole n’a pas de langue naturelle, mais les chaînes qu’il véhicule sont destinées à des personnes. Accepter des octets non ASCII ne suffit donc pas à internationaliser un service. Il faut encore saisir, stocker, comparer, rechercher, trier, rendre visuellement ou par la voix et vérifier que le destinataire peut agir.
La normalisation montre à quel point la ressemblance visuelle est trompeuse. Unicode autorise des séquences distinctes mais canoniquement équivalentes. L’annexe UAX #15 définit des formes de normalisation ; RFC 5198 a ensuite fourni un format de préparation pour les échanges réseau. RFC 3536 retient surtout une responsabilité : le protocole doit indiquer où la normalisation intervient. Sans cette décision explicite, deux chaînes qui se ressemblent peuvent diverger dans une clé, ou deux archives différentes peuvent fusionner sans preuve conservée.
Cette histoire ne reprend pas le terrain de l’article consacré à RFC 5137. Celui-ci traite des échappements Unicode, des identifiants normalisés et de l’ambiguïté entre comptes. Ici, le sujet est la chaîne plus générale qui va des octets reçus au caractère, au contexte d’écriture et de langue, puis au glyphe. Une politique d’identifiant n’en est qu’un usage particulier.
Le classement fournit un autre révélateur. La collation est une convention humaine liée à une langue ; elle ne se réduit pas à l’ordre numérique des points de code. Deux communautés utilisant la même écriture peuvent attendre des ordres différents. Une base de données peut exécuter parfaitement son tri et produire un index inadapté au lecteur. Le journal « tri terminé » ne documente pas la pertinence de la collation choisie.
Le texte bidirectionnel sépare encore l’ordre en mémoire de l’ordre affiché. Une capture d’écran ne reconstitue pas nécessairement la séquence source ; le déplacement du curseur, la copie ou la synthèse vocale peuvent révéler une structure cachée. Et le rendu n’est pas uniquement visuel : RFC 3536 inclut les sorties sonores et tactiles. Un glyphe convenable peut coexister avec une prononciation fausse ou un braille inutilisable.
Il faut enfin dater l’autorité du document. RFC 3536 n’a jamais été une norme Internet. En septembre 2011, RFC 6365 a été publié comme BCP 166 après consensus et revue publique de l’IETF ; il rend explicitement RFC 3536 obsolète. RFC 7997 a plus tard modifié la politique relative aux caractères non ASCII dans les RFC. Cette évolution ne rend pas rétroactivement normatives les définitions de 2003.
La section sécurité de RFC 3536 dit simplement qu’elle ne traite pas la sécurité. Il convient de ne pas lui prêter un modèle de menace contemporain. On peut constater aujourd’hui que les ambiguïtés de codage, de direction ou de présentation ont des conséquences ; la conclusion historique sûre est seulement qu’un système devient difficile à auditer lorsqu’il efface les frontières entre données, texte, langue et présentation.
Une preuve complète conserve donc les octets et leur étiquette, le décodage, la validation de la séquence, la forme de normalisation et son emplacement, la provenance de la balise de langue, les segments d’écriture et de direction, le moteur de façonnage, la police demandée et la police de secours, la sortie visuelle, sonore ou tactile, la collation retenue et enfin un test auprès du public concerné. Le glyphe lumineux ne ferme qu’une étape.
Sources
- RFC 3536 — HTML
- RFC 3536 — texte brut
- Notice RFC Editor
- Fiche IETF Datatracker
- Historique IETF Datatracker
- Errata de RFC 3536
- RFC 2277 — jeux de caractères et langues
- RFC 3066 — balises de langue
- RFC 5646 — cadre actuel des balises de langue
- RFC 3629 — UTF-8
- RFC 5198 — Unicode pour les échanges réseau
- RFC 6365 — terminologie, BCP 166
- RFC 7997 — caractères non ASCII dans les RFC
- Registre IANA des jeux de caractères
- Annexe Unicode no 15
- Modèle de caractères du W3C
- Heng Lu — Running Code Is Primary
- Heng Lu — On Reality Layers
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
