Summary

  • In the presence model co-authored by Jonathan Rosenberg, OPEN has a narrow meaning for instant messaging: the associated inbox is ready to accept a message. It is not a receipt for a person's location, attention, willingness, identity or reply.
  • PIDF can carry several service tuples, even conflicting OPEN and CLOSED values for the same contact. RFC 4479 therefore separates person, service and device attributes according to what they describe, while RFC 4480 treats recent input only as one signal for estimating whether someone may answer.
  • A defensible presence record preserves subscription authority, tuple provenance, service state, device activity, message delivery and human outcome as different events. A green dot is useful only when its legend does not spend evidence it never received.

The green dot answered the wrong question

The support transcript is ordinary. At 10:14, the directory displayed a colleague as available. At 10:15, an urgent message was sent. At 10:35, no reply had arrived. One team calls the presence system inaccurate; another says the user ignored the message.

Neither conclusion follows from the dot alone.

The Internet presence model was built around several actors and several kinds of state. A presentity publishes information. A presence service stores and distributes it. A watcher receives it. An instant-message service accepts data for an instant inbox. A principal is the person, group or software actor in the world outside those protocol elements. The model relates these things without declaring them identical.

That architecture matters because a familiar interface compresses them into one adjective: “available.” The compression may be helpful for choosing where to send a message. It is not a forensic statement that a particular human is sitting at a particular device, looking at the application and prepared to respond.

The smallest true receipt is less dramatic: one identified communications service reported a state under a particular publication and aggregation policy at a particular time.

OPEN was designed for an inbox

RFC 2778, written by Mark Day, Jonathan Rosenberg and Hiroyasu Sugano, is an Informational model. It says so plainly: its purpose is common vocabulary, not an interoperable protocol. In the instant-message context, its distinguished OPEN value means that the associated instant-inbox address corresponds to an inbox ready to accept an instant message. CLOSED means it will not accept one.

The object of the claim is the inbox. The model does not say that OPEN means a person is physically present. It does not say the person has recently touched a keyboard, has seen the sender's name, consents to an interruption or promises an answer. For other communications means, RFC 2778 allows an analogous notion but does not define it.

“Ready to accept” is itself not the whole delivery chain. A service may accept a message before a downstream store fails, before a notification reaches a device, before the application displays it or before a person reads it. Presence can make routing more informed without becoming a delivery receipt.

This is why a post-incident export should not translate OPEN into human_available=true. The translation changes the subject of the sentence. It takes a capability of a service and assigns it to a person.

A tuple is a service occurrence, not a portrait of a life

RFC 3863 turns the abstract model into the Presence Information Data Format, or PIDF. A presence document can contain several tuples. Each tuple has a status and can include a contact, a timestamp, notes and extensions. In the base format, <basic> contains open or closed.

For instant messaging, the definition remains exact: an open tuple says that its contact corresponds to an instant inbox ready to accept an instant message. A contact can be omitted for privacy or because a tuple is not tied to a communications means. The status element can also carry extensions whose meanings are separate from the basic value.

Multiplicity is not an edge case. Tuples can be segmented because information came from different devices, different applications on the same device or different times. PIDF even permits one tuple to say OPEN and another to say CLOSED while both carry the same contact.

That conflict does not authorize an observer to invent a universal truth. The watcher needs an application-specific interpretation: which tuple changed, which source produced it, which timestamp applies, what policy composed the document and whether a later notification superseded the earlier one.

The tuple's id helps correlate an occurrence with earlier documents. RFC 3863 calls it an arbitrary string whose significance does not extend beyond distinguishing tuples within the presentity. It is not a user identifier, device certificate or proof that two publishers represent the same human.

A database that retains only presence=open destroys exactly the evidence needed when two inputs disagree. A useful record retains tuple ID, component type, contact, value, publication time, receipt time and source. The roll-up is then a reversible interpretation, not a replacement for the inputs.

Permission to observe is not the state observed

RFC 3856, authored by Rosenberg, defines a SIP event package for presence. A watcher subscribes; a presence agent authenticates the subscription request and makes a separate authorization decision. Authorized or pending processing produces notifications that carry subscription state and presentity state.

These are independent control surfaces. Authentication asks who is requesting. Authorization asks what that watcher may receive. The subscription state asks whether the observation relationship is pending, active or terminated. The PIDF body reports the selected presence information. None of those facts certifies that a human is currently looking at an application.

The distinction also protects privacy. A watcher may be permitted to receive only a subset of presence information. A missing device-activity field may be a deliberate disclosure rule, not evidence that the device has been idle. A pending subscription is not a CLOSED service. A terminated subscription says that observation has ended, not that every service belonging to the presentity has gone offline.

When operations systems merge these states, access-control changes can look like human-behaviour changes. A watcher loses permission and the dashboard turns grey; an analyst concludes that the user left. The actual event occurred in the authorization plane.

Rosenberg's data model gave each fact an owner

RFC 4479, authored by Jonathan Rosenberg, provides a sharper type system for presence. It divides the presentity into person, service and device components. An attribute belongs to the thing it describes, not necessarily to the thing that reported it.

A phone can report that its user is in a meeting. “In a meeting” describes the person, so it belongs to the person component. Battery level or device power describes a device. A point at which communications can reach the user is a service. Reporting source and semantic subject are different fields.

That rule stops a common inference at the boundary. The fact that a service can accept a message does not make the person willing to communicate. The fact that a device is powered on does not prove that its service is usable. The fact that one device has a location does not make it the person's location; RFC 4479 explicitly allows person and device locations to differ.

The model is candid about identity, too. A person component is a facade for a single person, but the system cannot verify that the facade really represents one human. A help desk staffed by a group can be modeled as one person. Presence identity is therefore a modeling handle, not a biometric or organizational proof.

This does not weaken the system. It makes its assertions composable. A service can be OPEN; a device can be active; a person can publish an activity; and an application can decide how to present the combination. Each remains inspectable when the overall result surprises an operator.

Recent input improves an estimate, not the meaning of OPEN

RFC 4480, by Henning Schulzrinne, Vijay Gurbani, Paul Kyzivat and Rosenberg, adds rich presence attributes. One is user-input, which can report active or idle under a configurable threshold. It may describe one application, a whole device or an aggregation across services and devices. The exact last-input time can be omitted.

The specification gives a revealing example: a tuple that has not been used for a while may still be OPEN. A watcher may prefer an OPEN contact that was used more recently. The two observations answer different questions. Basic status concerns the service's willingness or ability to accept communication. Input recency helps estimate how likely the user is to answer.

An estimate is still not a receipt. Input can occur in another application. Automation can keep a device active. A person can read without producing a tracked input, or produce input without noticing the message. The threshold can differ between publishers. Privacy policy may suppress the timestamp.

“Green plus recently active” is a more informed routing signal than green alone. It is not proof of attention, consent or response. A responsible interface can expose the difference with labels such as “service accepting messages” and “activity seen within ten minutes,” leaving the decision to the user.

Attribution should preserve the same boundaries

Rosenberg's IETF Datatracker profile listed 72 RFCs and no active roles when captured on 9 September 2026. RFC 3856 and RFC 4479 name him as sole author. RFC 2778 and RFC 4480 are collective work with other named authors. Those records establish extensive standards participation without turning every element of Internet presence into a lone invention.

The official Five9 author page supplies the public headshot used to ground the editorial portrait. Its older biography is not evidence of a current job title. The restraint is deliberate: a dated page can establish image provenance while remaining unsuitable for a time-sensitive employment claim.

Authorship, standards consensus, implementation, operation and user behaviour are separate responsibilities. Treating them carefully mirrors the protocol lesson. Provenance gains value when its scope stays visible.

Build the evidence chain one verb at a time

A reliable presence record should be able to answer at least eight questions without substituting one for another:

  1. Was the watcher authenticated and authorized, and for which view?
  2. Which notification arrived, through which subscription, and when?
  3. Which tuple and component did the attribute describe?
  4. What contact and basic state were published, by which source and compositor policy?
  5. What device-input or other rich-presence evidence accompanied it, with what threshold?
  6. Did the instant-message service accept the message?
  7. Was it delivered to and displayed by a client?
  8. Did a human read, acknowledge or answer it?

Most systems will not observe every step. That is not a reason to fill the gaps. It is a reason to label them. “Service open; delivery unknown; human response absent” is more operationally useful than “available user ignored message.” The first statement identifies missing evidence. The second assigns motive from a colour.

Presence is valuable because it narrows uncertainty before communication. It does not abolish uncertainty. The green dot can remain—provided the organization remembers what it belongs to.

Sources