Summary

  • RFC 5344 describes use cases for presence and instant-messaging peering. It does not define a protocol, certify a federation or solve the security questions it identifies.
  • Its authorization-migration optimization can reduce duplicate traffic by sending one full presence document to a peer that filters it for local watchers. That transfers an enforcement task; it does not transfer the user's authority.
  • A defensible federation keeps separate receipts for peer authentication, user consent, policy version, watcher identity, transformation result, message disposition and any human or operational outcome.

One copy saved bandwidth by moving the decision

Presence is not a single Boolean. A document can reveal whether somebody is available, which device or service is active, a mood, an activity, a place, a relationship, a note or a time offset. Different watchers can be entitled to different views of the same person. A colleague may see availability; a family member may see location; a blocked contact may receive nothing or a deliberately bland answer.

RFC 5344 starts with an inter-domain problem. Alice belongs to one peer network and Bob to another. Bob's network may accept subscriptions only from its own users or from networks it trusts. Alice's network therefore carries her subscription to Bob's network and later carries notifications back. That arrangement establishes an administrative path. It does not erase Bob's rules about Alice.

Scale makes the distinction expensive. If hundreds of watchers in one remote network follow the same presentity, Bob's home network can send individually filtered copies. The copies preserve the home network's policy decision but repeat traffic. RFC 5344 describes another design: share privacy information and one full presence document, then let the receiving peer send the right values to the right watchers. It also describes a middle course in which several differently filtered documents travel with lists of the watchers for whom each is intended.

All three designs can be legitimate. They place evidence in different locations. Individual filtering requires the home network to prove which view it generated for which watcher. Delegated filtering requires the remote network to prove that it evaluated the right watcher against the right policy and transformed the document correctly. The watcher-list variant must prove that the list and document remained bound while both moved and while membership changed.

The optimization therefore does not remove authorization work. It changes the party, state and clock on which authorization depends.

Trusting a peer is not authorizing a watcher

RFC 5344 uses trust at the peer-network level because an interconnect needs to know which administrative domain is on the other side. Its security section asks whether the peer really is the network it claims to be, whether channels protect authenticity and confidentiality, whether the peer will keep information from third parties and whether it will avoid falsifying data.

Those are necessary questions, but they are not the same question as “may this watcher see Bob's location?” A certificate or bilateral agreement can authenticate a network endpoint. A federation rule can admit a service provider. Neither identifies the individual watcher without an additional identity chain, and neither grants that watcher every transformation allowed by Bob's policy.

RFC 4745 makes the missing chain visible. A policy rule has conditions, actions and transformations. The authenticated requestor identity can be a condition. Matching rules are combined, and transformations determine the information that reaches the requestor. RFC 5025 then defines presence-specific controls for person, device, service, activity, mood, place, relationship and other attributes. “Subscription allowed” is not a universal disclosure permission.

When enforcement is delegated, the receiving network needs more than the full document. It needs an identity for the watcher that has the same meaning the rule maker intended, a current rule set, the same transformation semantics and a way to handle revocation. If Alice's external-domain identifier is aliased, renamed or asserted through a different trust domain, the local policy engine can reach a technically valid decision about the wrong principal.

RFC 6271 later turns the use case into a requirement and makes one boundary explicit: sharing privacy settings must occur with the express consent of the user whose settings are shared. Consent to transfer the rules is still not consent to disclose every field. It authorizes a processing arrangement whose execution remains measurable.

The full document is a high-value intermediate

Delegated filtering creates an intermediate object that no ordinary watcher may be entitled to receive. The full presence document may carry enough attributes to reconstruct working patterns, devices, relationships or location. A breach at the receiving peer or clearing house can therefore reveal more than the final authorized views would have exposed.

Transport protection answers only part of that risk. TLS or SIPS can protect a hop and authenticate an endpoint under specified trust assumptions. It cannot prove that the receiving service stored the document for the agreed duration, applied the current rule, suppressed a forbidden field, resisted an internal administrator or deleted cached copies after revocation.

The evidence package should name the intermediate as a separate asset. Record its source presentity, generation time, policy version, intended enforcement peer, encryption context, retention class and deletion deadline. Record the derived view's watcher identity, matching rules and disclosed fields. If a remote peer cannot produce that lineage without exposing the sensitive document itself, the federation has a design problem rather than an audit inconvenience.

The risk becomes more concentrated in a central federation. RFC 5344 calls the hub form a clearing house and suggests services such as authorized interconnection, logging, n-way chat and lawful interception. A hub can simplify bilateral complexity, but it also accumulates trust, content and records. A log can be useful evidence only when its coverage, ordering, clock, integrity, retention and access policy are known. “The clearing house logged it” is not a completeness proof.

Lists make one request become many decisions

The list-based use case appears economical: Alice subscribes to a URI representing a personal, public or ad-hoc group. But a list is an active translation surface. RFC 5363 notes that a URI-list service receives one request and sends potentially many. That creates integrity, confidentiality, authorization and amplification risks. RFC 5360 treats a relay's translation from one target URI to multiple recipient URIs as a consent problem.

The authority decision cannot stop at the list URI. It must resolve who may use the list, who currently belongs to it, which members may receive the particular data, who can change membership and which snapshot governed this expansion. An ad-hoc conference list can change while a subscription remains active. A public group can be administered by somebody other than the presentity. A personal watch list expresses the watcher's interest, not the presentity's permission.

The operational receipt therefore needs a list version or membership digest, not merely the list address. If the server reports partial refusal, that refusal may itself reveal membership. If a single request causes a thousand notifications, rate and consent controls need to attach to the expansion, not only to the inbound message.

The same reasoning applies to multiple-recipient instant messaging. RFC 5365 carefully handles sender identity and privacy headers because a list server becomes a new user agent for outgoing requests. Copying, suppressing or transforming identity across trust boundaries is a decision, not plumbing.

Network disposition is not human receipt

RFC 5344 includes both pager-mode SIP MESSAGE and session-based MSRP. They should not be flattened into a generic “message delivered” metric. Pager mode is a discrete SIP request. MSRP establishes a session and has its own transaction and reporting semantics. A server can accept a request while a user is offline, a device is unavailable, a gateway later fails, or a client never displays the content.

A protocol response is still valuable. It proves that a particular component produced a particular disposition under a recorded transaction. What it does not prove is that the intended human saw, understood or acted on the message. A clearing-house log may prove custody at the hub. A peer-server receipt may prove acceptance at the domain boundary. A client acknowledgment may prove processing on a device. A read indicator, where supported and trustworthy, is another event. The business outcome remains separate.

Good dashboards display this ladder rather than compress it. Routed to peer. Accepted by remote service. Expanded to recipients. Delivered to a client. Displayed or acknowledged. Human response. Each row needs its own timestamp, actor and uncertainty. The same ladder helps incident response: an interconnect can be healthy while remote policy blocks a message, or remote delivery can work while the federation's accounting record is incomplete.

Meaning can change even when syntax survives

Interoperability often fails above the wire format. RFC 6271 gives a simple example: a proprietary gateway can map “Do Not Disturb” in one system to “Busy” in another. Both values may be valid in their local products, yet the translation changes the meaning that a watcher sees.

PIDF supplies a standard representation, but standard syntax does not prove semantic fidelity. A gateway must record the input value, mapping table and output. A peer should distinguish an absent attribute from a filtered attribute and a value that was translated. Otherwise a compliance review can see a well-formed document while an operator sees the wrong availability state.

Freshness matters as much as mapping. Presence publication, subscription acceptance and notification are different events. A correct policy applied to a stale document can still mislead. A current document filtered under an old policy can still over-disclose. Binding policy version and data version in the audit trail makes those failure modes visible.

Evidence boundary

The sources establish standards text, protocol models and security requirements. They do not establish the current behavior of any named federation, product, peer network, clearing house or user account. The scenarios above are analytical tests, not reported incidents. RFC 5344 is Informational; it captures use cases and explicitly leaves security solutions out of scope. Later RFCs define requirements and mechanisms, not universal deployment.

That limit is central to the thesis. A standards reference can show what an implementation ought to separate. Only deployment evidence can show what it actually separated.