Résumé

  • RFC 5196 enrichit la présence SIP avec des capacités de service et d’appareil. Ces indications permettent de choisir un moyen de contact, mais le texte précise qu’elles ne remplacent pas la négociation de média, notamment SDP.
  • Une exploitation défendable distingue la capacité déclarée, la règle de divulgation, la vue réellement reçue, la décision d’appeler, l’offre et la réponse, ainsi que le résultat du média en direct.

L’absence a trois sens, pas un seul

Le piège vient d’une interface apparemment simple. Un document contient une capacité positive, une capacité négative, ou ne dit rien. Il est tentant d’en faire trois couleurs d’un même état. Or RFC 5196 décrit un système où l’omission peut être volontaire. Un utilisateur peut disposer de la voix et refuser de publier ce fait. Une règle d’autorisation ou un serveur de présence peut aussi limiter ou modifier la vue destinée à un watcher précis.

Le silence n’est donc pas la preuve d’une incapacité. Il peut signifier que la source ne savait pas, que la donnée a expiré, qu’elle concernait un autre service, ou que ce destinataire n’avait pas le droit de la connaître. Transformer automatiquement ces cas en notsupported crée une affirmation que personne n’a émise.

Le vocabulaire de RFC 5196 rend justement explicites les valeurs placées sous supported et notsupported. Le document déconseille une énumération exhaustive de négations sans pertinence. Si une même valeur apparaît dans les deux ensembles, le watcher peut la considérer comme prise en charge. Cette règle résout un conflit de lecture ; elle ne rend pas l’ensemble complet ni actuel.

La politique fait partie de la provenance

La présence n’est pas un registre neutre placé entre un appareil et tous ses observateurs. C’est une projection. Le présentity publie, un agent peut porter l’information, une politique autorise une part de la divulgation et un serveur produit une vue pour un contexte d’abonnement. Deux watchers peuvent donc recevoir des documents différents sans que l’un soit corrompu.

Une base qui conserve le XML final mais oublie l’identité du watcher et la version de la règle se trompe de sujet. Elle ne possède pas « les capacités de l’appareil ». Elle possède ce qui a été montré à un destinataire, à une date donnée, après transformation. Réutiliser cette vue pour une autre personne revient à contourner la politique qui lui donnait son sens.

Cette distinction protège aussi l’analyse d’incident. Quand un appel audio n’a pas été proposé, il faut pouvoir savoir si le terminal ne l’a jamais publié, si le propriétaire l’a caché, si le serveur l’a filtré, si l’agrégateur l’a perdu ou si le watcher a mal interprété une omission. Un badge final ne permet aucun de ces diagnostics.

Un indice avant le contact

Le besoin initial reste légitime. Dans PIDF, une URI de contact ne dit pas toujours si le tuple correspond à la voix, à la vidéo, à la messagerie ou à un autre service. RFC 5196 reprend des caractéristiques de RFC 3840 et les place dans le modèle personne/service/appareil défini par RFC 4479. Le watcher obtient ainsi de meilleurs indices avant d’initier une communication.

Le mot décisif est « avant ». La portée du RFC indique que ces données renseignent préférences, volonté et capacités ; elle précise en même temps qu’elles ne remplacent pas la négociation de média SIP telle que SDP. La présence peut recommander une tentative. Seuls la requête, l’offre, la réponse et le terminal qui répond établissent ce qui est négocié dans cette session.

Une capacité peut aussi vieillir entre ces deux moments. L’utilisateur change d’appareil, le service redémarre, une publication disparaît ou un cache conserve la projection précédente. Il n’y a aucune obligation dans le texte que la présence corresponde parfaitement à la capacité réelle. Le watcher est explicitement averti de ne pas attendre cet alignement total.

Composer, c’est décider

Plusieurs sources peuvent publier au nom du même présentity : téléphone fixe, client mobile, logiciel de bureau, service de politique. RFC 5196 note que leur combinaison peut perdre des informations ou produire des incohérences. L’agrégateur ne doit donc pas être traité comme une photocopieuse.

Chaque valeur a besoin de son origine, de son objet — service ou appareil —, de son heure, de son expiration et de la décision prise en cas de conflit. Une règle « le dernier gagne » n’est intelligible que si l’on sait quel horodatage fait foi. Une union de toutes les capacités peut annoncer une combinaison qu’aucun terminal ne possède. Une intersection peut cacher une option parfaitement disponible sur le terminal qui répondra.

Le modèle personne/service/appareil fournit précisément la discipline qui manque à ces raccourcis. Une langue indiquée par un service n’est pas la preuve qu’un locuteur humain est présent. Une capacité vidéo attachée à un appareil n’est pas une promesse pour chaque URI du présentity. Et la volonté publiée n’est pas un consentement permanent à toute invitation.

Le reçu minimal

Pour chaque affirmation, enregistrer l’identité du présentity, du watcher et de l’abonnement ; le tuple, le service ou l’appareil concerné ; l’agent de publication ; la version de source ; la date de publication et d’expiration ; l’état positif, négatif ou non divulgué ; ainsi que la valeur exacte. Ajouter la règle d’autorisation et toute modification du serveur, puis calculer l’empreinte de la vue remise au watcher.

Ouvrir ensuite une seconde chaîne. Quelle indication a influencé le choix de contact ? Quelle URI et quel terminal ont été retenus ? Quels furent la requête SIP, l’offre et la réponse SDP, le média négocié, la disponibilité humaine et le résultat observé ? Si plusieurs sources ont été fusionnées, conserver leur ensemble et la résolution du conflit.

Ce schéma est une proposition d’exploitation, non une exigence de format ajoutée au RFC. Il applique la discipline de Heng Lu : le symbole doit rester inférieur au système vivant qu’il décrit. La présence garde toute sa valeur lorsqu’elle aide à choisir sans prétendre avoir déjà négocié.

Sources

  1. RFC 5196 en HTML
  2. Texte du RFC 5196
  3. Notice du RFC 5196
  4. Datatracker IETF : RFC 5196
  5. Historique du RFC 5196
  6. Références du RFC 5196
  7. Errata du RFC 5196
  8. RFC 3840
  9. RFC 3863
  10. RFC 4479
  11. RFC 3859
  12. RFC 4566
  13. RFC 3261
  14. RFC 2778
  15. RFC 3856
  16. RFC 3903
  17. RFC 5025
  18. Heng Lu — couches de réalité et pouvoir symbolique
  19. Heng Lu — spécification initiale minimale
  20. Heng Lu — primauté du code en fonctionnement