Résumé

  • La RFC 5367 permet de placer une liste plate de ressources dans la requête SUBSCRIBE initiale, d’exiger recipient-list-subscribe et d’établir un seul dialogue dont les notifications rlmi+xml décrivent les ressources constituantes.
  • Le statut de la réponse initiale ne renseigne pas sur la réussite des abonnements vers chaque URI. Après création, les requêtes SUBSCRIBE suivantes visent une URI fournie par le serveur ; un corps de liste n’y a aucune sémantique définie et provoque un rejet 415.
  • L’autorité est donc limitée par phase : liste de création, ensemble canonique, permission de chaque cible, dialogue, URI de continuation, notification, capacité de gestion, expiration et destruction sont des reçus séparés. La présence durable d’un document ou d’un lien ne rend pas son pouvoir durable.

La réponse avait un sujet précis

Une réponse SIP est toujours la réponse d’un acteur à une opération. Dans la RFC 5367, le client envoie une requête SUBSCRIBE au serveur de listes de ressources. La réussite de cette transaction peut établir un dialogue avec ce serveur. Elle ne constitue pas une déclaration anticipée de tous les serveurs ou ressources cachés derrière lui.

Le client inclut au moins un corps recipient-list, contenant la liste au format plat dérivé de la RFC 4826. Il place recipient-list-subscribe dans Require et annonce qu’il comprend rlmi+xml dans Accept. Ces éléments forment le contrat de création.

La spécification dit expressément que le code de statut ne donne aucune information sur la capacité du serveur à s’abonner avec succès aux URI de la liste. Le client obtient ces informations par les notifications.

Un tableau de bord qui affiche « trois abonnements actifs » dès réception du premier succès change donc le sujet de la preuve. Il possède un reçu du serveur de listes, pas trois reçus constituants.

La notification conservait la pluralité

RFC 4662 fournit le cadre de notification d’événements pour les listes de ressources. Le format rlmi+xml permet de représenter les ressources dont l’état est rapporté dans le dialogue.

L’agrégation économise des dialogues côté client ; elle ne fusionne pas les réalités. Une ressource peut être active, une autre refusée et la troisième inconnue. Une notification récente peut être complète ou partielle selon son contrat et sa version. Le mot « récent » ne signifie pas automatiquement « exhaustif ».

Chaque URI canonique doit conserver une position stable. Le système enregistre la version de notification, l’identité de la ressource, l’état déclaré, sa fraîcheur et l’origine de l’observation. Une ressource absente ne doit pas disparaître du dénominateur.

Cette structure permet une reprise limitée. Une incertitude portant sur Joe ne justifie pas de reconstruire le dialogue de Bill et Ted. Le serveur doit distinguer reprise du dialogue, reprise d’une ressource et retransmission d’une notification.

La liste n’avait d’autorité qu’au moment de créer

Après établissement du dialogue, le client peut envoyer d’autres SUBSCRIBE, notamment pour prolonger la durée. La RFC 5367 ne donne aucune sémantique à un corps de liste dans ces requêtes ultérieures.

Le client devrait donc l’omettre. Un serveur qui le reçoit rejette la requête avec 415 Unsupported Media Type. Le même XML peut être valide et pourtant dépourvu d’autorité dans cette phase.

Cette règle empêche une mutation silencieuse. Si une simple prolongation pouvait aussi remplacer la liste, la possession du dialogue deviendrait un pouvoir implicite d’élargir la surveillance. Une extension future peut définir une autre règle ; le contrat de base ne l’invente pas.

La preuve doit nommer la phase : création, maintien, terminaison ou gestion. Conserver seulement la dernière requête efface la raison pour laquelle son corps avait — ou n’avait pas — un effet.

Deux URI exposaient deux capacités

La requête initiale vise l’URI publique de la liste. Les requêtes suivantes visent l’URI transmise par le serveur lorsque le dialogue est créé.

Du point de vue du client, la première ressource accepte un corps recipient-list, tandis que la seconde ne l’accepte pas. La continuité du dialogue humain ne rend pas les surfaces interchangeables.

Le reçu relie l’URI publique, le principal authentifié, le hash de la liste, les identifiants du dialogue et l’URI de continuation. Cette filiation prouve comment la capacité de maintien a été obtenue sans prétendre qu’elle possède les droits de création.

Elle rend aussi les erreurs visibles. Une prolongation envoyée par habitude à l’URI publique n’est pas équivalente à une prolongation envoyée à la cible du dialogue, même si les deux adresses appartiennent au même domaine.

Le format général était plus riche que le service

La RFC 4826 offre des listes hiérarchiques et des références entry-ref. Le service de la RFC 5367 n’a besoin que d’une liste plate. Les clients devraient éviter la hiérarchie et les références ; le serveur peut écarter les informations supplémentaires.

Un document conforme à son schéma peut donc exprimer davantage que le service ne promet d’exécuter. La validité XML ne prouve pas la conservation sémantique.

Conservez le document brut, le profil pris en charge, les constructions écartées, la règle de normalisation et l’ensemble plat obtenu. Le hash du fichier source et le hash de l’ensemble exécuté répondent à deux questions différentes.

Cette réduction est une discipline de portée. Le format reste réutilisable entre applications ; le service décide quel sous-ensemble porte une autorité opérationnelle.

Le lien de gestion formait une troisième surface

Le serveur peut fournir une URI permettant de manipuler la liste associée à l’abonnement. Elle apparaît dans Call-Info au sein du NOTIFY qui établit l’abonnement, avec purpose=list-management.

Ce lien n’est ni la notification, ni automatiquement l’URI de continuation. Il nomme une capacité de gestion. Son service doit encore authentifier le demandeur, autoriser la méthode, valider la mutation et produire un reçu.

Une interface ne devrait pas transformer sa simple présence en preuve qu’une modification a réussi. Elle doit conserver qui a reçu l’URI, sa portée, la durée attendue et chaque opération effectuée.

Les trois surfaces ont des fonctions distinctes : l’URI publique crée, l’URI du dialogue maintient, l’URI list-management manipule. Leur réunion dans un écran ne doit pas fusionner leurs politiques.

La durée de la liste suivait celle de l’abonnement

La liste manipulable a une durée liée à l’abonnement. Elle devrait être détruite quand l’abonnement expire ou prend fin.

Cette règle interdit de transformer par inertie une liste temporaire en carnet d’adresses permanent. L’objectif est clair, mais la vérification physique demande davantage qu’un timer.

Expires: 0, une notification de terminaison et la suppression du stockage sont trois événements. Des caches, répliques, index ou archives peuvent survivre. L’opérateur doit préciser les objets visés, les exceptions de rétention et le reçu de fin.

L’incertitude sur une réplique ne doit pas annuler la norme. Elle doit apparaître comme incertitude bornée ou exception déclarée, non comme permission tacite de conservation.

L’identité du client ne remplaçait pas l’accord des cibles

La RFC 5367 reprend les règles de sécurité des RFC 4662 et 5363. Le serveur authentifie et autorise le client, tandis que la logique de listes URI exige aussi les permissions appropriées des cibles, notamment l’opt-in.

Un client authentique peut demander une observation abusive. Son droit d’utiliser le service ne prouve pas que Bill, Joe et Ted ont accepté cet event package, cette finalité et cette durée.

La décision lie principal, service, événement, URI canonique, but, durée et consentement applicable. Un rôle général « peut s’abonner » ne doit pas devenir un droit de surveiller toute liste fournie.

Les refus ont aussi une valeur probante. Une ressource absente d’une notification peut avoir été protégée par la politique plutôt qu’être tombée en panne. Sans reçu d’autorisation, les deux récits se confondent.

Le registre donnait des noms, pas des résultats

IANA enregistre recipient-list-subscribe et la valeur list-management. Ces noms permettent de négocier une capacité et d’interpréter un lien.

Un option-tag dans Require ou Supported ne démontre pas que chaque abonnement a réussi. Un purpose dans Call-Info ne démontre pas que l’URI reste valide ni qu’une mutation est autorisée. Le registre est une autorité de vocabulaire, pas une télémétrie.

La RFC 5367 a été publiée en octobre 2008 sur la voie Standards Track et a mis à jour la RFC 3265 en autorisant Call-Info dans NOTIFY. La RFC 3265 a ensuite été rendue obsolète par la RFC 6665. Les implémentations actuelles doivent lire cette filiation sans présenter le texte ancien comme dernier état du cadre d’événements.

L’évolution ne change pas la séparation essentielle : création, continuation, notification, gestion et fin de vie restent des affirmations distinctes.

Dix reçus empêchaient l’autorité de devenir permanente

Un dossier défendable sépare : authentification du client ; autorisation du service ; document initial ; ensemble plat canonique ; opt-in de chaque cible ; création du dialogue ; URI de continuation ; états constituants notifiés ; capacité de gestion ; terminaison et destruction observée.

Aucun reçu n’hérite automatiquement du suivant. Une réponse positive ne vaut pas résultats individuels. Un NOTIFY ne vaut pas nécessairement ensemble complet. Un lien ne vaut pas mutation. L’expiration ne vaut pas effacement observé.

La note de Lu Heng sur la spécification initiale minimale offre une lentille déclarée : normaliser le plus petit contrat partagé et laisser les décisions futures aux acteurs possédant l’information locale. Refuser une sémantique implicite aux listes de renouvellement suit exactement cette discipline.

Sa note sur les couches de réalité complète l’analyse. Document, option-tag, réponse, notification et timer sont des symboles situés à des couches différentes. Ils ne deviennent une réalité opérationnelle plus forte qu’avec le reçu qui les relie. Les faits protocolaires restent ceux des RFC et du registre IANA.