Résumé

  • La RFC 2987 a placé charset et language dans le même mécanisme de caractéristiques tout en qualifiant le premier de capacité habituelle et le second de préférence habituelle.
  • Employer le nom principal d’un jeu de caractères et comparer une balise de langue comme un jeton entier réduisait les ambiguïtés sans prouver le décodage ni la compréhension.
  • Une valeur q ordonnait des prédicats pour une décision locale ; elle ne certifiait ni le rendu, ni la qualité de la voix, ni la satisfaction de l’utilisateur.

Le parallélisme trompeur des formulaires

La RFC 2987 ne construit pas un grand protocole. Elle remplit deux formulaires d’enregistrement fondés sur la procédure de la RFC 2506. charset reçoit le suffixe 31 dans l’arbre IETF des caractéristiques de média ; language, le suffixe 32. Le registre IANA les porte encore aujourd’hui côte à côte.

Cette proximité est utile. Un protocole de négociation peut parler d’une représentation sans créer son propre dialecte. Les valeurs sont des jetons enregistrés. Leur comparaison se fait par égalité, sans tenir compte des majuscules. La syntaxe de la RFC 2533 permet de relier des prédicats et de leur attribuer une qualité. Le vocabulaire est commun, mais l’évaluateur reste local.

Le piège apparaît lorsqu’on déduit la nature d’un prédicat de sa forme.

Pour charset, la RFC dit que la caractéristique est, pour la plupart des appareils, une capacité. Un appareil qui ne connaît pas un encodage ne peut normalement pas transformer ses octets en texte intelligible. Pour language, elle parle le plus souvent d’une préférence, non d’une exigence. Le mot « afficher » visait souvent la parole produite par ordinateur, mais la logique ne dépend pas de cette seule application : un utilisateur peut préférer une langue sans que l’appareil devienne techniquement incapable de présenter toute autre langue.

Une expression identique peut donc porter soit une frontière d’exécution, soit un ordre de choix.

Le jeu de caractères engage une chaîne matérielle

L’exemple de la RFC classe utf-8, iso-8859-1 et utf-16. Les coefficients ressemblent à un scrutin. Ils n’en sont pas un tant que les décodeurs n’existent pas.

Un prédicat charset=utf-8 peut correspondre au profil et échouer sur le chemin réel. L’étiquette peut contredire les octets. Le décodeur peut manquer ou être défectueux. Les caractères abstraits peuvent être corrects tandis que la police ne contient pas les glyphes. Le rendu peut réussir sans que le lecteur comprenne le texte. Chaque transition demande sa propre preuve.

La RFC 2913 avait enregistré type séparément. Cette séparation empêchait text/plain de promettre tous les encodages possibles. Reconnaître la famille du média et savoir décoder une représentation donnée sont deux capacités voisines, pas un même acquittement.

La question des alias rendait la discipline encore plus concrète. La RFC 2978 autorisait plusieurs noms pour un même jeu de caractères, mais imposait un nom principal et exigeait que chaque nom n’identifie qu’un seul jeu. La RFC 2987 déconseillait les alias dans les expressions : un outil pouvait les convertir vers le nom principal et modifier ainsi une construction qui semblait seulement transportée.

Employer le nom principal en minuscules stabilisait la comparaison. Cette canonicalisation ne validait ni la table de conversion, ni le programme qui l’exécutait. Elle supprimait un désaccord de vocabulaire, pas les erreurs de l’implémentation.

Le texte demandait aussi que la capacité charset accompagne toute capacité relative aux données textuelles. Dire « je traite du texte » sans exposer la condition d’encodage masquait précisément la limite que le correspondant devait tester.

La langue n’est pas un mur de silicium

L’exemple linguistique classe no-nynorsk, no-bokmaal et i-sami-no. Même opérateur, autre autorité.

La RFC 1766 composait les balises de langue à partir d’une étiquette principale et de sous-étiquettes. Elle avertissait pourtant que l’application devait traiter la balise complète comme un seul jeton. Les sous-étiquettes avaient une fonction administrative ; elles ne formaient pas une carte automatique de l’intercompréhension.

La RFC 2987 reprend cette règle : comparaison du jeton entier, sans considération de casse, sans comparaison des sous-étiquettes. Un préfixe commun ne permet pas de conclure qu’un lecteur comprend deux variantes, qu’une voix est acceptable ou qu’un contenu peut en remplacer un autre.

Mais l’échec d’égalité ne doit pas être automatiquement transformé en panne de capacité. L’utilisateur peut préférer une langue et accepter une autre plutôt que l’absence de service. À l’inverse, un repli silencieux peut lui fournir de manière répétée un contenu inutilisable. La bonne décision dépend des variantes disponibles, de la priorité exprimée et de la politique de l’application.

La norme coordonne les entrées de cette décision ; elle ne décide pas à la place de tous.

Ce que le poids ne pèse pas

Dans la RFC 2533, un coefficient de qualité qualifie un prédicat et vaut 1 par défaut lorsqu’il est absent. Le document ne définit pas une formule universelle pour combiner toutes les préférences. Une telle formule aurait transformé un langage commun en politique centrale.

q=1.0 signifie donc qu’un profil a placé ce prédicat au premier rang dans ce contexte. Il ne prouve pas que le profil est récent, que la variante existe, que la voix est naturelle, que le décodage réussit ou que l’utilisateur accomplit sa tâche.

Le reçu opérationnel doit conserver davantage : ensemble reçu, normalisation, version de l’évaluateur, règle locale, candidats disponibles, choix final, ressource d’exécution, rendu et résultat humain. Sans ces étapes, le journal « négociation réussie » remplace plusieurs réalités par une seule étiquette verte.

Le registre nomme ; le code tranche

La permanence des entrées IANA montre la valeur de la coordination. Des implémentations indépendantes peuvent partager les mêmes noms et la même égalité. Aucun registre n’installe pourtant un décodeur, une police, une synthèse vocale ou un corpus traduit.

Le producteur du profil choisit ce qu’il déclare. Le fournisseur de contenu choisit les variantes. L’évaluateur normalise, classe et applique un éventuel repli. L’utilisateur reçoit la conséquence. Cette distribution interdit d’attribuer au formulaire d’enregistrement le pouvoir de toute la chaîne.

La « spécification initiale minimale » de Lu Heng fournit une grille utile : fixer ce qui est nécessaire à l’interopérabilité, puis laisser les décisions futures à ceux qui exécutent le code. Ici, le minimum comprend les noms, les domaines de valeurs et la comparaison. Il ne comprend pas un arbitre mondial des préférences.

La liberté locale a cependant un coût de preuve. L’application qui durcit une préférence ou assouplit une capacité doit pouvoir expliquer son choix. Sinon, l’optimisation devient une autorité invisible.

La primauté du code en fonctionnement complète le diagnostic. Une balise valide décrit une proposition. Seule l’exécution montre si l’appareil a normalisé le nom, trouvé une égalité, sélectionné la représentation, décodé les octets, présenté le contenu et servi l’utilisateur.

Les couches sont distinctes : registre, expression, normalisation, comparaison, sélection, capacité, exécution, perception et résultat. La vérité d’une couche ne donne pas mandat pour parler au nom des suivantes.

Une divulgation de sécurité mesurée

Pour les deux balises, la RFC observe que révéler l’acceptation d’un jeu de caractères ou d’une langue pourrait aider légèrement un attaquant si un bogue d’affichage est déjà connu dans cet environnement. Elle ne cite ni produit ni incident.

Cette réserve suffit à rappeler qu’un profil de capacité n’est pas une décoration. Il dirige le trafic, révèle une surface et déclenche des attentes. Il convient de ne publier que ce qui sert la décision et de ne jamais prendre la déclaration pour une preuve de sûreté.

La leçon de la RFC 2987 tient dans son refus d’uniformiser le sens au nom de l’uniformité de la forme. Les deux balises pouvaient voyager dans la même machine syntaxique. Elles ne possédaient pas le même pouvoir.

L’une décrivait généralement ce que la machine pouvait faire. L’autre, ce que la personne souhaitait qu’elle fasse. Une infrastructure honnête conserve cette différence jusqu’au résultat.

Sources