A PUA is an entity that provides presence information to a PS. In addition to the procedures specified in subclause 5.3.1, the PUA shall support the procedures specified in TS 24.229 appropriate to the functional entity in which the PUA is implemented.

When the PUA intends to publish its own view of the presentity's presence information, it shall generate a PUBLISH request by acting as an Event Publication Agent (EPA) in accordance with RFC 3903. The PUA shall implement the "application/pidf+xml" content type as described in RFC 3863,the Presence Information Data Format (PIDF) extensions defined in RFC 4480. The PUA may implement the PIDF extensions defined in RFC 4482. The PUA may implement location information according to the format defined in RFC 4119. The PUA shall implement RFC 5196 if it wants to make use of SIP user agent capabilities in the presence document. The extension may be used for describing the type of the service described by the presence tuple. The PUA may implement RFC 5264 if it wants to use the partial publication mechanism. The first partial PUBLISH request shall contain the full state. The PUA uses the "application/pidf-diff+xml" content type as described in RFC 5262. The PUA shall update the presence information, either 600 s before the publication expiration time if the publication period indicated from the PS in the response to the PUBLISH request was for greater than 1 200 s, or when half of the time has expired if the publication period was for 1 200 s or less, unless the PUA has determined that an update to the presence information is not required. When the PUA intends to show different value of the same presence attribute to different watchers, the PUA shall publish a tuple or person element for every value it intends to show, all including a different value of the same presence attribute. The PUA shall label different information with different value of the <class> element in every published tuple or person element as defined in RFC 4480. The PUA shall also authorize different tuples to different watchers or watcher groups by manipulating the subscription authorization policy as defined in subclause 6.3.1.2. If a local configuration information limiting the rate at which PUA is allowed to generate PUBLISH requests is available, then PUA shall take that information into account. Such local configuration information could be e.g. the shortest time period between consecutive PUBLISH requests.

The eXtensible Markup Language (XML) Schema Definition of the "application/pidf+xml" format covers the definition of the 3GPP subscriber's presence attributes and the PUA shall perform the following mapping:

• the communication address (containing communication means, status and contact address) attribute and the priority attribute are represented by a <tuple> element including a basic <status> element and a <contact> elements containing a priority attribute as defined in RFC 3863.
  The PUA represents subscriber specific information by including a <person> element defined in RFC 4479. The person element may contain e.g. <activities> and <place-type> elements both defined in RFC 4480. Further PIDF extensions as defined in RFC 4482 can also be used.
• the text attribute is represented by the <note> element as defined in RFC 3863 for <tuple> elements and in RFC 4479 for <person> and <device> elements; and
• the location attribute is represented by the elements defined in RFC 4119 and the <place-type> element defined in RFC 4480.

Additional extensions can be used to express application specific attributes, but their usage is outside the scope of this version of the specification.

The PUA shall implement the "multipart/related" content type as described in RFC 2387 if it wants to aggregate other Multipurpose Internet Mail Extensions (MIME) objects with the "application/pidf+xml" content type. When a presence attribute has a value of a MIME object, the PUA shall either:

1. publish the presence document and the MIME object utilizing the "multipart/related" content-type in the PUBLISH request; or
2. make use of content indirection.

When the PUA decides to use the content indirection mechanism for publishing an initial or modified value of a presence attribute the PUA shall:

1. store the MIME object behind an HTTP URI on the PS or ensure that the MIME object and a HTTP URL pointing to that MIME object already exists on the PS; or
2. use the "multipart/related" content type as described in RFC 2387 with the content indirection mechanism as specified in RFC 4483 for the publication of presence information format as follows:
   • set a CID URI referencing to other MIME multipart body. The other multipart body contains the content indirection information which is represented as the value of an XML element;
   • include the presence document of the format "application/pidf+xml" or "application/pidf-diff+xml" in the root of the body of the "multipart/related" content; and
   • specify the part having information about the MIME object by using the "message/external-body" content type, defining the HTTP URI, versioning information and other information about the MIME object as described in RFC 4483.

When storing a MIME object on the PS the PUA shall:

1. construct as many HTTP URIs as the number of objects to be stored; and
2. formulate every HTTP URI according to a predefined directory structure.

Upon activation of the presence service, the PUA application may subscribe for the watcher information state changes in accordance with RFC 3857 and RFC 3858. Subscription is according to RFC 6665 as per TS 24.229. The PUA application may include filters in the body of the SUBSCRIBE request in accordance with RFC 4661, and RFC 4660 as updated by RFC 6665.

In order to get notifications of changes to XML documents manipulated via the Ut reference point the PUA may generate a SUBSCRIBE request in accordance with RFC 5875 and RFC 6665.

A watcher is an entity that subscribes to or requests presence information about a presentity from the PS. In addition to the procedures specified in subclause 5.3.2, the watcher shall support the procedures specified in TS 24.229 appropriate to the functional entity in which the watcher is implemented.

When the watcher intends to subscribe for presence information state changes of a presentity, it shall generate a SUBSCRIBE request in accordance with RFC 6665 and RFC 3856. The watcher shall implement the "application/pidf+xml" content type as described in RFC 3863, the PIDF extensions defined in RFC 4480. The watcher may implement the PIDF extensions defined in RFC 4482. The watcher may implement location information according to the format defined in RFC 4119. The watcher shall implement RFC 5196 if it wants to make use of SIP user agent capabilities extensions included in the presence document. The extension may be used by the watcher for interpreting the type of the service described by the presence tuple. The watcher may include filters in the body of the SUBSCRIBE request in accordance with RFC 4661, and RFC 4660 as updated by RFC 6665. The watcher may indicate its support for partial notification using the Accept header field in accordance with RFC 5263. The watcher shall interpret the received presence information according to RFC 4479 and the following:

1. a <person> element as defined in RFC 4479 means information about the presentity;
2. a tuple including a <relationship> element defined in RFC 4480 means information about an alternate contact to the presentity;
3. a tuple contains communication means specific information. The communication means described by the tuple is deduced from the URI scheme of the contact address information present in the <contact> element as defined in RFC 3863. If the URI scheme of the contact address information provides ambiguous information about the communication means, the watcher shall further examine other elements of the tuple to decide the communication mean. Such elements can be the <methods> element, any of the different media type specific elements as defined in RFC 5196.
4. a <device> element as defined in RFC 4479 means information about a device.

Additional extensions can be used to express application specific attributes, but their usage is outside the scope of this version of the specification.

When the watcher intends to subscribe for presence information state changes of a presentity collection, it shall generate a SUBSCRIBE request in accordance with RFC 4662, additionally to the procedures described in subclause 5.3.2.2.

Upon activation of the presence service, the watcher may subscribe recursively for the watcher information state changes in accordance with RFC 3857 and RFC 3858. Subscription is according to RFC 6665 as per TS 24.229. The watcher may include filters in the body of the SUBSCRIBE request in accordance with RFC 4661, and RFC 4660 as updated by RFC 6665.

In order to get notifications of changes to XML documents manipulated via the Ut reference point the watcher may generate a SUBSCRIBE request in accordance with RFC 5875 and RFC 6665 as per TS 24.229.

A PS is an entity that accepts, stores, and distributes presence information. In addition to the procedures specified in subclause 5.3.3, the PS shall support the procedures specified in TS 24.229 appropriate to the functional entity in which the PS is implemented.

When the PS receives a SUBSCRIBE request for the presence information event package, the PS shall first attempt to verify the identity of the source of the SUBSCRIBE request as described in subclause 5.7.1.4 of TS 24.229, then perform authorization according to subclause 5.7.1.5 of TS 24.229. In case of successful subscription, the PS shall generate a response to the SUBSCRIBE request and notifications in accordance with RFC 6665 and RFC 3586. Additionally, in the special case of a watcher subscription if the subscription authorization policy results in the action to confirm the watcher subscription from the PUA and the PUA has a valid watcher information subscription, see RFC 3857, then, the PS shall inform the PUA about the watcher subscription attempt. If the watcher has indicated the need for partial notification using the Accept header field, then the PS shall generate partial notifications in accordance with RFC 5263 and RFC 5262. If the body of the SUBSCRIBE request from the watcher contains filters, the PS shall apply the requested filtering function on notifications in accordance with RFC 4661, and RFC 4660 as updated by RFC 6665. If the watcher has indicated support for the "multipart/related" content type using the Accept header field, then the PS may generate notifications using "multipart/related" content type which aggregates "application/pidf+xml" formatted presence information with other MIME objects in accordance with RFC 2387. In this case, the PS shall modify the value of the presence attribute in the PIDF document to refer to the MIME object included in the corresponding MIME multipart body. If the watcher has not indicated support for the "multipart/related" or a MIME object cannot be accessed by the PS, the PS should exclude the presence attribute from the notification.

The PS shall act as an Event State Compositor (ESC). When the PS receives a PUBLISH request, the PS shall first verify the identity of the source of the PUBLISH request as described in subclause 5.7.1.4 of TS 24.229, then perform authorization according to subclause 5.7.1.5 of TS 24.229. In case of successful authentication and authorization, the PS shall process the PUBLISH request in accordance with RFC 3903. If the PUBLISH request contains the "application/pidf-diff+xml" content-type as described in RFC 5262, the PS shall process the PUBLISH request in accordance with RFC 3903 and RFC 5264. If the PUBLISH request contains the "multipart/related" content type and the PS supports the content type, the PS shall process the content as follows:

• if a MIME multipart contains a MIME object of a content type supported by the PS, either store the MIME object in case of initial publication or replace an existing content in case of modify operation; and
• if a multipart includes the "message/external-body" content type and the content indirection as described in RFC 4483 is supported by the PS, ensure that it has access to the MIME object indicated by the URI and that the MIME object exists; and associate the value of the presence attribute that refers to the MIME object with the MIME object and additional information about it.

If the PS does not support the content type used for publishing MIME objects then the PS shall send a 415 (Unsupported Media Type) response and indicate the supported content types in the Accept header. To receive 3GPP2 IP-CAN network presence information from the PNA, the PS shall support the XML extension defined in 3GPP2 X.S0027-004 [46].

When the PS receives a SUBCRIBE request for the watcher information event template package, the PS shall first verify the identity of the source of the SUBSCRIBE request as described in subclause 5.7.1.4 of TS 24.229, then perform authorization according to subclause 5.7.1.5 of TS 24.229. In case of successful subscription, the PS shall generate a response to the SUBSCRIBE request and notifications in accordance with RFC 6665, RFC 3857 and RFC 3858. If the body of the SUBSCRIBE request from the PUA contains filters, the PS shall apply the requested filtering function on notifications in accordance with RFC 4661, and RFC 4660 as updated by RFC 6665.

When the PS receives a SUBSCRIBE request having the Event header value "xcap-diff", the PS shall first verify the identity of the source of the SUBSCRIBE request as described in subclause 5.7.1.4 of TS 24.229, then it shall perform authorization as described in subclause 5.7.1.5 of TS 24.229. Afterwards, the PS shall generate a response to the SUBSCRIBE request and notifications in accordance with RFC 5875 and RFC 6665.

The Resource List Server (RLS) is an implementation of the presence list server. The RLS is an entity that accepts subscriptions to resource lists and sends notifications to update subscribers of the state of the resources in a resource list. In addition to the procedures specified in subclause 5.3.4, the RLS shall support the procedures specified in TS 24.229 appropriate for an AS in which the RLS is implemented.

When the RLS receives a SUBSCRIBE request for the presence information event package of a presentity collection, the RLS shall first verify the identity of the source of the SUBSCRIBE request as described in subclause 5.7.1.4 of TS 24.229, then perform authorization according to subclause 5.7.1.5 of TS 24.229. In case of successful subscription, the RLS shall generate a response to the SUBSCRIBE request and notifications in accordance with RFC 6665 and RFC 4662 by adding a Require header field with value "eventlist". If the body of the SUBSCRIBE request from the watcher contains filters, the RLS shall apply the requested filtering function on notifications in accordance with RFC 4661, and RFC 4660 as updated by RFC 6665.

When the RLS receives a SUBSCRIBE request for the presence information event package of a presentity collection and installs the corresponding subscription, the RLS shall resolve the list URI to individual URIs and generate SUBSCRIBE requests for each of the individual URIs as per the procedures in RFC 6665, RFC 3856 and RFC 4662 if the state information for the resource represented by the individual URI is otherwise not available. For internal virtual subscriptions, the detection of loops potentially caused by lists of lists is possible in RLS. However for back-end subscriptions (see RFC 4662), the detection of such situations is not possible in RLS. To prevent loops in subscriptions to non-local resources the RLS shall not insert "eventlist" in the "Supported" header of back-end subscriptions.

When the RLS receives a SUBSCRIBE request having the Event header value "xcap-diff", the RLS shall first verify the identity of the source of the SUBSCRIBE request as described in subclause 5.7.1.4 of TS 24.229, then it shall perform authorization as described in subclause 5.7.1.5 of TS 24.229. Afterwards, the RLS shall generate a response to the SUBSCRIBE request and notifications in accordance with RFC 5875 and RFC 6665.

In addition to the procedures specified in subclause 5.3.5, the PNA shall support the procedures specified in TS 24.229 appropriate to the functional entity in which the PNA is implemented. The PNA can collect presence information about the presentity from a number of core network entities. The PNA can combine information from various core network entities to form more complete presence information. Among these core network entities, the S-CSCF uses SIP to deliver presence information to the PNA over the Pi reference point as specified in subclause 5.3.5.2.

On receiving a third-party REGISTER request which contains an Expires header with a non-zero value, the PNA shall, if no subscription already exists, subscribe to the reg event package for a particular user at the S-CSCF, as described in subclause 5.7.1.1 of TS 24.229. As a result, the S-CSCF will then provide the presence-related information as reg event packages in NOTIFY requests to the PNA. On receiving a third-party REGISTER request, the PNA may, if a subscription already exists, resubscribe to the reg event package for a particular user at the S-CSCF, as described in subclause 5.7.1.1 of TS 24.229. As a result, the S-CSCF will then provide the presence-related information as reg event packages in NOTIFY requests to the PNA.

To publish network presence information received from 3GPP2 IP-CAN, the PNA shall follow the procedures defined in 3GPP2 X.S0027-004 [46].