WDIFF

draft-ietf-sip-xcapevent-04.txt --> draft-ietf-sip-xcapevent-07.txt

SIP J. Urpalainen
Internet-Draft Nokia
Intended status: Standards Track October 3, 2008 D. Willis, Ed.
Expires: April 6, November 28, 2009 Softarmor Systems LLC
May 27, 2009

An Extensible Markup Language (XML) Configuration Access Protocol (XCAP)
Diff Event Package
draft-ietf-sip-xcapevent-04
draft-ietf-sip-xcapevent-07

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims

This Internet-Draft is submitted to IETF in full conformance with the
provisions of which he BCP 78 and BCP 79. This document may contain material
from IETF Documents or she is aware
have been IETF Contributions published or will made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be disclosed, modified outside the IETF Standards Process, and any
derivative works of which he or she becomes
aware will it may not be disclosed, in accordance with Section 6 of BCP 79. created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 6, November 28, 2009.

Urpalainen & Willis Expires November 28, 2009 [Page 1]

Internet-Draft XCAP Diff Event May 2009

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.

Abstract

This document describes an "xcap-diff" SIP (Session Initiation
Protocol) event package for the SIP Event Notification Framework,
which clients can use to receive notifications of the partial changes of to
Extensible Markup Language (XML) Configuration Access Protocol (XCAP)
resources. The initial synchronization information exchange and
document updates are based on the XCAP-Diff XCAP Diff format.

Urpalainen Expires April 6, 2009 [Page 1]

Internet-Draft xcap diff event October 2008

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. XCAP-Diff Event Package . . . . . . . . . . . . . . . . . . . 4
4.1. Overview of Operation With Basic Requirements . . . . . . 4
4.2. Event Package Name . . . . . . . . . . . . . . . . . . . . 5
4.3. 'diff-processing' Event Package Parameter . . . . . . . . 5
4.4. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6
4.5. Subscription Duration . . . . . . . . . . . . . . . . . . 7 8
4.6. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 8
4.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 8
4.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 11
4.9. Handling of Forked Requests . . . . . . . . . . . . . . . 12
4.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 12 13
4.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 12 13
5. An Initial Example NOTIFY document . . . . . . . . . . . . . . 12 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 17
Appendix A. Informative Examples . . . . . . . . . . . . . . . . 16 17
A.1. Initial documents on an XCAP server . . . . . . . . . . . 16 17
A.2. An Initial Subscription . . . . . . . . . . . . . . . . . 17 18
A.3. A Document Addition Into a Collection . . . . . . . . . . 18 19
A.4. A Series of XCAP Component Modifications . . . . . . . . . 19 20
A.5. An XCAP Component Subscription . . . . . . . . . . . . . . 23
A.6. A Conditional Subscription . . . . . . . . . . . . . . . . 25
Author's Address . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28

Urpalainen & Willis Expires April 6, November 28, 2009 [Page 2]

Internet-Draft xcap diff event October 2008 XCAP Diff Event May 2009

1. Introduction

The SIP Events framework [RFC3265] describes subscription and
notification conventions for the SIP [RFC3261] protocol. Session Initiation Protocol (SIP)
[RFC3261]. The Extensible Markup Language (XML)
[W3C.REC-xml-20060816] Configuration Access Protocol (XCAP) [RFC4825]
allows a client to read, write and modify XML formatted XML-formatted application
usage data stored on an XCAP server.

While the XCAP protocol allows several authorized users or devices to modify the same XML
document, XCAP does not provide an effective
synchronization mechanism (beyond
polling) to keep resources
equivalent synchronized between a server and a
client. This memo defines an "xcap-diff" event package that,
together with the SIP event notification framework [RFC3265] and the XCAP-diff
XCAP diff format [I-D.ietf-simple-xcap-diff], allows a user to
subscribe to changes in an XML document, and to receive notifications
whenever a change in an the XML document takes place. changes.

There are three basic features that this event package enables with
the XCAP-Diff [I-D.ietf-simple-xcap-diff] change notification format.

Firstly, it enables:

First, a client can subscribe to a list the URI references of XCAP documents from documents' URLs in a
collection [RFC4918] located on an XCAP server. This is important
when allows a subscriber is doing an initial synchronization or a comparison
of existing to
compare server resources to with its local resources using the locally cached XCAP documents,
for example. The version-history of document comparisons are based
on URLs and
the strong entity tag (ETag) values of XCAP documents documents, which are
also indicated with
shown in the XCAP-Diff format.

Secondly, XCAP Diff format, and to synchronize them.

Second, this event package can signal whenever a change is
happening in those resources. The changes can be reported with resources in
one of three ways. The simplest model is that first mode only document creations, updates
and removals are indicated. The actual contents of those documents
are not included in indicates the notification event type and
does not include document contents, so the subscriber uses the
(HTTP) RFC 2616 HTTP
[RFC2616] protocol for a retrieval of document
contents. The two more complex modes allow to retrieve the updated document. The second mode includes
document content or changes of documents
to be indicated straightaway with in notification messages, using the XML-Patch-Ops RFC 5261 XML-
Patch-Ops [RFC5261] semantics inside the XCAP-Diff [I-D.ietf-simple-xcap-diff]
format. A client can then apply a conditional patch to locally
cached documents based on the strong ETag values of documents. format with minimal notification size. The
most complex model produces the smallest documents third
mode also includes document content or changes in notification
messages, but it doesn't
necessarily show is more verbose, and shows the full HTTP version-history information unlike version-
history.

Third, the
other, typically more verbose one.

Lastly, client can subscribe to changes in specific XML element or
attribute contents (XCAP components) can be
received "in-band", that is straight within the XCAP-Diff
notification format. For example, an XCAP element content can be
requested and indicated without receive element or attribute
contents in the need of a separate HTTP GET

Urpalainen Expires April 6, 2009 [Page 3]

Internet-Draft xcap diff event October 2008

request. resulting XCAP Diff format notification messages. If this
the requested node either exists or component does not exist but is later created or
modified, created, the
notifier sends a notification body indicates its with the component's content. And
similarly, The
notifier also sends notifications when the removals of subscribed XCAP components
are reported, removed, for example after a successful HTTP DELETE request.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Urpalainen & Willis Expires November 28, 2009 [Page 3]

Internet-Draft XCAP Diff Event May 2009

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119, BCP 14
[RFC2119] and indicate requirement levels for compliant
implementations.

3. Definitions

The following terms are used in this document:

XCAP Component: An XML element or an attribute, which can be
updated, removed removed, or retrieved with the XCAP protocol. XCAP.

Aggregating: While An XCAP client can update only a single XCAP
component Component
at a time with using HTTP. However, a relevant HTTP request, notifier may be able to
aggregate a series of these modifications can be aggregated together with the into a single
notification using XML-Patch- Ops semantics when they are indicated within encoded in the XCAP-Diff XCAP-
Diff format.

This document reuses terminology mostly defined in (XCAP) RFC 4825 XCAP [RFC4825] and
some in (WebDAV) RFC 4918 WebDAV [RFC4918].

4. XCAP-Diff Event Package

4.1. Overview of Operation With Basic Requirements

Enabling all of the

To receive "xcap-diff" event package features require that features, the subscriber MUST somehow signal to the notifier the resources it
is interested
indicates its interest in getting information. These resource selections are
indicated simply certain resources by sending including a URI-list to the notifier URI list
in the subscription body. The URIs of body to the notifier. Each URL in this list MUST point to
be a collection, HTTP URL that identifies a document collection, an XCAP document, or an
XCAP component. When collections are selected, the
conventions applied follow the (WebDAV) RFC 4918 [RFC4918] semantics,
that is, the subscriber Collection URLs MUST add the have a trailing forward slash "/" character to
the end of
"/", following the path segment of a URI. conventions of WebDAV [RFC4918]. A collection
selection includes all documents in that particular collection and recursively
also
all documents in any of the possible sub-collections. The URI URL of an XCAP component selector
consists of the document selector added URL with the XCAP Node Selector. Selector added.
Although the XCAP Node Selector allows

Urpalainen Expires April 6, 2009 [Page 4]

Internet-Draft xcap diff event October 2008 requesting all in-scope
namespaces of an element, subscriptions to
them the client MUST NOT be used. subscribe to
namespaces.

The notifier MUST support XCAP component subscriptions. The notifier
sends the first notification of in response to the subscription subscription, and
this first notification MUST always contain the
URI references URLs of the subscribed, existing documents and
XCAP
attribute(s) with their content(s), and the subscribed, existing
qualified names components that are part of XCAP element(s) preferably with their content(s). the subscription. The notifier MUST always support first
notification SHOULD contain the contents of subscribed XCAP component subscriptions. documents
and components. The subsequent notifications MAY contain patches to
these documents. The
notifier MUST support the simplest change notification model, but the
XML-Patch-Ops diff-generation is RECOMMENDED to implement. The subscriber can control specify how the notifier will
signal the changes of
documents. How this can be done, will be shown later in this
document.

Whenever a change in a resource or an XCAP component content is
indicated inside documents by using the XCAP-Diff [I-D.ietf-simple-xcap-diff] format, 'diff-processing' event

Urpalainen & Willis Expires November 28, 2009 [Page 4]

Internet-Draft XCAP Diff Event May 2009

package parameter, covered in the subscriber MUST have read privilege to that particular resource. section Section 4.3

4.2. Event Package Name

The name of this event package is "xcap-diff". As specified in RFC
3265
[RFC3265], this value appears in the Event header field present in
SUBSCRIBE and NOTIFY requests.

4.3. 'diff-processing' Event Package Parameter

With the aid of the optional "diff-processing" event Event header parameter field
parameter, the subscriber directs the notifier how indicates a preference as to apply the "XML diffing
process" or in other words, how the
notifier SHOULD indicate change notifications of documents. The
possible values are "no-patching",
"xcap-patching" "xcap-patching", and "aggregate" in increasing complexity order. "aggregate".
All three modes provide information that allows the subscriber to
synchronize its local cache, but only the "xcap-patching" mode
provides intermediate states of the version history. The notifier
SHOULD use the indicated mode if it understands it (as such optimizes
network traffic within the capabilities of the receiver), but MAY use
"xcap-patching" as a matter of local policy, as all subscribers are
required to support that mode.

The "no-patching" value (the simplest operational change
notification mode) means that the notifier indicates only the
document creations,
modifications and removals the event type (creation, modification, and removal)
in the notification. The notification does not necessarily
indicate the full HTTP ETag change history. Subscribers and
notifiers MUST support the "no-patching" mode as a base-line for
interoperability. The other, more complex modes are indicated. optional.

The "xcap-patching" value means that the notifier includes all individual
updated XCAP component
updates made by XCAP clients along with the contents and entity tag (ETag)
changes are indicated. changes.
The client receives the full (HTTP) ETag change history of a
document. This is equivalent to sending individual notifications
for each change.

The "aggregate" value means that the notifier SHOULD MAY aggregate
several individual XCAP component updates into a single XCAP-Diff XCAP Diff
<document> element. The policy for determining whether or not to
apply aggregation or to determine how many updates to aggregate is
locally determined. The notifier SHOULD support the "aggregate"
mode and implement XML-Patch-Ops ( [RFC5261]) diff-generation,
because this can greatly reduce the number of notification
operations required.

If the subscription does not contain this additional "diff-
processing" the "diff-processing" header
field parameter, the notifier SHOULD send all individual
changes so that default to the client receives "no-patching"
mode, as this is the full (HTTP) ETag change only mode for which implementation is required
in both subscribers and notifiers.

Urpalainen & Willis Expires April 6, November 28, 2009 [Page 5]

Internet-Draft xcap diff event October 2008

history of a document. In other words, "xcap-patching" is the
default operational mode of a notifier. Note that the "no-patching"
mode does not necessarily indicate the full HTTP ETag change history. XCAP Diff Event May 2009

Note: If To see the difference between "xcap-patching" and
"aggregate" modes, consider a document history that has versions from "a" to "a", "b" to
and "c" with corresponding ETag values "1", "2" and "3", the "xcap-
patching" "3". The
"xcap-patching" mode indicates will include first the change from version
"a" to "b" with
previous the versions' corresponding "1" and new "2" ETags and also
then the change from version "b" to "c" with previous their "2" and new "3" ETags for a particular document. A
change from "a" to "b" can for example be an element addition to a
document, so it is a single (atomic) change made by XCAP (HTTP)
semantics. However, the
ETags. The "aggregate" mode tries to optimize optimizes the change and indicates for example
only a single aggregated change from "a" to "c" with previous the old "1"
and new "3" ETags. If these changes are closely related, e.g. that is,
the same element has been updated many times, the bandwidth
savings are naturally larger.

This "diff-processing" parameter is a subscriber hint to the
notifier. The notifier MAY fall back to may respond using a simpler operational mode mode, but it MUST NOT use not a
more complex one, when it signals changes. For
example, an "aggregate" request MUST be served by the notifier in the
"aggregate", "xcap-patching" or "no-patching" modes, and an "xcap-
patching" request one. Notifier selection of a mode is covered in
Section 4.7. During re-subscriptions, the "xcap-patching" and "no-patching" modes.
Naturally, the "no-patching" request MUST be served only in subscriber MAY change the same
"no-patching" mode.
diff-processing parameter.

The formal grammar [RFC5234] of the "diff-processing" parameter:

diff-processing = "diff-processing" EQUALS EQUAL (
"no-patching" /
"xcap-patching" /
"aggregate" /
token )

where EQUAL and token are defined in RFC 3261 [RFC3261].

4.4. SUBSCRIBE Bodies

The URI list of the requested URIs are is described by the XCAP resource list format specified in RFC 4826 [RFC4826],
and it is included as a body of the initial SUBSCRIBE request that creates the subscription. request. Only a
simple subset of that format is required, a flat list of XCAP R-URIs.
The "uri" attribute of the <entry> element contains these URI values.
The usage of subscriber MUST NOT use hierarchical lists and or <entry-ref>
references, etc.
MUST NOT be used. However, using this format allows adding some
future etc., (though in the future, semantics may be expanded
thanks to these subscriptions. the functionality in the resource list format). In
subsequent SUBSCRIBE requests, such as those used for refreshing the
expiration timer, the subscribed URI-list URI list MAY change.

Subscribers need to appropriately populate change, in which case
the Request-URI notifier MUST use the new list.

The SUBSCRIBE request MAY contain an Accept header field. If no such
header field is present, it has a default value of "application/
xcap-diff+xml". If the header field is present, it MUST include
"application/xcap-diff+xml", and MAY include any other types.

The SUBSCRIBE request MAY contain the Suppress-If-Match header field

Urpalainen & Willis Expires April 6, November 28, 2009 [Page 6]

Internet-Draft xcap diff event October 2008 XCAP Diff Event May 2009

[I-D.ietf-sipcore-subnot-etags], which directs the notifier to
suppress either the body of a subsequent notification, or the entire
notification if the ETag value matches.

If the SUBSCRIBE body contains elements or attributes that the
notifier doesn't understand, the notifier MUST ignore them.

Subscribers need to appropriately populate the Request-URI of the
SUBSCRIBE request, typically set to the URI of the notifier. This
document does not provide any constraints to it. constrain that URI. It is assumed that the
subscriber is provisioned with or has learned the URI of the notifier
of this event package. This specification assumes that a subscriber
populates initial SUBSCRIBE requests with the URI of that notifier.

It is anticipated that the event package.

The XCAP server will usually be collocated co-located with the SIP notifier, so
the subscriber MAY use relative XCAP R-URIs. This
means that Request-URIs. Because relative
Request-URIs are allowed, the notifier has then been provisioned with MUST know how to resolve these
against the correct XCAP Root URI value, for example. A future specification(s) can be written for
the more complex use-cases, this memo describes only the most simple
one.

Note: It is worth noting that the notifier and the XCAP server can
be separated (running on different hosts). However, it requires
that the notifier has some means (in real-time) to be signalled
about content changes of documents on an XCAP server. Also
theoretically, a single notifier could serve multiple XCAP servers
and absolute XCAP R-URIs could then be used. value.

Figure 1 shows an example of a subscription SUBSCRIBE request and body of covering several XCAP
resources: a "resource-list" document, a specific element in a "rls-
services" document document, and a collection in "pidf-manipulation"
Application Usage. For all of these resources the client MUST have
read privilege in order to actually receive them in a NOTIFY request.
application usage. The "Content-Type" header of this SUBSCRIBE
request is "application/
resource-lists+xml". "application/resource-lists+xml".

SUBSCRIBE sip:tests@xcap.example.com SIP/2.0
...
Accept: application/xcap-diff+xml
Event: xcap-diff; diff-processing=aggregate
Content-Type: application/resource-lists+xml
Content-Length: [XXX]
Expires: 4200

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="resource-lists/users/sip:joe@example.com/index"/>
<entry uri="rls-services/users/sip:joe@example.com/index/
~~/*/service%5b@uri='sip:marketing@example.com'%5d"/>
<entry uri="pidf-manipulation/"/>
</list>
</resource-lists>

Figure 1: Example subscription body

Urpalainen & Willis Expires November 28, 2009 [Page 7]

Internet-Draft XCAP Diff Event May 2009

4.5. Subscription Duration

The default expiration time for subscriptions within this package is
3600 seconds. As per RFC 3265 [RFC3265], the subscriber MAY specify
an alternative expiration timer in the Expires header field.

Urpalainen Expires April 6, 2009 [Page 7]

Internet-Draft xcap diff event October 2008

4.6. NOTIFY Bodies

As described in RFC 3265 [RFC3265],

The format of the NOTIFY message will contain
bodies that describe body is either the state default of the subscribed resource. This body
"application/xcap-diff+xml" or is in a format listed in the Accept
header field of the SUBSCRIBE, or
a package-specific default if the Accept header field was omitted
from the SUBSCRIBE.

In this event package, the body of the notification contains messages contain an XCAP
diff Diff
document [I-D.ietf-simple-xcap-diff]. The SUBSCRIBE request MAY
contain an Accept header field. If no such header field is present,
it has a default value of "application/xcap-diff+xml". If the header
field is present, it MUST include "application/xcap-diff+xml", and
MAY include any other types. .

The XCAP-Diff XCAP Diff format [I-D.ietf-simple-xcap-diff] can indicate include the full
element and attribute content of XML documents, and for XCAP documents and components. For
documents, the format can also include corresponding URIs, the ETag values
values, and patching instructions from version "a" to "b". Also the removals of Removal
events (of documents, elements and attributes elements, or attributes) can be shown. With other than identified too.
Except for collection selections selections, the "sel" selector values of the
XCAP-Diff format MUST be octet-by-octet equivalent to the relevant
"uri" parameter values of the <entry> element of the "resource-list"
document.

4.7. Notifier Generation of NOTIFY Requests

During the initial subscription subscription, or if the URI list changes in
SUBSCRIBE refresh requests, the notifier MUST first resolve the requested
XCAP resources. If the subscribed body contains elements
or attributes that it doesn't understand, they MUST be ignored by the
notifier. resources and their privileges. If there are superfluous
resource selections in the requested URI-list, URI list, the notifier SHOULD
NOT provide overlapping similar responses for these resources. A
resource where for which an authenticated user hasn't got does not have a read privilege,
privilege MUST NOT be included in the XCAP-Diff format. Note that for example, an
XCAP component
which that could not be located with XCAP semantics, semantics does not
produce an error. Instead, the request remains in a "pending" state,
that is, waiting for this resource to be created. created (or read access
granted). Subscriptions to collections have a similar property: once
a new document is created into the subscribed collection, the
creation of a new resource is
notified signaled with the next NOTIFY request.

After the notifier knows the list of authorized XCAP resources are known, the notifier resources, it
generates the first full response. This initial notification body NOTIFY, which contains URI references to subscribed all
subscribed, existing documents for which the subscriber has read
privileges, and typically XCAP component(s) actual of existing content.

After sending the initial notification, the notifier MUST start selects a diff-
processing mode for reporting changes. If the subscriber suggested a

Urpalainen & Willis Expires April 6, November 28, 2009 [Page 8]

Internet-Draft xcap diff event October 2008

follow-up XCAP Diff Event May 2009

mode in the "diff-processing" parameter of the subscribed XCAP component SUBSCRIBE, the
notifier MAY use that requested mode or document updates made
by XCAP (HTTP) clients. The diff-processing parameter directs how MAY fall back to a simpler
operational mode, but the notifier reports changes. Regardless MUST NOT use a more complex mode
than the one chosen by the subscriber. From least to most complex,
the order of these operational modes, the same end result modes is achieved, the resources MAY be kept in-sync.
Some intermediate states of following: "no-patching", "xcap-
patching", "aggregate". Thus, the version-history of resources MAY be
lost by these notifications, notifier may respond to an
"aggregate" request using any mode, but cannot reply to an "xcap-
patching" subscription using the "aggregate" mode. Naturally, the
notifier MUST handle a "no-patching" request with the "no-patching"
mode.

In all modes, the notifier MUST maintain the chronological order of
XCAP
changes MUST be maintained. The same rule applies if changes. If several changes
for to a given resource are indicated presented
in a single notification, the chronological update order MUST follow be
preserved in the XML document order of the notification body.
Preservation of chronological order is required to produce a correct
document in the XCAP-
Diff document. subscriber. If content modifications are made out-
of-order, an erroneous document would probably be formed.

While with the most complex patching mode "aggregate" the mode uses bandwidth
usage is the most efficient, efficiently, it
introduces other challenges. The initial synchronization MAY might fail
with rapidly changing resources, because the "aggregate" mode doesn't necessarily indicate
messages might not include the full version-history of a document and
the base XCAP protocol does not support version-history retrievals of
documents. Secondly, when When new documents are created into the in subscribed collections
and the notifier is "aggregating" aggregating patches, the same issue can occur.
In a
corner-case, corner case, the notifier may not be able to provide patches
with the XML-Patch-Ops RFC 5261 [RFC5261] semantics. Therefore, if the
notifier has to temporarily disable diff-generation diff generation and send only the
URI references of some changed documents to the subscriber, it MUST
continue with the "xcap-patching" mode afterwards for these
resources, if the initial subscription also started with the "xcap-
patching" mode.

The notifiers MAY decide In other words, if the appropriate diff-generation
(aggregation) logic themselves, for example subscriber loses track of the
patching operations, the subscriber must refresh to a "known good"
state by downloading the current document. Once it has done so, it
can resume using xcap-patching.

In the "aggregate" mode, the notifier chooses how long to wait for
subsequent
multiple patches if there's already something to signal.

When combine. Even with rapidly changing resources
the notifier is acting in MUST signal only the latest state: e.g. whether the XCAP
component exists or not.

In the "xcap-patching" mode, it the notifier MAY also disable the diff-generation diff-
generation temporarily for some reason for certain resources, for example when the
NOTIFY body becomes impractically large or an intermediate error has
happened. All Some XCAP clients may will probably not try to optimize changes to its extremes, have completely
optimized their patch request, so even when acting in the "xcap-patching" "xcap-
patching" operational mode mode, the notifier MAY try to optimize the diff-generation.

Urpalainen & Willis Expires November 28, 2009 [Page 9]

Internet-Draft XCAP Diff Event May 2009

diff-generation, for example by eliminating redundant patch
operations. Otherwise said: the notifier is not required to send
patch operations exactly as received by clients; rather it MAY notify
with a more efficient patch operation that MUST produce the same
result as the series of patch operations produced by the XCAP client.

Note: It is straightforward to change the XCAP HTTP request client's change
requests (sent via HTTP) to the use XML-Patch-Ops semantics. While
XCAP does not support patching of all XML node types, types - for example
example, namespace declarations can not be added separately, separately -
utilization of XML-Patch-Ops can sometimes significantly reduce
the bandwidth requirements in at the expense of extra processing.

When
Extension of XCAP for this utilization of patch-ops is outside the
scope of this document, but it is evident that XCAP clients that
produce efficient change requests using XML-Patch-Ops make it much
easier for the notifier to produce an efficient change
notification using XML-Patch-Ops.

After the notifier has reported that some the existence of an XCAP components exist in a
document, component,
it MUST also report their removals its removal consistently. For

Urpalainen Expires April 6, 2009 [Page 9]

Internet-Draft xcap diff event October 2008 example, the
removal of the parent element of the subscribed element requires the
same signalling since the subscribed element ceases to
exist after exist. To
signal the removal. The removal of an XCAP component is
signalled by setting component, the notifier sets the
Boolean "exist" attribute value to false of the <element> or <attribute> elements. Even with rapidly changing
resources the notifier MUST signal only the last existing state:
whether the XCAP component exists or not.

During re-subscriptions the diff-processing parameter MAY change.
The value change influences only subsequent notifications not the
notification (if generated) followed immediately after the
(re-)SUBSCRIBE request.
elements to false.

When the notifier process receives a re-subscription re-subscription, it MUST re-send the
current full XML-Diff content unless the NOTIFY message can be
suppressed with the subscriber has requested a
conditional subscription
[I-D.ietf-sip-subnot-etags] semantics [I-D.ietf-sipcore-subnot-etags] by using the
header Suppress-
If-Match: field Suppress-If-Match: [ETag value]. With a conditional re-subscription re-
subscription, the notifier MUST compare also inspect the subscription body
when determining the current subscription state. Since the
subscription is based on a list of XCAP R-URIs R-URIs, it is RECOMMENDED
that the notifier does not consider the order of these URIs when
determining the equivalence to "stored" previous states, that the order of appearance
of these URIs is not significant. Once states. If a match
to the previous state is not found, the NOTIFY message MUST contain
the full XML-Diff state (similar to the initial notification). The
notifiers SHOULD implement the conditional subscription handling with
this event package.

During re-subscriptions, the subscriber may change the value of the
diff-processing parameter. The value change influences only
subsequent notifications, not the notification (if generated)
followed immediately after the (re-)SUBSCRIBE request.

Event packages like this require in practice a reliable transfer of NOTIFY
messages. This means that all messages MUST successfully be
transferred as otherwise patching or the document will become out of sync, and then patches

Urpalainen & Willis Expires November 28, 2009 [Page 10]

Internet-Draft XCAP Diff Event May 2009

will most likely fail or at least
the document contents becomes to be out-of-sync. (or worse, have unintended consequences). This
"xcap-diff" event package requires, similar to Partial-PIDF-Notify
[I-D.ietf-simple-partial-notify]
RFC 5263 [RFC5263], that the notifiers a notifier MUST NOT send a new NOTIFY
request to the same dialog unless a successful 200-
response 200-response has been
received for the last sent NOTIFY request. If the NOTIFY request
fails due to a timeout condition, timeout, the notifier MUST remove the subscription.

Note: This requirement ensures that out-of-order of events will not
happen or that the dialog would continue will terminate after non-resolvable
NOTIFY request failures. In addition, some of the probable NOTIFY
error responses (e.g. 401,407,413) (for example, 401, 407, 413) can possibly be
handled gracefully without tearing down the dialog.

If, for example, the subscriber has selected too many elements to
which to subscribe, so such that the notification body would become be
impractically large (e.g. (that is, an intermediate NOTIFY failure), the
notifier MAY discard

Urpalainen Expires April 6, 2009 [Page 10]

Internet-Draft xcap diff event October 2008 the <element> element content. The existence of
elements is then indicated with an empty <element> element element, and the
content is not shown for those resources. In other words, the
<element> element does not not have a child element then which would show
the subscribed "full" element content.

4.8. Subscriber Processing of NOTIFY Requests

The first NOTIFY request will usually contain references to HTTP
resources including their strong ETag values. If the subscriber does
not have similar locally cached versions, it will typically start an
unconditional HTTP GET request for those resources. During this HTTP
retrieval time time, the subscriber MAY also receive patches to these
documents (if it has requested them) to these documents if the documents are changing
frequently. It can thus happen that the changing.
A subscriber receives newer
versions of documents (with HTTP) than what was indicated in the
initial notification. If patches are received in these notifications
and if all atomic XCAP modifications are indicated with both previous
and new ETags of each resource, it is easy to can chain the modification list for a the document and possibly omit some or all of
aggregate the patches
based on changes itself if the received ETag (with HTTP) notifications contain patches and
indicate all atomic XCAP modifications with both previous and new
ETags of a document. Indeed,
there's still a chance that each resource ("xcap-patching" mode). If the received version by
received via HTTP is newer than any of those versions indicated in received via the notification so that notifications,
the subscriber may not find an equivalent match of an ETag value is not found from
the chain of patches. This can happen since notifications are
reported after the
actual HTTP changes and preferably at some minimum intervals.
In such a case, the subscriber SHOULD either wait for subsequent
notifications or refresh the subscription and repeat the described
"sync" algorithm until a match is achieved.

The notifier MAY at any time disable (temporarily) the diff-
processing of some resources so that only URI references of
modifications are received. So even when the notifier is acting in
this simpler diff-processing ("xcap-patching") mode, several cycles
MAY be needed before an initial "full" sync is achieved. As the
notifier MAY also disable this diff-processing in the middle of a
dialog, the subscriber is always, at any time responsible to make the
appropriate, similar actions. Also as the last resort

To avoid out-of-sync issues, the subscriber MAY always disable the usage of diff-processing.

If start the
subscription is started straightaway with the "aggregate" mode
which doesn't necessarily show "xcap-patching" mode, and then refresh the full version-history information,
subscription with the previous "sync" algorithm breaks more easily. Indeed, it is "aggregate" mode. Syncs are successful if the
received (HTTP) HTTP ETag matches either with either the previous or the new ETag of
the reported aggregated patch. This
failure MAY successfully be resolved by re-fetching If the out-of-sync
document, waiting for subsequent notifications or by refreshing subscription is started with
the
subscription, but "aggregate" mode, which doesn't necessarily show the same issue MAY still repeat. However, in such full

Urpalainen & Willis Expires April 6, November 28, 2009 [Page 11]

Internet-Draft xcap diff event October 2008

a case or in general, XCAP Diff Event May 2009

version-history information, the safer way subscriber may not be able to avoid
synchronize its local cache with the first notification. The
subscriber MAY resolve this out-of-sync issue
is to start by doing one of the subscription with following: re-
fetching the "xcap-patching" mode, and
afterwards refresh out-of-sync document, waiting for subsequent
notifications, or by refreshing the subscription to subscription. However, the "aggregate" mode. same
issue may still repeat.

If the subscriber has received a "full" sync and it has detected that
some of the resources are being served with the "xcap-patching" mode
while others are in the "aggregate" mode mode, it SHOULD refresh the
subscription to the "aggregate" mode.

The notifier MAY at any time temporarily use the "no-patching" mode
for some resources so that the subscriber receives only URI
references of modifications. When the notifier is acting in this
mode, several cycles MAY be needed before an initial "full" sync is
achieved. As the notifier MAY change modes in the middle of a
dialog, the subscriber is always responsible for taking appropriate
actions. Also, as the last resort, the subscriber MAY always disable
the usage of diff-processing by setting the "diff-processing"
parameter to "no-patching".

If a diff format can not cannot be applied because of some due to patch processing and/or
programming errors, errors (for a list, see Section 5.1 of RFC 5261 [RFC5261], [RFC5261]), the
subscriber SHOULD refresh the subscription and disable patching by
setting the usage of
patching. "diff-processing" parameter to "no-patching". The
subscriber SHOULD NOT reply with a non-200 response
when this kind of error happens, since the
notifier could hardly cannot make
any corrective actions. corrections.

During unconditional re-subscriptions re-subscriptions, the subscriber MUST stamp the
received state of all previous resources MUST be stamped as stale. However, if a
conditional [I-D.ietf-sip-subnot-etags] [I-D.ietf-sipcore-subnot-etags] re-subscription is successful
successful, the subscriber MUST preserve the current state of
resources MUST be preserved unless the subscribed URI-list URI list has changed, i.e. changed. That is, the resource's state
subscriber MUST then
be fetched fetch the resource's state, for example example, from some
local cache.

4.9. Handling of Forked Requests

This specification only allows only a single dialog to be constructed as a
result of emitting from
an initial SUBSCRIBE request. In case a SUBSCRIBE
request is forked and If the subscriber receives forked responses,
responses to a SUBSCRIBE, the subscriber MUST apply the procedures indicated in
Section 4.4.9 of RFC 3265 [RFC3265] for handling non-allowed forked
requests.

Urpalainen & Willis Expires November 28, 2009 [Page 12]

Internet-Draft XCAP Diff Event May 2009

4.10. Rate of Notifications

Notifiers of "xcap-diff" event package SHOULD NOT generate
notifications for a single subscription at a rate of more than once
every five seconds.

4.11. State Agents

State agents play no role in this package.

5. An Initial Example NOTIFY document

Figure 2 shows an example initial XCAP-Diff XCAP Diff format document provided
by the first NOTIFY request. The subscriber used the list as in request to the SUBSCRIBE example in Figure 1. An
The following is an example event Event header of field for this SUBSCRIBE
request:

Urpalainen Expires April 6, 2009 [Page 12]

Internet-Draft xcap diff event October 2008

Event: xcap-diff; diff-processing=aggregate

The subscriber requests that the notifier to actually "aggregate" XCAP component
updates together. It is anticipated and anticipates that the subsequent notifications would will
contain aggregated patches to these documents.

Urpalainen & Willis Expires November 28, 2009 [Page 13]

Internet-Draft XCAP Diff Event May 2009

<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/root/">
<document new-etag="7ahggs"
sel="resource-lists/users/sip:joe@example.com/index"/>
<document new-etag="30376adf"
sel="pidf-manipulation/users/sip:joe@example.com/index"/>
<d:element sel="rls-services/users/sip:joe@example.com/index/
~~/*/service%5b@uri='sip:marketing@example.com'%5d"
xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xmlns="urn:ietf:params:xml:ns:rls-services"
xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
><service
xmlns:rl="urn:ietf:params:xml:ns:resource-lists">
<service uri="sip:marketing@example.com">
<list name="marketing">
<rl:entry uri="sip:joe@example.com"/>
<rl:entry uri="sip:sudhir@example.com"/>
</list>
<packages>
<package>presence</package>
</packages>
</service></d:element>
</service>
</d:element>
</xcap-diff>

Figure 2: An example initial XCAP-Diff XCAP Diff format document

Note that the resource-list "index" document included only the new
ETag value, as the document existed during the subscription time. In
the "pidf-manipulation" collection collection, there is only a single document
where
for which the user has read privilege. The <services> element exists
within the rls-services "index" document and its content is shown.

6. IANA Considerations

This specification instructs IANA to add a new event package to the

Urpalainen Expires April 6, 2009 [Page 13]

Internet-Draft xcap diff event October 2008
SIP Event Types Namespace registry. The new data to be added is:

Package Name Type Contact Reference
------------- -------- ------- ---------
xcap-diff package IETF SIP Working Group [RFCXXXX]
<sip@ietf.org>

Urpalainen & Willis Expires November 28, 2009 [Page 14]

Internet-Draft XCAP Diff Event May 2009

7. Security Considerations

This document defines a new SIP event package for the SIP event
notification framework specified in RFC 3265 [RFC3265]. As such, all
the security considerations of RFC 3265 apply. The configuration
data can contain sensitive information, and both the client and the
server need to authenticate each other. The notifiers MUST
authenticate the "xcap-diff" event package subscriber using the
normal SIP authentication mechanisms, for example Digest as defined
in Section 22 of RFC 3261 [RFC3261]. The notifiers MUST be aware of
XCAP User identities (XUI) and how to map the authenticated SIP
identities unambiguously with XUIs.

Since XCAP [RFC4825] provides a basic authorization policy for
resources and as since notifications contain similar fragment content of similar to XCAP
resources, the security considerations of XCAP also apply. The
notifiers MUST obey the XCAP authorization rules when signalling
resource changes. In practice, this means following the read
privilege rules of XCAP resources.

Denial-of-Service attacks against the notifiers deserve a special
mentioning. Subscriptions mention.
The following can cause denial of service due to intensive
processing: subscriptions to a long list of URIs MAY be too process-
intensive. The URIs, "pending"
subscriptions to non-existent documents or XCAP components impose the same challenge as well as the components, and diff-
generation algorithms, at least when they algorithms that try to optimize the required bandwidth
usage to extremes.

The mechanism used for conveying this xcap-diff event information MUST
ensure integrity and SHOULD ensure confidentially of the information.
An end-to-end SIP encryption mechanism, such as S/MIME described in
Section 26.2.4 of RFC 3261 [RFC3261], SHOULD be used. If that is not
available
available, it is RECOMMENDED that TLS [RFC4346] [RFC5246] be used between
elements to provide hop-by-hop authentication and encryption
mechanisms described in Section 26.2.2 "SIPS URI Scheme" and Section
26.3.2.2 "Interdomain Requests" of RFC 3261 [RFC3261].

8. Acknowledgments

The author would like to thank Jonathan Rosenberg for his valuable

Urpalainen Expires April 6, 2009 [Page 14]

Internet-Draft xcap diff event October 2008
comments and providing the initial event package, and Aki Niemi,
Pekka Pessi, Miguel Garcia, Pavel Dostal, Krisztian Kiss, Anders
Lindgren, Sofie Lassborn, Keith Drage, Stephen Hinton, Byron Campen,
Avshalom Houri, Ben Campbell, Paul Kyzivat and Kyzivat, Spencer Dawkins Dawkins, Pasi
Eronen and Chris Newman for their valuable comments. Lisa Dusseault
critiqued the document during IESG review, raising numerous issues
that resulted in improved document quality. Further, technical
writer A. Jean Mahoney devoted countless hours to integrating Lisa's

Urpalainen & Willis Expires November 28, 2009 [Page 15]

Internet-Draft XCAP Diff Event May 2009

comments and cleaning up the technical English usage.

9. References

9.1. Normative References

[I-D.ietf-simple-xcap-diff]
Rosenberg, J. and J. Urpalainen, "An Extensible Markup
Language (XML) Document Format for Indicating A Change in
XML Configuration Access Protocol (XCAP) Resources",
draft-ietf-simple-xcap-diff-09 (work in progress),
May 2008.

[I-D.ietf-sipcore-subnot-etags]
Niemi, A., "An Extension to Session Initiation Protocol
(SIP) Events for Conditional Event Notification",
draft-ietf-sipcore-subnot-etags-02 (work in progress),
April 2009.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.

[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.

[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007.

[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats
for Representing Resource Lists", RFC 4826, May 2007.

[RFC4346]

[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", 1.2", RFC 4346, April 2006. 5246, August 2008.

[RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch
Operations Framework Utilizing XML Path Language (XPath)
Selectors", RFC 5261, September 2008.

Urpalainen & Willis Expires April 6, November 28, 2009 [Page 15] 16]

Internet-Draft xcap diff event October 2008

[I-D.ietf-sip-subnot-etags]
Niemi, A., "An Extension to Session Initiation Protocol
(SIP) Events for Conditional XCAP Diff Event Notification",
draft-ietf-sip-subnot-etags-02 (work in progress),
February May 2009

Operations Framework Utilizing XML Path Language (XPath)
Selectors", RFC 5261, September 2008.

9.2. Informative References

[W3C.REC-xml-20060816]
Maler, E., Paoli, J., Bray, T., Yergeau, F., and C.
Sperberg-McQueen, "Extensible Markup Language (XML) 1.0
(Fourth Edition)", World Wide Web Consortium
Recommendation REC-xml-20060816, August 2006,
<http://www.w3.org/TR/2006/REC-xml-20060816>.

[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, June 2007.

[I-D.ietf-simple-partial-notify]

[RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H.
Khartabil, "Session Initiation Protocol (SIP) extension Extension
for Partial Notification of Presence Information",
draft-ietf-simple-partial-notify-10 (work in progress),
January
RFC 5263, September 2008.

[W3C.REC-xml-20060816]
Sperberg-McQueen, C., Paoli, J., Bray, T., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
Edition)", World Wide Web Consortium FirstEdition REC-xml-
20060816, August 2006,
<http://www.w3.org/TR/2006/REC-xml-20060816>.

Appendix A. Informative Examples

In all following examples only the very relevant headers for this
event package or HTTP requests are shown.

These examples illustrate the basic features of this "xcap-diff" the xcap-diff event
package. Only the relevant header fields are shown. Note also that
the SIP R-URIs of these examples don't correspond to the reality,
i.e. that they typically change within a dialog. reality.

A.1. Initial documents on an XCAP server

The following documents exist on an XCAP server (xcap.example.com)
with an imaginary "tests" Application Usage (AU) application usage (there's no Default
Document Namespace default
document namespace defined in this imaginary AU). application usage).

http://xcap.example.com/tests/users/sip:joe@example.com/index:

<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
</doc>

and then

http://xcap.example.com/tests/users/sip:john@example.com/index:

Urpalainen & Willis Expires April 6, November 28, 2009 [Page 16] 17]

Internet-Draft xcap diff event October 2008

and then

http://xcap.example.com/tests/users/sip:john@example.com/index: XCAP Diff Event May 2009

<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is another sample document</note>
</doc>

A.2. An Initial Subscription

The following demonstrates the listing of a collection contents and
it shows only resources where the user has read privilege. The user Joe
Joe, whose XUI is "sip:joe@example.com" does "sip:joe@example.com", sends an initial
subscription:

SUBSCRIBE sip:tests@xcap.example.com SIP/2.0
...
Accept: application/xcap-diff+xml
Event: xcap-diff; diff-processing=aggregate
Content-Type: application/resource-lists+xml
Content-Length: [XXX]

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="tests/users/sip:joe@example.com/"/>
</list>
</resource-lists>

In addition to the 200 (OK) response, the notifier sends the first NOTIFY looks like:
NOTIFY:

NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]

<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<document new-etag="7ahggs"
sel="tests/users/sip:joe@example.com/index"/>

Urpalainen Expires April 6, 2009 [Page 17]

Internet-Draft xcap diff event October 2008
</xcap-diff>

The subscriber realizes learns that there's only a single the document on this "tests" Application Usage and it has already an application

Urpalainen & Willis Expires November 28, 2009 [Page 18]

Internet-Draft XCAP Diff Event May 2009

usage is equivalent to its locally cached version version, so it doesn't do any actions. Had it a different does not
act. If the local version locally, it had been different, the subscriber would
most likely re-fetch the document.

If the subscriber had requested the "tests/users/" collection collection, the
notification body would have been the same since Joe has no read
privilege to John's resources (XCAP default behavior).

So this demonstrates the listing of a collection contents and it
shows only resources where the user Joe has read privilege.

If the Expires header has field had a value "0" this is effectively a similar "0", the request would be
similar to the PROPFIND method of WebDAV, the syntax's WebDAV. The syntax and responses
differ, however.

A.3. A Document Addition Into a Collection

Let's say that Joe adds a new document to his collection, it can be using
either the same client or another client running on a different device where the subscriber
runs or it is on the same. So he different
device. He does an HTTP PUT to his AU application usage collection:

PUT /tests/users/sip:joe@example.com/another_document HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xml
Content-Length: [XXX]

<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is another sample document</note>
</doc>

As a result to this

This HTTP PUT request results in the XCAP client gets receiving a strong
HTTP ETag "terteer" for this new document.

Then the subscriber receives a notification afterwards:

Urpalainen Expires April 6, 2009 [Page 18]

Internet-Draft xcap diff event October 2008

NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]

<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<document new-etag="terteer"
sel="tests/users/sip:joe@example.com/another_document"/>

Urpalainen & Willis Expires November 28, 2009 [Page 19]

Internet-Draft XCAP Diff Event May 2009

</xcap-diff>

Note that this the result is "additive", "additive"; it doesn't indicate the already
indicated "index" document. Only the initial (or refreshed)
notification contains all document URI references.

If it is Joe's client both modifies the same device doing modifications documents and refreshes the subscription,
the subscriber
subscriptions, it would typically ignores ignore this event. notification, since its
modifications had caused the notification. If it were an another
device the client that
received this NOTIFY hadn't submitted the document change, it would
probably fetch this new document.

If the subscriber decides now to refresh Joe's client refreshes the subscription with the same request body
as in the initial subscription, the result will include these two
documents: "index" and "another_document" with their ETags.

A.4. A Series of XCAP Component Modifications

Now some of the Joe's client decides to utilize uses its XCAP patching
capability, so it does capability by doing the
following:

PUT /tests/users/sip:joe@example.com/index/~~/doc/foo HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]

<foo>this is a new element</foo>

Again

Since the XCAP insertion of the element is successful, Joe's client
receives the new HTTP ETag "fgherhryt3" of the updated "index" document as the insertion of the element is
successful.

Urpalainen Expires April 6, 2009 [Page 19]

Internet-Draft xcap diff event October 2008
document.

Immediately thereafter the XCAP thereafter, Joe's client does again (even pipe-lining issues another HTTP request
(this request could work): even be pipe-lined):

PUT /tests/users/sip:joe@example.com/index/~~/doc/bar HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]
<bar>this is a bar element
</bar>

Urpalainen & Willis Expires November 28, 2009 [Page 20]

Internet-Draft XCAP Diff Event May 2009

The reported new HTTP ETag of "index" is now "dgdgdfgrrr".

And yet again the XCAP Joe's client does: issues yet another HTTP request:

PUT /tests/users/sip:joe@example.com/index/~~/doc/foobar HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]

<foobar>this is a foobar element</foobar>

The reported new ETag of "index" is now "63hjjsll".

After awhile the subscriber awhile, Joe's client receives then a notification with an embedded
patch since it has requested "aggregate" diff-processing and the
notifier is capable of producing them:

Urpalainen Expires April 6, 2009 [Page 20]

Internet-Draft xcap diff event October 2008

NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]

So the subscriber

Joe's client applies this patch to the locally cached "index"
document and also
document, detects the ETag update (and update, and stores the last ETag
value). value.
Note that how several XCAP component modifications were
aggregated together. aggregated.

Note also that that, if the Joe's client hadn't had did not have a locally cached version

Urpalainen & Willis Expires November 28, 2009 [Page 21]

Internet-Draft XCAP Diff Event May 2009

of the reference document, it would have needed to do a HTTP GET
request after the initial notification. If the ETag of the received
resource by HTTP did not then match with either the previous or new ETag of
this aggregated patch, an out-of-
sync out-of-sync condition would be probable. So
This issue is not typical, but it can happen. To resolve the issue,
the client could try to re-fetch the "index" document and resolve the issue and/or wait for
subsequent notifications to detect a match. Another, and a more certain A better and simpler way
to avoid the issue, issue is to refresh the subscription with the "xcap-patching" "xcap-
patching" mode and later refresh to with the "aggregate" mode.
That said, it is not typical that this issue occurs, but it can
happen and the client (subscriber) is about to handle the
consequences.

Had the "xcap-patching" mode been the operational mode of

Alternatively, if the
notifier, so as an alternative, notifier's operational mode been "xcap-
patching", the NOTIFY response could have been:

Urpalainen Expires April 6, 2009 [Page 21]

Internet-Draft xcap diff event October 2008 been the following:

NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]

<?xml version="1.0" encoding="UTF-8"?>
<d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<d:document previous-etag="7ahggs"
sel="tests/users/sip:joe@example.com/index"
new-etag="fgherhryt3">
<d:add sel="*"
><foo>this sel="*">
<foo>this is a new element</foo></d:add</d:document> element</foo>
</d:add>
</d:document>
<d:document previous-etag="fgherhryt3"
sel="tests/users/sip:joe@example.com/index"
new-etag="dgdgdfgrrr">
<d:add sel="*"
><bar>this sel="*">
<bar>this is a bar element
</bar></d:add</d:document>
</bar>
</d:add>
</d:document>
<d:document previous-etag="dgdgdfgrrr"
sel="tests/users/sip:joe@example.com/index"
new-etag="63hjjsll">
<d:add sel="*"
><foobar>this sel="*">
<foobar>this is a foobar element</foobar></d:add</d:document> element</foobar>
</d:add>
</d:document>
</d:xcap-diff>

Note that if

Urpalainen & Willis Expires November 28, 2009 [Page 22]

Internet-Draft XCAP Diff Event May 2009

If the client had to do a re-fetch of the "index" document after the initial
notification, it would be easy to skip could have skipped some or all of these patches patches,
depending on the received resource version by HTTP,
that is, when whether the HTTP ETag matches with matched some of these ETags in the
chain of patches. If not, the HTTP ETag did not match and the received
HTTP version must be is a newer version which will be indicated in later notification(s) and
then the sync
MAY may then be achieved if since the notifier is able to still provide provided the
full change history.

And lastly history in the "xcap-patching" mode.

Lastly, the notifier could (temporarily) fall back to the "no-
patching" mode:

Urpalainen Expires April 6, 2009 [Page 22]

Internet-Draft xcap diff event October 2008 mode, which allows the notifier to keep the dialog alive
when there are too many updates:

NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]

<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff" xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<document previous-etag="7ahggs3"
sel="tests/users/sip:joe@example.com/index"
new-etag="63hjjsll"/>
</xcap-diff>

This fall back allows to keep the dialog alive, for example when
there are really (too) many rapidly changing updates happening. So
at

At any time, the notifier may fall back to this simplest the "no-patching" mode for
some (or all) or all of the subscribed documents.

A.5. An XCAP Component Subscription

The user Joe does sends an initial subscription for the "id" affribute of
a <doc> element. The "index" document exists, but the <doc> root
element does not contain the "id" attribute at the time of the
subscription.

Urpalainen & Willis Expires November 28, 2009 [Page 23]

Internet-Draft XCAP Diff Event May 2009

SUBSCRIBE sip:tests@xcap.example.com SIP/2.0
...
Accept: application/xcap-diff+xml
Event: xcap-diff
Content-Type: application/resource-lists+xml
Content-Length: [XXX]

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="tests/users/sip:joe@example.com/index/~~/doc/@id"/>
</list>
</resource-lists>

In addition to the 200 OK response, the

The first NOTIFY looks like the following since
there's there is nothing to
indicate:

Urpalainen Expires April 6, 2009 [Page 23]

Internet-Draft xcap diff event October 2008

NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]

<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/"/>

Note that if the "index" document hadn't existed, the first NOTIFY
request would have been the same. The XCAP-Diff XCAP Diff document format
doesn't indicate reasons for non-existing resources.

Afterwards Joe's XCAP client updates the whole document root element
including the attribute "id" (not a typical XCAP operation nor a
preferred one, just an illustration here):

PUT /tests/users/sip:joe@example.com/index/~~/doc HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]

<doc id="bar">This is a new root element</doc>

Urpalainen & Willis Expires November 28, 2009 [Page 24]

Internet-Draft XCAP Diff Event May 2009

The new HTTP ETag of the "index" document is now "dwawrrtyy".

Then the subscriber Joe's client gets a notification:

NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]

<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<attribute sel="tests/users/sip:joe@example.com/index/~~/doc/@id"
>bar</attribute>
sel="tests/users/sip:joe@example.com/index/~~/doc/@id">
bar
</attribute>
</xcap-diff>

Urpalainen Expires April 6, 2009 [Page 24]

Internet-Draft xcap diff event October 2008

Note that the HTTP ETag value of the new document is not shown as it
is irrelevant for this use-case.

Then Joe's XCAP client removes the "id" attribute:

DELETE /tests/users/sip:joe@example.com/index/~~/doc/@id HTTP/1.1
Host: xcap.example.com
....
Content-Length: 0

And the subscriber gets a notification:

NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]

Urpalainen & Willis Expires November 28, 2009 [Page 25]

Internet-Draft XCAP Diff Event May 2009

The notification indicates that the subscribed attribute was removed
from the document. Naturally attributes are "removed" if the element
where they belong gets removed e.g. is removed, for example by a an HTTP DELETE request.
The component selections indicate only the existence of attributes or
elements.

A.6. A Conditional Subscription

The last example is about a conditional subscription with which the
regeneration of where a full refresh
can be avoided when there are no changes in resources. The user Joe does Joe's client
sends an initial subscription:

Urpalainen Expires April 6, 2009 [Page 25]

Internet-Draft xcap diff event October 2008

SUBSCRIBE sip:tests@xcap.example.com SIP/2.0
...
Accept: application/xcap-diff+xml
Event: xcap-diff; diff-processing=xcap-patching
Content-Type: application/resource-lists+xml
Content-Length: [XXX]

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="tests/users/sip:joe@example.com/"/>
</list>
</resource-lists>

In addition to

Since there are now two documents in the 200 OK response, repository, the first NOTIFY
looks like
(since there are now two documents at the repository): following:

NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
SIP-ETag: xggfefe54
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]

<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<document new-etag="63hjjsll"
sel="tests/users/sip:joe@example.com/index"/>
<document new-etag="terteer"
sel="tests/users/sip:joe@example.com/another_document"/>
</xcap-diff>

Urpalainen & Willis Expires November 28, 2009 [Page 26]

Internet-Draft XCAP Diff Event May 2009

Note that the NOTIFY request responds with contains the SIP-ETag "xggfefe54".
So a subscription refresh where This
SIP-ETag is placed in the Suppress-If-Match header field of the
conditional subscription. The "diff-processing" mode also is changed
(or is requested to change), looks like:

Urpalainen Expires April 6, 2009 [Page 26]

Internet-Draft xcap diff event October 2008 change):

SUBSCRIBE sip:tests@xcap.example.com SIP/2.0
...
Suppress-If-Match: xggfefe54
Accept: application/xcap-diff+xml
Event: xcap-diff; diff-processing=aggregate
Content-Type: application/resource-lists+xml
Content-Length: [XXX]

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="tests/users/sip:joe@example.com/"/>
</list>
</resource-lists>

If the notifier evaluates this request and if it finds a match to the previous stored state when it
evaluates this request, it responds with 204 (No Notification). If
there are no reportable changes as per [I-D.ietf-sip-subnot-etags]
the whole
[I-D.ietf-sipcore-subnot-etags], NOTIFY request generation is being
suppressed. When the notifier is capable of aggregating can aggregate several modifications,
this re-
subscription effectively re-subscription enables the processing of that mode thereafter.
Indeed, the re-subscription may be quite process-
intensive, process-intensive,
especially when there are a large number of relevant reported
resources.

Author's Address

Authors' Addresses

Jari Urpalainen
Nokia
Itamerenkatu 11-13
Helsinki 00180
Finland

Phone: +358 7180 37686
Email: jari.urpalainen@nokia.com

Urpalainen & Willis Expires April 6, November 28, 2009 [Page 27]

Internet-Draft xcap diff event October 2008

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. XCAP Diff Event May 2009

Dean Willis (editor)
Softarmor Systems LLC
3100 Independence Pk #311-164
Plano, TX 75075
USA

Phone: +1 214 504 19876
Email: dean.willis@softarmor.com

Urpalainen & Willis Expires April 6, November 28, 2009 [Page 28]

----