Résumé

  • Pour la messagerie instantanée, le modèle de présence auquel Jonathan Rosenberg a contribué donne à OPEN un sens précis : la boîte associée est prête à accepter un message. Il ne constate ni la présence physique, ni l’attention, ni la volonté de répondre d’une personne.
  • PIDF accepte plusieurs tuples, y compris des états OPEN et CLOSED contradictoires pour une même adresse. RFC 4479 sépare donc trois objets — personne, service, appareil — selon ce que l’attribut décrit, et non selon l’équipement qui l’a produit.
  • Un indicateur honnête conserve séparément l’autorisation du veilleur, l’origine du tuple, l’état du service, l’activité de l’appareil, la livraison et l’action humaine. Le point vert n’est pas faux ; sa légende peut l’être.

Deux états qui ne se contredisent pas

Dans un centre d’assistance, la fiche d’un expert reste verte depuis le matin. Un second panneau indique pourtant « aucune activité depuis 47 minutes ». Le superviseur doit décider où envoyer un dossier urgent. S’il lit les deux valeurs comme des mesures rivales de la disponibilité humaine, il lui faut choisir laquelle croire. S’il respecte leur objet, elles peuvent être vraies ensemble.

Le service de messagerie accepte encore les messages. L’appareil observé n’a pas reçu de saisie récente. La personne peut être au téléphone, devant un autre terminal, en réunion ou absente. Rien dans ces deux signaux ne dit encore si elle lira le dossier.

Cette sobriété est inscrite dans les premiers textes de présence de l’IETF. Leur intérêt n’est pas de fabriquer une intuition magique de disponibilité, mais de rendre échangeables des observations dont la portée reste limitée.

OPEN qualifie d’abord une boîte de réception

RFC 2778 est un modèle informatif signé par Mark Day, Jonathan Rosenberg et Hiroyasu Sugano. Il propose un vocabulaire commun ; il ne prétend pas définir à lui seul un protocole interopérable. Il distingue notamment le presentity qui fournit l’information, le service de présence qui la distribue, le watcher qui l’observe, le service de messagerie et l’instant inbox qui reçoit les messages.

Dans ce cadre, OPEN signifie, pour la messagerie instantanée, que l’adresse associée correspond à une boîte prête à accepter un message. CLOSED signifie qu’elle ne peut pas l’accepter. Pour d’autres moyens de communication, le texte envisage un sens analogue sans le définir.

Le sujet grammatical est décisif. Ce qui est ouvert est une boîte ou, plus tard, un service de communication. Le standard ne dit pas qu’un humain se trouve devant l’écran, connaît l’identité de l’expéditeur, accepte d’être interrompu ou promet une réponse. Il n’atteste même pas toute la chaîne de livraison : accepter à l’entrée ne garantit ni stockage, ni notification, ni affichage, ni lecture.

Le passage de « boîte prête à accepter » à « personne disponible » n’est donc pas une traduction neutre. C’est une nouvelle inférence, décidée par le produit qui dessine le point vert.

PIDF conserve plusieurs versions locales de la réalité

RFC 3863 encode l’information dans le Presence Information Data Format. Un document PIDF peut contenir plusieurs tuples. Chacun possède un état et peut comporter une adresse de contact, un horodatage, des notes et des extensions. La valeur de base est open ou closed.

La segmentation sert lorsque les informations proviennent d’appareils différents, de plusieurs applications sur un même appareil ou de moments distincts. Le texte autorise même deux tuples portant la même adresse, l’un OPEN, l’autre CLOSED. La contradiction apparente est laissée au watcher, dont la politique dépend de l’application.

Le champ id d’un tuple permet de le rapprocher d’une notification antérieure. Il s’agit d’une chaîne arbitraire, utile uniquement pour distinguer les occurrences au sein d’un presentity. Ce n’est ni une identité humaine, ni un certificat d’appareil, ni la preuve que deux sources décrivent la même situation.

Une base qui ne garde que la dernière couleur perd le raisonnement. Pour qu’un état soit auditable, il faut conserver l’identifiant du tuple, son contact, sa valeur, son origine, l’objet décrit, l’heure publiée, l’heure reçue et la règle de composition. L’indicateur agrégé devient alors recalculable ; sans ces éléments, il devient une affirmation sans provenance.

Voir l’information est une autorisation distincte

RFC 3856, dont Rosenberg est l’auteur, transporte la présence par les mécanismes SIP SUBSCRIBE et NOTIFY. Le presence agent authentifie toute demande d’abonnement, puis prend une décision d’autorisation séparée. Une demande peut réussir, être rejetée ou rester en attente ; les notifications portent à la fois l’état de l’abonnement et l’état publié du presentity.

Ces couches ne doivent pas s’hériter mutuellement. L’authentification identifie le watcher. L’autorisation détermine ce qu’il peut voir. L’abonnement décrit la relation d’observation. Le corps PIDF porte l’information choisie. Aucun de ces actes ne vérifie qu’une personne regarde son écran.

La frontière protège aussi la vie privée. Une absence d’activité peut résulter d’une règle qui masque l’information. Un abonnement terminé peut refléter une révocation d’accès, pas l’extinction du service. Une demande en attente n’équivaut pas à CLOSED. Si le tableau de bord mélange accès et présence, une modification de politique apparaîtra comme un départ humain.

RFC 4479 remet chaque attribut sur le bon objet

Dans RFC 4479, Jonathan Rosenberg distingue la personne, le service et l’appareil. Le principe central est simple : un attribut appartient à ce qu’il décrit, pas nécessairement au composant qui l’a signalé.

Un téléphone peut annoncer que son utilisateur est en réunion. L’information décrit la personne et appartient donc au composant personne. La batterie appartient à l’appareil. Un point de joignabilité — messagerie, téléphonie, SMS — appartient au service. L’origine de la mesure et son objet sont deux colonnes différentes.

Le modèle empêche plusieurs raccourcis. Un appareil allumé ne garantit pas le fonctionnement d’un service. Un service joignable ne prouve pas la volonté de communiquer. La position d’un appareil n’est pas forcément celle de la personne ; RFC 4479 prévoit explicitement que les deux positions puissent différer.

Il avertit aussi que le composant personne est une façade de modélisation. Le système ne peut pas vérifier qu’il représente réellement un seul être humain. Un service d’assistance composé de plusieurs agents peut apparaître comme une personne. L’URI de présence fournit un identifiant opérationnel, pas une preuve biométrique ou juridique.

Cette séparation est une force : l’application peut rapprocher les signaux tout en sachant lequel corriger. Si le service accepte mais que l’appareil est inactif, l’équipe de routage et l’équipe du terminal ne recherchent pas la même panne.

L’activité récente ne promet toujours pas une réponse

RFC 4480, signé par Henning Schulzrinne, Vijay Gurbani, Paul Kyzivat et Rosenberg, enrichit PIDF. Son élément user-input peut indiquer une activité ou une inactivité selon un seuil configurable. La mesure peut concerner une application précise, l’ensemble d’un terminal ou une agrégation de services. L’heure exacte de dernière saisie peut ne pas être publiée.

Le texte formule la bonne prudence : un tuple peu utilisé peut rester OPEN, et le watcher peut préférer un service à la fois ouvert et utilisé plus récemment. L’ouverture et la récence sont donc deux indices. Leur combinaison sert à estimer la probabilité d’une réponse.

Estimer n’est pas constater. Une saisie dans une autre fenêtre peut produire « actif ». Un processus automatique peut maintenir le terminal éveillé. Une personne peut lire sans déclencher le capteur retenu, ou taper sans voir le message urgent. Les seuils varient et la confidentialité peut masquer le détail.

L’interface peut afficher « service acceptant les messages » et « activité il y a moins de dix minutes ». Elle rend alors le raisonnement visible au lieu de transformer deux signaux techniques en certitude psychologique.

Une attribution aussi précise que les états

Au 9 septembre 2026, le profil IETF de Jonathan Rosenberg recensait 72 RFC et aucune fonction active. RFC 3856 et RFC 4479 le donnent comme auteur unique ; RFC 2778 et RFC 4480 sont des travaux collectifs. Ces faits établissent une contribution documentée, pas le contrôle des implémentations ni la paternité solitaire de toute la présence Internet.

La page d’auteur officielle de Five9 fournit le portrait public qui sert de référence d’identité pour l’illustration éditoriale. Sa biographie ancienne n’est pas utilisée pour affirmer une fonction actuelle. Une source peut convenir à la provenance d’une image sans convenir à une déclaration d’emploi datée.

Cette discipline d’attribution est la même que celle du modèle : auteur, consensus IETF, éditeur logiciel, opérateur et utilisateur n’occupent pas la même place.

Écrire une phrase par preuve

Un dossier exploitable répond séparément aux questions suivantes : quel watcher a été authentifié et pour quelle vue ; quel abonnement et quelle notification ont produit l’état ; quel tuple, service et contact étaient concernés ; quelle règle a composé les sources ; quelle activité d’appareil accompagnait l’état ; le service a-t-il accepté le message ; le client l’a-t-il reçu et affiché ; une personne l’a-t-elle lu ou traité ?

Toutes les réponses ne seront pas disponibles. La lacune doit rester visible. « Service ouvert, livraison inconnue, réponse absente » permet encore de diagnostiquer. « Utilisateur disponible mais silencieux » invente un comportement humain à partir d’une capacité réseau.

Le point vert reste un bon outil de choix. Il cesse seulement d’être un témoin universel.

Sources