3.6.5.1 Processing a setSubscriber Request

As specified in section 2.2.2.6.2, a setSubscriber request is identified by a SERVICE request with a Content-Type header field value of "application/msrtc-presence-setsubscriber+xml". Upon receipt of such a message, the server MUST verify that the To-URI, the From-URI, and the URI in the SERVICE header are identical. This URI is then used to look up the publisher whose subscriber list is to be modified. The server then parses the XML to fetch the subscriber URI and looks up this URI in the SubscriberSet. If a SubscriberEntry for this subscriber URI is not found, the server returns a 400 error response. If a SubscriberEntry for this subscriber URI is found, the server updates the internal state according to the acknowledged attribute in the subscriber element and then sends a 200 OK. If the acknowledged value is "true", the server SHOULD remove the SubscriberEntry from the SubscriberSet. This is done to avoid an ever-growing SubscriberSet structure for all users; otherwise, SubscriberSets grow over time as users' contact lists grow.

The removal of a SubscriberEntry when the acknowledged attribute is "true" is not possible in the case of MSRTC and PIDF subscriptions. The server MUST NOT remove the subscriber entries for these subscriptions, because MSRTC and PIDF subscriptions do not have a similar "context" concept. If the server were to remove the subscriber entries, Publishers would be notified every time they get subscribed by MSRTC/PIDF subscribers. For details, see section 3.7.5.3.

The server SHOULD enforce a size limit for the SubscriberSet list. The size limit is defined by an implementer. The server SHOULD return a 413 error response if the number of entries in the SubscriberSet list exceeds an enforced server limit.

If there is a non-empty context element in the category SUBSCRIBE request that is received from a subscriber, the server MUST insert the content of the non-empty context element in the context subelement of the subscriber element specified in section 2.2.2.6.1; otherwise, this element is omitted. For an example of a SUBSCRIBE request with a non-empty context element, see section 2.2.2.4.1.

The server forces a total size limit for the context elements stored per publisher. The size limit is defined by an implementer. The server can return a 413 error response.

The XML schema for the document can be found in section 6. A setSubscribers request MUST NOT support acknowledging multiple subscribers at once, as seen in the schema.

In the example found in section 4.8.1, Bob acknowledges alice@contoso.com.