Presence Authorization Rules
Extracted elements (28)
All permissions in the presence authorization framework are positive grants of information rather than negative denials. This design ensures privacy-safety: failure to obtain or understand an authorization document can only result in less information being revealed, never more.
The <sphere> condition is noted as primarily useful for matching transformation rules rather than subscription handling actions, because its value changes dynamically and a change could suddenly terminate a subscription with no way for the watcher to know when it would be reinstated.
The <sub-handling> and polite-block behavior are combined into a single element because proper privacy handling requires a correlation between the subscription authorization decision and whether polite blocking is used. If they were separate, the combination algorithm would treat them independently.
SIP aliases (multiple AORs assigned to a single user) have no relationship in this specification — each looks like a different user. Even if the presence server knows about aliases for the watcher, they are not mapped to each other in identity matching.
The <provide-note> permission does not control <note> values nested within <activities>, <mood>, <place-is>, <place-type>, <privacy>, <relationship>, or <service-class> elements; those notes are present if the respective parent element is permitted.
A watcher URI that is a SIP URI with a phone number MUST NOT match <one> or <except> conditions whose 'id' is a tel URI with the same number, and vice versa. URIs of different schemes are never equivalent.
Extensions to this specification MUST exist within a different namespace. The schema defined in this document and the namespace urn:ietf:params:xml:ns:pres-rules MUST NOT be altered by future specifications, to prevent privacy violations from misinterpretation.
Future specifications that wish to define new subscription handling action types MUST define an entirely new action element separate from <sub-handling> with their own set of values.
It is RECOMMENDED that clients support all of the actions, transformations, and conditions defined in this specification. Partial support risks incompatibility when a user edits their authorization rules from a different client supporting a different subset.
Presence servers implementing this specification MUST support all of the conditions, actions, and transformations defined in this specification. If servers implemented a subset, clients would need a discovery mechanism, which is not defined.
The final presence document D sent to a watcher MUST satisfy D = F(D), where F is the privacy filtering operation. Further applications of the filtering operation must be a no-op, ensuring the document is fully compliant with privacy policy.
The value of the 'name' attribute in <provide-unknown-attribute> MUST be an unqualified element name (namespace prefix MUST NOT be included), and the 'ns' attribute MUST be a namespace URI.
When presence authorization documents are transported using XCAP, the XCAP capabilities document at the server SHOULD contain the namespaces for the permissions supported by the presence server, allowing agents to query supported capabilities before constructing documents.
Clients retrieving presence authorization documents SHOULD render information about rules they do not understand to users, so users can be certain what rules are in place. This prevents confusion when a user edits rules from clients supporting different subsets.
A presence authorization document is an XML document formatted according to the common policy schema (RFC 4745), composed of rules with three parts: conditions, actions, and transformations. Each permission is a positive grant of information to the watcher, making the format privacy-safe by design.
The <provide-all-attributes> permission is a macro granting access to all presence attributes in permitted person, device, and tuple elements, including attributes unknown to the server or defined in future extensions. It expands into the full set of provide-* permissions.
The <provide-devices> permission is a set variable controlling watcher visibility into <device> elements. Set members identify devices by <class>, <deviceID> (URI equivalence), or <occurrence-id> (case-sensitive equality). The special value <all-devices> grants access to all device occurrences.
The <provide-persons> permission is a set variable controlling watcher visibility into <person> elements. Set members identify person occurrences by <class> or <occurrence-id>. The special value <all-persons> grants access to all person occurrences.
The <provide-services> permission is a set variable controlling watcher visibility into <tuple> service elements. Set members identify services by <class>, <occurrence-id>, <service-uri> (URI equivalence), or <service-uri-scheme> (case-sensitive equality). The special value <all-services> grants access to all service occurrences.
The <provide-unknown-attribute> permission allows granting access to proprietary or future presence attributes not known to the server. It takes mandatory 'name' (unqualified element name) and 'ns' (namespace URI) attributes. Its interpretation can change if the server is upgraded to recognize the previously unknown namespace.
The <provide-user-input> permission is an enumerated integer controlling access to the <user-input> element. Values are: false (0, remove element), bare (10, retain but strip idle-threshold and since attributes), thresholds (20, retain idle-threshold only), and full (30, retain all attributes).
The <sub-handling> element is an enumerated integer action specifying the subscription authorization decision. Defined values are: block (0, default), confirm (10), polite-block (20), and allow (30). The combination algorithm selects the maximum value across all matching rules.
This document registers the XCAP Application Usage ID (AUID) 'pres-rules' in the IETF tree. This AUID is used to manage presence authorization documents via XCAP.
This document registers the XML namespace URI urn:ietf:params:xml:ns:pres-rules and the XML schema URI urn:ietf:params:xml:schema:pres-rules with IANA per RFC 3688 procedures.
Combining multiple authorization documents can produce non-obvious results. For example, a rule granting all example.com users access combined with a rule blocking [email protected] will still grant [email protected] access, because all permissions are positive grants and the maximum value wins.
Presence authorization policies are sensitive — they reveal which users are liked or disliked. When transported over a network they SHOULD be encrypted, and transport SHOULD provide authenticity and message integrity.
When XCAP is used to transfer presence authorization documents, both clients and servers MUST implement HTTP over TLS and HTTP Digest authentication. Sites SHOULD authenticate clients using digest over TLS and SHOULD define the root services URI as an https URI.
The <sub-handling> value drives the RFC 3857 subscription state machine. Changing to 'block' generates a 'rejected' event moving subscriptions to 'terminated'; changing to 'confirm' moves active subscriptions back to 'pending'; changing to 'polite-block' or 'allow' generates an 'approved' event moving pending subscriptions to 'active'.