Résumé

  • RFC 3930 opposait, de façon volontairement exagérée, le document quasi statique regardé comme un tout au message éphémère dont les composants suivent des traitements différents.
  • Cette opposition fixe une frontière concrète pour l’extension, la canonicalisation, l’authentification sélective et les identifiants qui entrent en collision lorsque des fragments sont recomposés.

Le tout visible n’était pas l’unité de traitement

Dans RFC 3930, Donald Eastlake ne compare pas une spécification RFC au code qui l’exécute. Il compare deux manières de penser l’objet numérique. La première voit l’équivalent d’une feuille, destinée à une personne, dont la présentation participe au sens. La seconde voit un assemblage temporaire créé par un processus, enrichi par son état local, puis consommé ou relayé par plusieurs autres.

Le dossier RFC Editor classe le texte comme Informational. Les paragraphes DOCUM et PROTO sont des caricatures utiles, pas un recensement des pratiques. XML pouvait appartenir aux deux mondes. RFC 3023 identifiait ses types de média et RFC 3470 guidait son emploi dans les protocoles, sans transformer une représentation reconnaissable en machine à états.

Un champ peut provenir d’un calcul local, un autre d’un message antérieur et un troisième n’être lu que pour être transmis. Le contexte absent de l’écran peut décider du sens. Ainsi, un nom ou une date n’a pas besoin d’emporter toutes ses significations humaines possibles si le protocole définit déjà l’émetteur, le lecteur et l’action. Mais cette définition ne prouve ni consentement ni autorité. RFC 3552 organise l’analyse de sécurité; RFC 3852 organise des objets cryptographiques. Aucun des deux ne convertit un champ présent en résultat humain.

Les versions n’arrivaient pas ensemble

La vision protocolaire suppose que les extensions seront déployées de manière inégale. RFC 3930 recommande des étiquettes de version ou de fonction, une négociation quand elle est possible, des longueurs permettant d’ignorer l’inconnu et des indications de destination permettant à un intermédiaire de relayer sans comprendre. Ce sont des outils de coexistence, non des preuves de compatibilité.

Le problème a survécu aux formats. RFC 8259 laisse à JSON plusieurs choix de représentation; RFC 8785 définit ensuite une forme canonique destinée aux signatures et aux condensats. RFC 8949 traite l’encodage déterministe de CBOR. Ces textes prolongent la question sans être des mises en œuvre de RFC 3930.

La canonicalisation avait deux bords dangereux

Une reconstruction peut modifier des fins de ligne, un encodage de caractères, un contexte d’espace de noms ou une écriture numérique sans modifier ce que l’application juge important. RFC 3076 et RFC 3741 ont défini des formes canoniques XML; RFC 3275 a défini le traitement des signatures XML.

RFC 3930 refuse les deux raccourcis. Trop peu de canonicalisation rend la vérification cassante. Trop de canonicalisation peut faire vérifier des données dont le sens a changé. La bonne transformation correspond exactement à l’équivalence de l’application. De même, signer « tout » peut être faux lorsque les compteurs de sauts, l’historique de routage ou les marques locales doivent changer.

Le texte porte lui-même une petite discordance. La section 2.4.1 renvoie à [RFC3741], qui est bien le document d’exclusive canonicalisation. Sa bibliographie développe pourtant cette étiquette comme le document GMPLS de L. Berger, RFC 3471. La recherche d’errata ne signalait aucune correction correspondante le 7 octobre 2026. Ce défaut ne réfute pas l’analyse; il montre seulement qu’une étiquette lisible et l’objet effectivement référencé doivent être réconciliés.

Un identifiant local ne survivait pas forcément au montage

Des fragments provenant de plusieurs messages peuvent porter le même ID. Réécrire ces IDs casse des références enregistrées et parfois les signatures. Les qualifier hiérarchiquement protège l’unicité locale mais modifie l’ancre lorsque le fragment bouge. RFC 3930 privilégiait donc un identifiant aléatoire assez long lorsqu’une ancre globale était nécessaire.

Les deux perspectives convergent quand l’objet a peu de composants, change peu, traverse peu d’acteurs et vise surtout la lecture humaine. L’ordre de conception reste décisif: partir du graphe de traitement, puis ajouter les besoins documentaires. RFC 7990 définit séparément le modèle archivistique de la série RFC; publier un document n’est pas exécuter le protocole qu’il décrit.

Les textes de Heng Lu sur la spécification initiale minimale et l’adoption volontaire et la primauté du code en fonctionnement offrent ici une discipline éditoriale: une publication coordonne, tandis que l’implémentation, la validation, l’exploitation et l’usage établissent ce qui est devenu réel. Le document peut être visible comme un tout; les preuves demeurent distribuées entre ses composants.