Résumé

  • RFC 5198 assemble UTF-8, NFC, état d’affectation, CRLF et restrictions sur les caractères de contrôle pour former Net-Unicode ; réussir le décodage UTF-8 ne suffit donc pas.
  • Une application peut dépendre de tables Unicode du système ou du langage qui évoluent sans changement de son code. Le reçu doit identifier ces tables et conserver la décision exacte d’admission et de normalisation.

L’égalité des versions cachait une dépendance

Les inventaires de production aiment les coordonnées simples : numéro de version, empreinte de l’image applicative, commit. Ces valeurs répondent à une question réelle — quels octets appartenant au programme ont été livrés ? — mais elles ne décrivent pas toutes les données consultées pendant son exécution.

RFC 5198 place le problème au centre de sa section sur les versions Unicode. Une application effectue rarement elle-même toutes les conversions et normalisations. Elle appelle des fonctions du système d’exploitation ou du langage. Ces fonctions peuvent être mises à jour sans modification du code applicatif ; le programme peut même ne disposer d’aucun moyen plausible de connaître la version Unicode ou la procédure de normalisation employée, ni de vérifier leur cohérence.

La conséquence n’est pas que toute mise à jour réécrit arbitrairement les chaînes anciennes. Le document s’appuie au contraire sur la stabilité NFC : une chaîne sans point non affecté, correctement normalisée, doit rester normalisée dans les versions futures. La frontière mobile est celle du répertoire. Un point non affecté se normalise d’abord vers lui-même ; lorsqu’une version ultérieure lui attribue un caractère, il peut entrer dans une nouvelle relation de normalisation. Le même binaire, lié à deux bases différentes, ne prend alors plus la même décision d’admission.

Net-Unicode ajoute un profil à l’encodage

RFC 3629 définit UTF-8. RFC 5198 ne se contente pas de le renommer. Il construit une forme d’échange textuelle destinée aux protocoles qui n’ont pas déjà précisé leur propre usage d’Unicode.

Les caractères doivent être encodés en UTF-8. Lorsqu’un protocole connaît la notion de ligne, celle-ci se termine par CRLF ; CR hors de CRLF n’est toléré que dans l’héritage déconseillé CR NUL. Les contrôles C1 U+0080 à U+009F sont interdits. IND, NEL, U+2028 et U+2029 ne remplacent pas CRLF. Un BOM initial est interdit. Les séquences devraient être normalisées en NFC avant transmission. Enfin, l’émetteur ne doit pas transmettre de point non affecté dans la version Unicode dont il dépend, et les versions d’Unicode et de NFC doivent être cohérentes.

Ces tests ont des objets différents. Le décodeur valide des octets. La base Unicode attribue ou non un point. NFC choisit une représentation canonique. La règle de ligne et de contrôles limite la grammaire du flux. Un unique champ « Unicode valide » efface la cause d’un rejet et rend toute comparaison entre serveurs équivoque.

Même le registre d’errata appelle à conserver les niveaux. Le texte publié étend à tort l’expression « plage ASCII » jusqu’à U+009F ; cette correction est seulement signalée, tandis que l’interdiction séparée des contrôles C1 est claire. L’erratum vérifié 1402 corrige uniquement « ci-dessous » en « ci-dessus ». Une implémentation doit documenter ce qu’elle applique, pas convertir silencieusement tout signalement en nouvelle norme.

La version de l’application ne suffit pas au rejeu

Supposons qu’un incident soit reproduit six mois plus tard. L’équipe remet en place le paquet applicatif exact et rejoue les mêmes octets. Si elle ne restaure pas également l’image hôte, le runtime de langue et les données Unicode, elle ne rejoue pas nécessairement la même admission.

RFC 5198 examine quatre échappatoires imparfaites : figer une version et maintenir la liste de ses points non affectés ; joindre une version à chaque texte ; inventer des règles absolument stables ; ou appliquer une variante de NFC qui rejette les points encore non affectés. La quatrième piste est discutée sous le nom de « Stable NFC ». Aucune ne transforme toutefois un simple numéro de version applicatif en preuve du traitement réel.

Le risque concerne aussi les contrôles de sécurité. Le RFC avertit qu’un texte volontairement non normalisé peut contourner une recherche naïve, par exemple dans un pare-feu. Si la passerelle normalise avec une table et l’application avec une autre, elles peuvent agir sur deux états différents du texte. Conserver seulement la décision finale — autorisé ou bloqué — masque l’entrée, la transformation et la version qui ont rendu cette décision possible.

Un reçu reproductible

Le reçu commence par le binaire mais descend jusqu’à ses dépendances : empreinte de l’application, image de base, runtime, version de la base de caractères Unicode et données NFC. Si la plateforme ne sait pas les exposer, cette ignorance doit apparaître comme telle.

Pour chaque flux sensible, il faut ensuite relier l’empreinte des octets reçus au résultat UTF-8, à la séquence de points de code, au verdict affecté/non affecté et à la version qui l’a produit. Les décisions sur BOM, usage privé, C0, C1, CR, LF, CR NUL, U+2028 et U+2029 restent séparées. L’empreinte avant normalisation, celle de la sortie NFC et l’indication « déjà NFC » permettent de distinguer validation et transformation.

Enfin, le contrôle qui a consommé ce texte doit être nommé : comparaison, filtrage, signature, stockage ou affichage. Sa décision n’est pas son effet. Un flux conforme à Net-Unicode peut encore être mal autorisé ; un rejet de forme ne prouve pas une attaque. RFC 5198 fournit un contrat d’échange. Le reçu opérationnel empêche ce contrat de devenir une simple étiquette verte.

Sources

  1. RFC 5198 — HTML
  2. RFC 5198 — texte
  3. Fiche RFC 5198
  4. Datatracker IETF : RFC 5198
  5. Historique du RFC 5198
  6. Références du RFC 5198
  7. Errata du RFC 5198
  8. RFC 3629 — UTF-8
  9. RFC 2277 — jeux de caractères et langues
  10. RFC 4690 — examen IAB des noms internationalisés
  11. RFC 3454 — Stringprep
  12. RFC 8264 — cadre PRECIS
  13. RFC 6365 — terminologie de l’internationalisation
  14. RFC 854 — Telnet
  15. RFC 698 — option ASCII étendu de Telnet
  16. Annexe Unicode no 15 — formes de normalisation
  17. Politique de stabilité d’Unicode
  18. Heng Lu — couches de réalité et pouvoir symbolique
  19. Heng Lu — spécification initiale minimale
  20. Heng Lu — primauté du code en fonctionnement