Résumé
- RFC 3407 permettait d’annoncer ce qu’un terminal pouvait accepter à cet instant sans choisir la configuration de la session.
- La déclaration, la sélection par une négociation ultérieure et le fonctionnement constaté du média formaient trois preuves distinctes.
SDP décrivait une session, mais ses lignes média servaient aussi d’inventaire. Inscrire plusieurs formats pouvait signifier qu’ils appartenaient tous à la configuration active. Or un équipement limité par la mémoire ou les processeurs de signal savait parfois utiliser chacun séparément, jamais tous simultanément. La description confondait état réel et possibilités.
RFC 3407 ajouta donc un mécanisme minimal, lisible par les anciens systèmes parce que ses nouveaux attributs pouvaient être ignorés. Les capacités supplémentaires n’étaient pas des offres acceptées. Elles devenaient seulement des entrées possibles pour une négociation conduite ailleurs, notamment par le modèle offre-réponse.
Le texte interdit précisément l’inférence tentante : recevoir un format dans l’ensemble de capacités ne permettait pas de supposer qu’une tentative limitée à ce format réussirait. Les paramètres pouvaient manquer, les ressources changer, la combinaison être impossible ou le pair préférer autre chose. La capacité rendait l’essai légitime, non son résultat certain.
L’ensemble était complet et remplaçable. Un seul numéro de séquence couvrait toutes les descriptions. Dès qu’un nouvel ensemble arrivait, l’ancien ne devait plus être utilisé. Le compteur avançait modulo 256, mais un récepteur pouvait avoir manqué des messages; un trou ne justifiait donc pas le rejet. Ce numéro marquait une époque de déclaration, pas une livraison continue prouvée.
La portée empêchait aussi les extrapolations. Une capacité de niveau session s’appliquait aux flux du type indiqué. Une capacité de niveau média restait attachée à sa ligne, même si elle décrivait un autre type. Sans flux correspondant, une capacité de session avait une portée indéfinie, sauf dans une session à flux unique. L’emplacement faisait partie du contrat.
Les paramètres complétaient le format. cpar pouvait déclarer une condition de format ou de bande passante; les variantes minimale et maximale formaient une plage unique. Négocier sans respecter cette condition pouvait échouer alors que la déclaration initiale restait honnête.
Les numéros de capacités étaient des poignées locales à un ensemble donné. Leurs trous ne suffisaient pas davantage à invalider la liste. Une autre procédure pouvait les référencer, mais RFC 3407 ne transformait pas cette référence en accord. Sa limite était volontaire.
La renégociation de paramètres sensibles ajoutait un risque. Sans authentification et conception prudente, un adversaire pouvait provoquer une dégradation de sécurité ou multiplier les renégociations jusqu’au déni de service. Une option disponible n’était pas nécessairement une option sûre à sélectionner.
RFC 5939 apporta plus tard un cadre comprenant capacités, configurations potentielles, configuration réelle et règles offre-réponse. Il recommandait son usage aux nouvelles implémentations et autorisait une double déclaration pour les pairs anciens. Il n’abrogea pas formellement RFC 3407; surtout, sa procédure de négociation n’utilisait pas les anciennes descriptions. La coexistence n’effaçait pas la frontière des décisions.
Cette histoire rappelle qu’un catalogue technique ne prouve ni une décision commune ni un résultat. Il faut conserver séparément ce que chaque terminal annonçait, ce que les deux parties ont choisi et ce que le média a réellement transporté.
Sources
- https://www.rfc-editor.org/rfc/rfc3407.html
- https://www.rfc-editor.org/rfc/rfc3407.txt
- https://www.rfc-editor.org/info/rfc3407/
- https://datatracker.ietf.org/doc/rfc3407/
- https://datatracker.ietf.org/doc/rfc3407/history/
- https://datatracker.ietf.org/doc/rfc3407/references/
- https://www.rfc-editor.org/errata_search.php?rfc=3407
- https://www.rfc-editor.org/rfc/rfc2327.html
- https://www.rfc-editor.org/rfc/rfc3264.html
- https://www.rfc-editor.org/rfc/rfc5939.html
- https://www.rfc-editor.org/rfc/rfc5888.html
- https://www.rfc-editor.org/rfc/rfc4566.html
- https://www.rfc-editor.org/rfc/rfc8866.html
- https://www.rfc-editor.org/rfc/rfc3551.html
- https://www.rfc-editor.org/rfc/rfc2543.html
- https://www.rfc-editor.org/rfc/rfc2705.html
- https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml
- https://www.rfc-editor.org/rfc/rfc4568.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
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
