Résumé

  • La RFC 3269 considérait le multicast fiable comme une famille de conceptions dépendantes des applications, et non comme un transport universel. Elle a transformé l’approche par blocs en contrat documentaire : chaque composant réutilisable devait exposer son champ d’application, ses interfaces, ses dépendances et ses limites de défaillance ; une instanciation de protocole devait, elle, décrire le système complet.
  • Son avertissement central était compositionnel : deux composants peuvent fonctionner par paires et échouer une fois réunis. La réutilisation est donc un objectif de conception, pas une preuve de compatibilité, de sûreté, de déploiement ou d’adoption.

Le problème de frontières derrière la modularité

Le Reliable Multicast Transport (RMT) partait d’un décalage concret. Les applications ne demandaient pas une seule forme de fiabilité : distribution de fichiers, collaboration interactive et diffusion en continu différaient par la taille des groupes, le délai, l’ordre des messages, le nombre d’émetteurs et la tolérance aux livraisons incomplètes. La RFC 2357 avait déjà fait de ces différences et des effets sur la congestion des motifs d’examen. La RFC 3269 posait une autre question : si aucun protocole unique ne convient à tous les usages, que doit révéler une spécification avant que ses éléments puissent être réutilisés ?

La réponse n’était pas de prétendre que chaque bloc est indépendant. La RFC 3269 reconnaissait que certains blocs dépendent du contexte. A et B peuvent fonctionner ensemble, tout comme B et C, alors que A, B et C réunis peuvent échouer. Une dépendance invisible dans une combinaison peut devenir une incompatibilité dans une autre. Le dessin d’une boîte sur un schéma ne prouve pas que sa frontière est réelle.

Le document demandait donc à chaque spécification de bloc de justifier son niveau de granularité, de décrire ses fonctions et interfaces externes, ses cas d’usage, ses défaillances connues et leur détection éventuelle, les environnements et blocs incompatibles, ainsi que les questions de sécurité et d’identifiants lorsque pertinentes. Les champs d’en-tête et exigences entre blocs devaient également être explicites si nécessaire. Un concepteur pouvait alors juger si le bloc convenait à un nouveau scénario, sans déduire sa portabilité de son nom.

Un composant n’est pas le protocole assemblé

La RFC 3269 traçait une seconde frontière autour de l’instanciation de protocole, le document qui réunit les blocs en un protocole complet. Celui-ci devait préciser l’application et l’échelle visées, les environnements inclus et exclus, les faiblesses connues, l’architecture, les composants choisis, leurs interactions et les compromis retenus. Il devait également donner les algorithmes et formats de paquets complets, plutôt que de laisser l’implémentation deviner ce qu’un bloc abstrait ne spécifiait pas.

La déclaration de conformité précisait l’unité de l’affirmation : l’instanciation, avec les documents de blocs qu’elle cite, devait spécifier complètement un protocole RMT fonctionnel au regard des exigences antérieures de la RFC 2357. Cela ne transformait pas la RFC 3269 en rapport de test et ne garantissait pas l’interopérabilité d’une implémentation. Le texte précisait plutôt quelles pièces documentaires devaient permettre d’évaluer l’expression « protocole fonctionnel ».

Une règle sur les formats de paquets est révélatrice : une instanciation RMT devait d’abord définir un usage sur UDP. L’attribution d’un numéro de protocole IP dédié était reportée jusqu’à ce que le protocole soit suffisamment déployé et compris. Le document séparait ainsi l’achèvement de la conception d’une allocation rare dans le registre et d’une éventuelle adoption ultérieure. Cette règle exprime une frontière normative, pas la preuve qu’un protocole donné a été largement déployé.

La RFC 3048 décrivait déjà le partage entre blocs réutilisables et noyaux propres aux protocoles. La RFC 3269 fournissait aux auteurs les obligations qui rendaient ce partage lisible. En 2009, la RFC 5651 indiquait explicitement suivre ses recommandations en actualisant la spécification antérieure du bloc LCT : c’est un exemple traçable de filiation documentaire. Cette citation montre une continuité de méthode, non une conformité universelle ou un résultat de déploiement.

La leçon historique n’est pas que « la modularité gagne ». La RFC 3269 conditionnait la réutilisation à la divulgation du périmètre et faisait de l’exhaustivité une propriété du protocole assemblé, pas de chacun de ses composants pris isolément. Elle pouvait améliorer ce que les auteurs rendaient examinable. Elle ne pouvait pas rendre sûre par simple déclaration la composition de spécifications distinctes.

Sources