Summary

  • RFC 5196 lets a SIP presence document carry service and device capabilities so a watcher can make a better choice before contact. The RFC expressly says that this information is only a hint and does not replace media negotiation such as SDP.
  • A trustworthy operating record must keep source capability, disclosure policy, watcher-visible projection, invitation, offer and answer, selected endpoint, user willingness and live media outcome as separate events.

A useful prediction, promoted into a verdict

Base PIDF can expose a contact URI without saying whether the tuple represents voice, video, messaging or some other service. RFC 5196 improves that weak starting point. It imports the capability vocabulary associated with RFC 3840 and places service and device features into the person/service/device model. Before initiating a session, a watcher can see clues about media, message types, language and other characteristics.

That is an efficiency mechanism. A client may rank contact choices, avoid an obviously unsuitable service or offer a form of communication the recipient is likely to handle. Yet the specification draws a hard line around the result: the capability extension supplies hints about preferences, willingness and capability before contact. It does not replace the negotiation that follows, including SDP.

The distinction is temporal as well as technical. Presence might have been produced by another device, cached before an endpoint changed, modified by a server or filtered for this watcher. An SDP answer is attached to a particular offer in a particular session. A green video value in presence and a rejected video stream can therefore both be true descriptions of different layers.

The watcher receives a projection, not the source

The presentity controls more than a collection of features. It can choose not to publish a capability it actually has. RFC 5196 gives the plain example of a service that supports voice while the user decides not to disclose that support. Silence is not the same as a negative assertion.

Authorization policy adds another transformation. A presence agent may expose one view to a colleague and another to an unknown subscriber. A presence server may limit or modify the information. If an application stores only the final XML and labels it device capability, it erases the policy that produced the view. The correct subject is narrower: capability visible to this watcher, under this subscription and rule version, at this time.

This matters most where absence drives automation. A scheduler that reads an omitted feature as not supported may suppress a valid call. One that treats every advertised feature as immediately usable may create an attempt that cannot complete. RFC 5196 warns about both directions: incomplete or false presence can conceal a possible communication or encourage an impossible one. The watcher should not expect exact alignment with the live service.

Composition creates a third statement

Presence often has more than one publisher. A desk phone, soft client, mobile device and policy service can all contribute. The RFC recognizes that combining multiple sources may lose information or produce mismatches. Aggregation is therefore not clerical merging. It is a decision about scope, precedence and conflict.

The XML vocabulary distinguishes an explicit positive under supported from an explicit negative under notsupported. It discourages publishers from filling documents with exhaustive irrelevant negatives. If the same value appears in both sets, the stated resolution is to assume support. A compositor that silently chooses the latest leaf, deletes the conflict or converts missing data to false creates a new claim without preserving its inputs.

Operators need per-value provenance. Which publication unit supplied the claim? Did it describe a service or a device? When did it expire? Which watcher authorization applied? Was the result copied, filtered, merged or inferred? Without those fields, a later investigator cannot tell whether an inaccurate decision came from an endpoint, privacy rule, stale cache or composition algorithm.

Capability is attached to something

RFC 4479 supplies the person/service/device model that RFC 5196 extends. That model prevents an attractive shortcut: copying one capability across every object associated with a user. A service capability can express what a service offers; a device capability can express what a device can do. Neither automatically proves which device will answer a future invitation.

Even a SIP URI needs context. The motivation for the extension is that the URI alone may not identify the service behind a tuple. Capability metadata makes the choice better, but it does not turn the tuple into a guarantee of reachability, permission or human availability. “Speaks French” is not “a French-speaking person is present.” “Supports video” is not “will accept this video call.” “Supports a message type” is not “this payload passed the live negotiation.”

The operational schema should preserve those grammatical differences. A source reports. A policy permits disclosure. A server constructs a view. A watcher observes. A client decides to invite. SIP routes a request. SDP negotiates media. An endpoint and a person produce the outcome. Compressing all those verbs into ready creates authority that no one event possesses.

A minimum receipt for capability-led contact

For each presence claim, retain the presentity, watcher and subscription context; tuple, service or device identity; publication agent; source version; publication and expiry time; positive, negative or undisclosed state; and the exact feature value. Record the authorization rule and every server-side transformation before hashing the watcher-visible document.

Then start a new chain. Record which visible capability influenced the invitation, the target URI, selected endpoint, SIP response, SDP offer and answer, negotiated media, and observed result. Keep user willingness distinct from technical support. If multiple sources contributed, preserve the input set and conflict decision rather than only the flattened output.

This receipt is an operational inference, not a new wire requirement in RFC 5196. Its purpose is to prevent a prediction from becoming retroactive proof. The design is compatible with Heng Lu’s discipline of keeping the symbolic layer subordinate to the running system. Presence is valuable precisely because it is lightweight and anticipatory. It stays valuable when its boundary remains visible.

Sources

  1. RFC 5196 HTML
  2. RFC 5196 text
  3. RFC 5196 information page
  4. IETF Datatracker: RFC 5196
  5. RFC 5196 history
  6. RFC 5196 references
  7. RFC 5196 errata
  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 — reality layers and symbolic power
  19. Heng Lu — minimum initial specification
  20. Heng Lu — running-code primacy