Résumé

  • La RFC 7865 nomme le document XML des métadonnées SIPREC application/rs-metadata+xml, alors que la RFC 7866 emploie application/rs-metadata dans ses procédures et ses exemples.
  • L’erratum 7987, signalé en juin 2024, est toujours affiché comme Held for Document Update. La RFC 9806, publiée sur le Standards Track en juin 2025, met à jour la RFC 7866 et remplace toutes les occurrences fautives.
  • La RFC 9806 fournit aussi l’enregistrement IANA que les deux textes de 2016 n’avaient pas effectué. Le registre actuel associe application/rs-metadata+xml aux RFC 7865 et 9806.
  • Cette chaîne établit la règle documentaire. Elle ne prouve ni le libellé émis par un SRC, ni celui accepté par un SRS, ni la façon dont une enveloppe multipart a été traitée ou archivée.

Une contradiction de quatre caractères

La RFC 7865 définit les métadonnées d’une session enregistrée sous la forme d’un document XML propre à SIPREC et lui attribue le type application/rs-metadata+xml. Publiée le même mois, la RFC 7866 décrit le protocole de session d’enregistrement, mais raccourcit ce nom en application/rs-metadata dans sa section 9 et dans plusieurs figures.

Les deux documents ne divergent pas sur le contenu XML. La RFC 7866 renvoie expressément à la RFC 7865 pour le format. La divergence porte sur l’identifiant qui pilote la sélection du traitement MIME. Un corps peut être un XML parfaitement valide et rester inutilisable si sa valeur Content-Type ne correspond pas à l’entrée attendue par le répartiteur du récepteur.

L’erratum 7987, déclaré le 12 juin 2024, a isolé cette contradiction. Sa page donne l’ancienne valeur, la nouvelle et le constat qu’aucun des deux RFC initiaux n’avait enregistré le type. Son statut visible reste Held for Document Update. Il faut conserver cette formulation exacte : ce statut n’est pas Verified, et une analyse sérieuse ne le rebaptise pas.

La RFC 9806 apporte la décision normative ultérieure. Publiée en juin 2025 comme document Standards Track, elle porte la mention Updates: 7866, dit résoudre l’erratum et ordonne de remplacer chaque occurrence de application/rs-metadata par application/rs-metadata+xml. La spécification courante est donc claire. La population déployée ne l’est pas nécessairement.

Une mise à jour préserve l’histoire au lieu de la réécrire

Le texte original de la RFC 7866 continue d’afficher l’ancien libellé. La RFC 9806 ne modifie pas rétroactivement cette archive ; elle ajoute une couche explicite qui change la lecture opérationnelle de l’ensemble. Cette conservation est utile pour l’audit, car elle permet de suivre l’affirmation d’origine, le signalement et la résolution.

Elle crée aussi un risque de lecture partielle. Un développeur qui ne consulte que la RFC 7866 peut reprendre l’ancienne chaîne. Un inventaire qui note seulement « compatible RFC 7866 » ne distingue pas les deux comportements. Un collecteur d’errata peut voir le statut Held sans relier la nouvelle RFC. Inversement, un contrôle du registre peut trouver le nom correct sans démontrer qu’une version de produit l’a jamais intégré.

Chaque pièce répond donc à une question différente. La RFC 7865 établit l’intention du format. La RFC 7866 localise l’incohérence dans la procédure sur le fil. L’erratum conserve le signalement et son état éditorial. La RFC 9806 porte la mise à jour formelle. Aucune de ces pièces ne constitue un inventaire de logiciels en cours d’exécution.

Le registre ferme l’espace de noms, pas le déploiement

La RFC 9806 reconnaît que l’enregistrement manquait et fournit le modèle nécessaire. Celui-ci fixe le type application, le sous-type rs-metadata+xml, l’absence de paramètres obligatoires ou facultatifs et des considérations d’encodage conformes à application/xml selon la RFC 7303. Il désigne les SRC et SRS comme applications, COMMON comme usage prévu et l’IETF comme autorité de changement.

La capture du registre IANA au 20 septembre 2026 contient bien application/rs-metadata+xml et cite les RFC 7865 et 9806. C’est une preuve forte de la coordination du nom. Ce n’est pas une preuve d’installation. L’IANA ne peut pas indiquer si une version a ajouté le jeton, si une option l’a activé, si un intermédiaire l’a réécrit ou si un dépôt a conservé la valeur reçue.

Le suffixe +xml apporte lui aussi une information bornée. La RFC 7303 permet à un logiciel générique de reconnaître la famille XML. Le suffixe ne certifie ni le schéma SIPREC, ni l’appartenance du document à la bonne Recording Session, ni la cohérence de la suite entre instantanés complets et mises à jour partielles.

La correction se joue dans l’enveloppe MIME

La RFC 7866 décrit une surface concrète. Le SRC peut envoyer un instantané complet ou une mise à jour partielle dans un INVITE ou un UPDATE. Si le même message transporte une offre SDP et les métadonnées, le corps externe est multipart/mixed. Une partie contient le SDP ; l’autre porte les métadonnées avec Content-Disposition: recording-session.

Une preuve d’interopérabilité doit donc aller plus loin qu’un ticket de conformité. Elle relie la méthode SIP et des identifiants bornés, le Content-Type externe, la limite multipart, le Content-Type et le Content-Disposition de la partie, un hachage du corps XML, son espace de noms, le caractère complet ou partiel de la mise à jour et le résultat du pair.

Le résultat ne se réduit pas au succès global de la signalisation. Le SRS doit suivre l’ordre des mises à jour partielles. Après une perte d’état interne, il peut demander un nouvel instantané complet. Face à une erreur syntaxique ou sémantique des métadonnées, il peut terminer la Recording Session. Une réponse 2xx à un autre niveau du dialogue ne prouve pas que cette chaîne a été acceptée.

L’existence d’un fichier audio ne suffit pas non plus. Le stockage et la lecture sont hors du périmètre de la RFC 7866. L’audio peut avoir été conservé tandis que les métadonnées ont été rejetées, retardées, normalisées ou indexées sous un alias historique. Il faut vérifier la valeur reçue, la valeur stockée et le chemin de relecture ou d’export.

La compatibilité peut masquer le dernier nœud ancien

Accepter temporairement les deux libellés peut être un choix raisonnable. Cela évite qu’un pair ancien bloque une migration. Mais la RFC 9806 n’impose pas cette politique, et la souplesse diminue la valeur probante d’un succès.

Si tous les serveurs acceptent indéfiniment les deux chaînes, un client obsolète devient invisible. Si une passerelle réécrit l’ancienne valeur, la télémétrie en aval fait paraître corrigée une flotte qui ne l’est pas à la source. Si les journaux normalisent les deux valeurs avant enregistrement, l’opérateur perd le signal du trafic résiduel.

Une transition maîtrisée définit un sens et une durée. Les nouveaux générateurs peuvent n’émettre que la valeur corrigée, tandis que les analyseurs gardent une double acceptation bornée. Une exception peut être limitée à des pairs identifiés. Une réécriture doit journaliser séparément la valeur reçue et la valeur transmise. La sortie de compatibilité dépend d’un trafic observé et d’un propriétaire nommé, non d’une simple date au calendrier.

Le reçu de garde de correction

Le reçu proposé ici est un contrôle éditorial de Daniel Kade. Ce n’est ni un champ de la RFC 9806, ni une exigence de l’IETF, du RFC Editor ou de l’IANA.

Sa première partie fixe la chaîne documentaire : passages des deux RFC d’origine, identifiant, date, statut et correction de l’erratum, relation de mise à jour de la RFC 9806, puis capture datée et hachage du modèle IANA.

La deuxième partie lie l’implémentation : produit SRC ou SRS, version, build, modules d’analyse et de génération, génération de configuration, valeurs acceptées et émises dans chaque sens. Pour chaque alias ancien, elle précise s’il est rejeté, accepté, normalisé ou réécrit et quel signal rend ce choix observable.

La troisième partie décrit la transaction : méthode, identifiants bornés, en-têtes Accept et Content-Type, limite multipart, Content-Disposition, hachage du document, espace de noms, état de l’instantané, liaison SDP et verdict du pair. Une demande de resynchronisation, un rejet ou une terminaison restent des résultats distincts.

Enfin, le reçu rejoint l’archive : libellé stocké, clé d’index, règle de normalisation, représentation exportée et test de relecture. Il conserve cohorte de déploiement, comptages ancien/nouveau/inconnu, canari, fenêtre de compatibilité, essais négatifs, déclencheur de retour arrière, propriétaire, décision de retrait et exceptions restantes.

La publication prouve que la règle existe. Le reçu montre où elle a effectivement circulé.

Limite des preuves

Les sources établissent la contradiction, le signalement, la mise à jour et l’état du registre. Elles ne fournissent aucun recensement des produits SIPREC, aucune matrice de versions, aucune mesure de part des deux valeurs et aucun incident attribué à cette incohérence. Cet article n’accuse aucun fournisseur.

Les chemins de risque décrits sont des scénarios vérifiables, pas des défaillances observées. Ils découlent des surfaces visibles du protocole : jeton exact, structure multipart, analyse XML, séquence des mises à jour et traitement des archives. Chaque opérateur doit les tester dans son propre environnement au lieu de substituer l’existence de la RFC 9806 à une preuve d’exécution.

Sources