WDIFF

draft-ietf-sip-xcapevent-01.txt --> draft-ietf-sip-xcapevent-02.txt

SIP J. Urpalainen
Internet-Draft Nokia
Intended status: Standards Track February 25, April 11, 2008
Expires: August 28, October 13, 2008

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

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

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 August 28, October 13, 2008.

Abstract

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

Urpalainen Expires August 28, October 13, 2008 [Page 1]

Internet-Draft xcap diff event February April 2008

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 4
4. XCAP-Diff Event Package . . . . . . . . . . . . . . . . . . . 4
4.1. XCAP-Diff Processing Model . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 5 6
4.5. Subscription Duration . . . . . . . . . . . . . . . . . . 6 7
4.6. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 6 8
4.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 7 8
4.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 8 11
4.9. Handling of Forked Requests . . . . . . . . . . . . . . . 9 12
4.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 9 12
4.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 9 12
5. An Initial Example NOTIFY document . . . . . . . . . . . . . . 9 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. Registration of the "xcap-diff" Event Package . . . . . . 11 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 16
Appendix A. Informative Examples . . . . . . . . . . . . . . . . 16
A.1. Initial documents on an XCAP server . . . . . . . . . . . 16
A.2. An Initial Subscription . . . . . . . . . . . . . . . . . 17
A.3. A Document Addition Into a Collection . . . . . . . . . . 18
A.4. A Series of XCAP Component Modifications . . . . . . . . . 19
A.5. An XCAP Component Subscription . . . . . . . . . . . . . . 23
A.6. A Conditional Subscription . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 27
Intellectual Property and Copyright Statements . . . . . . . . . . 14 28

Urpalainen Expires August 28, October 13, 2008 [Page 2]

Internet-Draft xcap diff event February April 2008

1. Introduction

The SIP Events framework [RFC3265] describes subscription and
notification conventions for the SIP [RFC3261] protocol. The
Extensible Markup Language (XML) [W3C.REC-xml-20060816] Configuration
Access Protocol (XCAP) [RFC4825] allows a client to read, write and
modify 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 (except polling) to keep resources
equivalent 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 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
XML document takes place. It is also possible to subscribe to
documents within some collection [RFC4918], the notifier provides
then the documents where the user has read privilege.

Before being able to apply any patches into documents, a client needs
to first retrieve initial reference documents. With XCAP,

There are three basic features that this is
done event package enables with
the HTTP [RFC2616] protocol. The first "xcap-diff" XCAP-Diff [I-D.ietf-simple-xcap-diff] change notification thus contains references to subscribed documents,
thereafter notifications format.

Firstly, it can contain patches to these documents.
Some clients might need to retrieve only some specific element or
attribute list a collection [RFC4918] content from these of an XCAP
server, which means in practice listing the URI references of XCAP
documents without using from a collection. This is important when a subscriber is
doing an initial synchronization or a comparison of existing server
resources to the HTTP
protocol. All locally cached XCAP documents, for example. The
version-history of these use-cases document comparisons are based on the strong
entity tag (ETag) values of XCAP documents which are also indicated
with the XCAP-Diff format.

Secondly, this event package can signal whenever a change is
happening in those resources. The changes can be reported with three
ways. The simplest model is that only document creations, updates
and removals are indicated. The actual contents of those documents
are not shown and the subscriber uses the (HTTP) RFC 2616 [RFC2616]
protocol for a retrieval of document contents. The two more complex
modes allow the changes of documents to be indicated straightaway
with the XML-Patch-Ops [I-D.ietf-simple-xml-patch-ops] 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. The most complex model
produces the smallest documents but it doesn't necessarily show the
full HTTP version-history information unlike the other, but typically
more verbose one.

Lastly, 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

Urpalainen Expires October 13, 2008 [Page 3]

Internet-Draft xcap diff event April 2008

requested and indicated without the need of a separate HTTP GET
request. If this requested node either exists or is later created or
modified, the notification body indicates its content. And
similarly, the removals of subscribed XCAP components are reported,
for example after a successful HTTP DELETE request.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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:

Urpalainen Expires August 28, 2008 [Page 3]

Internet-Draft xcap diff event February 2008

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

Aggregating: While XCAP clients client can update only a single XCAP
component at a time, several time with a relevant HTTP request, a series of
these modifications can be aggregated together with the XML-Patch-Ops semantics. XML-Patch-
Ops semantics when they are indicated within the XCAP-Diff format.

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

4. XCAP-Diff Event Package

4.1. XCAP-Diff Processing Model

When a client starts an "xcap-diff" subscription it may not be aware Overview of Operation With Basic Requirements

Enabling all of the individual XCAP documents "xcap-diff" event package features require that
the subscriber MUST somehow signal to the notifier the resources it
is subscribing to. This can,
for instance happen when interested in getting information. These resource selections are
indicated simply by sending a user subscribes URI-list to his/her collection the notifier in the
subscription body. The URIs of this list MUST point to a
given collection,
a document or an XCAP Application Usage where several different clients update component. When collections are selected, the same XCAP documents. The initial notification can give
conventions applied follow the list
of these documents which (WebDAV) RFC 4918 [RFC4918] semantics,
that is, the authenticated user is allowed subscriber MUST add the forward slash "/" character to read.
The references and
the strong ETag values end of these the path segment of a URI. A collection selection
includes all documents are
shown so in that a client can separately fetch particular collection and recursively
also all documents in any of the possible sub-collections. The URI
of an XCAP component selector consists of the actual document
contents selector added

Urpalainen Expires October 13, 2008 [Page 4]

Internet-Draft xcap diff event April 2008

with the HTTP protocol. After these document retrievals, XCAP Node Selector. Although the subsequent SIP notifications can contain patches XCAP Node Selector allows
requesting all in-scope namespaces of an element, subscriptions to these
documents by using XML-Patch-Ops [I-D.ietf-simple-xml-patch-ops]
semantics.

While
them MUST NOT be used.

The first notification of the initial document synchronization is based on separate HTTP
retrievals subscription MUST always contain the
URI references of full documents, XML elements or attributes can be
received "in-band", that is straight within the <xcap-diff>
notification format. For example, an subscribed, existing documents and/or SHOULD
contain the subscribed XCAP element content can be
requested without content(s) and/or MUST contain
the need of a separate HTTP GET request by
providing a request URI with an subscribed XCAP Element Node Selector within the
subscription body. If the requested node can not be found with the
aid of this attribute content(s). The notifier MUST thus
always support XCAP Node Selector value, the node content isn't
naturally shown in the notification. Once component subscriptions. The subsequent
notifications MAY contain patches to these nodes will be
created, documents. The notifier
MUST support the simplest change notification bodies model, but the XML-
Patch-Ops diff-generation is RECOMMENDED to implement. The
subscriber MAY control how the notifier will indicate their content. And
similarly, signal the removals changes of subscribed XCAP components
documents. How this can be done, will be
reported, for example after shown later in this
document.

Whenever a successful HTTP DELETE request.

In yet another usage scenario, change in a subscriber to the "xcap-diff" event
might not need XML-Patch-Ops conventions at all. Indeed, the
subscriber just wants to be informed that resource or an update has happened, but
the subscriber XCAP component content is not interested in learning the actual changes of
indicated inside the document(s). The XCAP-Diff [I-D.ietf-simple-xcap-diff] format
will then only indicate document creations, updates and removals.

Urpalainen Expires August 28, 2008 [Page 4]

Internet-Draft xcap diff event February 2008 format,
the subscriber MUST have read privilege to that particular resource.

4.2. Event Package Name

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

4.3. 'diff-processing' Event Package Parameter

The

With aid of the optional "diff-processing" event header parameter the
subscriber directs the notifier how to apply the "XML diffing process". The
process" or in other words, how the notifier SHOULD indicate change
notifications of documents. The possible values are "no-patching", "xcap-patching", "aggregate".
"xcap-patching" and "aggregate" with the increasing complexity order.

The "no-patching" value (the simplest operational change
notification mode) means that only document or XCAP component existences MUST be creations,
modifications and removals are indicated.

The "xcap-patching" value means that all individual XCAP component
updates made by XCAP clients along with the entity tag (ETag)
changes MUST be are indicated.

The "aggregate" value means that the notifier is free to SHOULD aggregate
several individual XCAP component updates into a single XCAP-Diff
<document> element.

If the subscription does not contain this additional "diff-processing" "diff-
processing" parameter, the notifier MUST SHOULD send all individual

Urpalainen Expires October 13, 2008 [Page 5]

Internet-Draft xcap diff event April 2008

changes so that the client receives the full (HTTP) ETag change
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 either indicate the full HTTP ETag change
history.

Note: If the document history has versions from "a" to "b" to "c"
with corresponding ETag values "1", "2" and "3", the "xcap-
patching" mode indicates first the change from "a" to "b" with
previous "1" and new "2" ETags and also the change from "b" to "c"
with previous "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 "aggregate" mode tries to optimize the
change and indicates for example only a single aggregated change
from "a" to "c" with previous "1" and new "3" ETags. If these
changes are closely related, e.g. 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 a simpler operational mode
but it MUST NOT use 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 in the "xcap-patching" and "no-patching" modes.
Naturally, the "no-patching" request MUST be served only in the same
"no-patching" mode.

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

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

4.4. SUBSCRIBE Bodies

When generating a subscribe request, the subscriber needs to define

The list of the resources it is interested in getting information. This can be
done simply by sending a URI list to the SIP notifier. This list is requested URIs are described with by the XCAP resource
list [RFC4826] document format. format specified in RFC 4826 [RFC4826], and it is included as a
body of the SUBSCRIBE request that creates the subscription. Only a
simple subset of that format is needed here, that is required, a flat list of XCAP R-URIs.
The "uri" attribute of the <entry> element contains these URI values.
The usage of hierarchical lists and <entry> <entry-ref> references, etc. can thus
MUST NOT be omitted. used. However, using this format allows adding some
future semantics to these subscriptions. As it In subsequent SUBSCRIBE
requests, such as those used for refreshing the expiration timer, the
subscribed URI-list MAY change.

Urpalainen Expires October 13, 2008 [Page 6]

Internet-Draft xcap diff event April 2008

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. It is assumed that
the subscriber is provisioned 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 XCAP server will be collocated with the
SIP notifier, so the subscriber MAY use relative XCAP URIs. Although R-URIs. This
means that the notifier has then been provisioned somehow the XCAP Node Selector allows requesting all in-scope namespaces of an
element, subscriptions to them SHOULD NOT
Root URI value, for example. A future specification(s) MAY be used. When re-
subscribing within a current dialog,
written for the subscribed body MAY also
change.

In more complex use-cases, this event package, the Accept header SHOULD contain memo describes only the MIME type
"application/xcap-diff+xml" [I-D.ietf-simple-xcap-diff]. If no

Urpalainen Expires August 28, 2008 [Page 5]

Internet-Draft xcap diff event February 2008

Accept header
most simple one.

Note: It is specified to a SUBSCRIBE request, worth noting that the NOTIFY
messages will also contain bodies in this MIME type. Other MIME
types MAY be included in notifier and the Accept header.

Figure 2 shows an example to a subscription of several 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.

Figure 2 shows an example of a subscription body of several XCAP
resources: a "resource-list" document, a specific element in a "rls-
services" 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.
The "Content-Type" header of this SUBSCRIBE request is "application/
resource-lists+xml".

<?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 2: Example subscription body

When collections are selected as "pidf-manipulation" in the example,
the conventions applied follow the WebDAV [RFC4918] semantics, that
is, the subscriber MUST add the forward slash "/" character to the
end of the path segment. If a subscribed collection contains sub-
collections, the notifications will contain also the sub-collection
documents for which the user has read privilege.

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 October 13, 2008 [Page 7]

Internet-Draft xcap diff event April 2008

4.6. NOTIFY Bodies

The

As described in RFC 3265 [RFC3265], the NOTIFY bodies message will follow contain
bodies that describe the conventions state of the subscribed resource. This body
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 an XCAP
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 format [I-D.ietf-simple-xcap-diff] which can indicate the
full element and attribute content of XML documents, and for
documents the corresponding URIs, the ETag values and patching
instructions from version "a" to "b". Also the removals of
documents, elements and attributes can be shown. With other than
collection selections the "sel" selector values of the XCAP-Diff
format MUST be octet-by-octet

Urpalainen Expires August 28, 2008 [Page 6]

Internet-Draft xcap diff event February 2008 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 the notifier MUST first resolve the
requested XCAP resources. Once If the subscribed body contains elements
or attributes that it doesn't understand, they MUST be ignored by the
notifier. If there are superfluous resource selections in the
requested URI list, URI-list, the notifier SHOULD NOT provide overlapping
similar responses for these resources. Only the resources where the
authenticated user has read privilege, will MUST be included in the XCAP-Diff XCAP-
Diff format. Note that for example, an XCAP component which could
not be located with XCAP semantics, does not produce an error.
Instead, the request remains in a "pending" state, that is, waiting
for this resource to be created. 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 with the next
NOTIFY request.

After the list of authorized XCAP resources are known, the notifier will generate
generates the first full response. At this time depending on This initial notification body
contains URI references to subscribed existing documents and/or XCAP
component(s) actual existing content.

After sending the "diff-processing" parameter, initial notification, the notifier also usually starts MUST start the

Urpalainen Expires October 13, 2008 [Page 8]

Internet-Draft xcap diff event April 2008

follow-up of the subscribed XCAP component or document updates and unless otherwise directed, it reports all individual made
by XCAP
component updates with (HTTP) clients. The diff-processing parameter directs how
the ETag changes to notifier reports changes. Regardless of these operational modes,
the subscriber. If same end result is achieved, the
notifier process receives then resources MAY be kept in-sync.
Some intermediate states of the version-history of resources MAY be
lost by these notifications, but the chronological order of XCAP
changes MUST be maintained. The same rule applies if several changes
for a re-subscription given resource are indicated in a single notification, the
chronological order MUST follow the XML document order in the XCAP-
Diff document.

While with the diff-
processing=aggregate value most complex patching mode "aggregate" the bandwidth
usage is the most efficient, it MUST re-send introduces other challenges. The
initial synchronization MAY fail with rapidly changing resources,
because the "aggregate" mode doesn't necessarily indicate the current full XML-Diff
content unless
version-history of a document and the NOTIFY message will base XCAP protocol does not
support version-history retrievals of documents. Secondly, when new
documents are created into the subscribed collections and the
notifier is "aggregating" patches, the same issue MAY occur. In a
corner-case, the notifier may not be suppressed able to provide patches with the
conditional subscription [I-D.ietf-sip-subnot-etags] semantics by
using
XML-Patch-Ops [I-D.ietf-simple-xml-patch-ops] semantics. Therefore,
if the header Suppress-If-Match: [ETag value]. The notifier
SHOULD then start has to aggregate different individual patches together. temporarily disable 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 the appropriate aggregation diff-generation
(aggregation) logic themselves, for example how long to wait for
subsequent patches if there's already something to signal.

With a conditional re-subscription [I-D.ietf-sip-subnot-etags]

When the notifier MUST compare is acting in the "xcap-patching" mode, it MAY also
disable the subscription body diff-generation temporarily for some reason for certain
resources, for example when determining the
current NOTIFY body becomes impractically
large or an intermediate error has happened. All XCAP clients may
not try to optimize changes to its extremes, so even when acting in
the "xcap-patching" operational mode the notifier MAY try to optimize
the diff-generation.

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

When the notifier has reported that some XCAP components exist in a
document, it MUST also report their removals consistently. For

Urpalainen Expires October 13, 2008 [Page 9]

Internet-Draft xcap diff event April 2008

example, the removal of the parent element of the subscribed element
requires the same signalling since the subscribed element ceases to
exist after the removal. The removal of an XCAP component is
signalled by setting 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.

When the notifier process receives a re-subscription it MUST re-send
the current full XML-Diff content unless the NOTIFY message can be
suppressed with the conditional subscription
[I-D.ietf-sip-subnot-etags] semantics by using the header Suppress-
If-Match: [ETag value]. With a conditional re-subscription the
notifier MUST compare also the subscription body when determining the
current subscription state. Since the subscription is based on a
list of XCAP R-URIs it is RECOMMENDED when determining the
equivalence to "stored" previous states, that the order of appearance
of these URIs is not significant. Once a match to the previous state
is not found, the NOTIFY message MUST contain the full XML-Diff
state.

It can happen in some corner cases that the notifier can not or will
not provide patches with the XML-Patch-Ops
[I-D.ietf-simple-xml-patch-ops] semantics. One example of this is
when state
(similar to the diff format produces a larger content than initial notification). The notifiers SHOULD
implement the original
document is. When conditional subscription handling with this happens, and if the server has been in this
diff "aggregation" mode, it MUST fall back to the "xcap-patching"
mode for this particular resource.

Urpalainen Expires August 28, 2008 [Page 7]

Internet-Draft xcap diff event February 2008

It is RECOMMENDED to implement the XML-Patch-Ops processing on a
server. However, the notifier MUST support XCAP component
subscriptions. If for example, the subscriber has selected too many
elements to subscribe, so that the notification body would become
impractically large, the notifier MAY discard the <element> element
content. The existence of elements is then indicated with an empty
<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.
package.

Event packages like this require in practice a reliable transfer of
NOTIFY messages. This means that all messages MUST be successfully be
transferred as otherwise patching will most likely fail or at least
the document content contents becomes to be different. RFC 3265 [RFC3265]
proposes utilization of a "version" attribute information out-of-sync. This "xcap-diff"
event package requires, similar to state
deltas in chapter 4.4. Partial-PIDF-Notify
[I-D.ietf-simple-partial-notify] requires that the notifiers will not MUST NOT send a
new NOTIFY request to the same dialog unless a successful 200-
response
(200 OK) has been received for the last sent NOTIFY request. The latter applies
also to this "xcap-diff" event package. If the
NOTIFY request fails due to a timeout condition, the notifier MUST
remove the subscription.

4.8. Subscriber Processing

Note: This requirement ensures that out-of-order of NOTIFY Requests

The first NOTIFY request events will typically contain references to HTTP
resources including their strong ETag values. If the subscriber does
not have similar locally cached versions, it will start an
unconditional HTTP GET happen or that the dialog would continue after non-resolvable
NOTIFY request failures. In addition, some of the probable NOTIFY
error responses (e.g. 401,407,413) can possibly be handled
gracefully without tearing down the dialog.

If for those resources. During this HTTP
retrieval time example, the subscriber MAY also receive patches has selected too many elements to these
documents (notifications) if the documents are changing frequently.
It can thus happen
subscribe, so that the subscriber receives notification body would become impractically
large (e.g. an intermediate NOTIFY failure), the notifier MAY discard

Urpalainen Expires October 13, 2008 [Page 10]

Internet-Draft xcap diff event April 2008

the <element> element content. The existence of elements is then
indicated with an empty <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 the subscriber MAY also receive patches (if it has
requested them) to these documents if the documents are changing
frequently. It can thus happen that the subscriber receives newer
versions of documents (with HTTP) than what was indicated in the
initial notification. However,
once 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 chain the modification
list for a document and possibly omit some or all of the patches
based on the received ETag (with HTTP) of a document. After Indeed,
there's still a chance that the
subscriber MAY send a re-subscription to start received version by HTTP is newer
than any of those versions indicated in the diff "aggregation"
on notification so that an
equivalent match of an ETag value is not found from the server.

The subscriber can use CSeq values to keep track chain of possible missing
NOTIFY requests. These values
patches. This can easily be used to detect missing
"xcap-diff" events if there happen since notifications are no multiple usages in reported after the current
dialog. Also failing patches or inconsistent ETag value
actual HTTP changes can
be due to missing messages. Once and preferably at some minimum intervals. In
such a client detects an error it MUST
renew case, the subscription.

If subscriber SHOULD either wait for subsequent
notifications or refresh the subscription and repeat the described
"sync" algorithm until a diff format can not be applied because match is achieved.

The notifier MAY at any time disable (temporarily) the diff-
processing of some patch processing 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 the subscriber
MAY always disable the usage of diff-processing.

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

Urpalainen Expires August 28, October 13, 2008 [Page 8] 11]

Internet-Draft xcap diff event February April 2008

a case or in general, the safer way to avoid this out-of-sync issue
is to start the subscription with the "xcap-patching" mode, and
afterwards refresh the subscription to the "aggregate" mode.

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 it SHOULD refresh the
subscription to the "aggregate" mode.

If a diff format can not be applied because of some patch processing
and/or programming errors, look see Section 5.1 of
[I-D.ietf-simple-xml-patch-ops], the subscriber SHOULD renew refresh the
subscription and disable the usage of "diff-processing". It is
hardly reasonable to signal patching. The subscriber
SHOULD NOT reply with a non-200 response when this kind of error to the notifier even if the
error exists in
happens, since the notifier process. could hardly make any corrective actions.

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

4.9. Handling of Forked Requests

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

4.10. Rate of Notifications

Notifiers of "xcap-diff" event package SHOULD NOT generate
notifications for a single user 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 3 shows an example initial XCAP-Diff document provided by the
first NOTIFY request. The subscriber used the list as in the example
in Figure 2. An example event header of this SUBSCRIBE request:

Urpalainen Expires October 13, 2008 [Page 12]

Internet-Draft xcap diff event April 2008

Event: xcap-diff; diff-processing=aggregate

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

Note: If these documents are changing frequently during the
initial synchronization stage, it can happen that the subscriber
can not synchronize the contents of all documents properly.
However, the subscriber can always begin with the default "xcap-

Urpalainen Expires August 28, 2008 [Page 9]

Internet-Draft xcap diff event February 2008

patching" mode where all individual changes with the full ETag
change history are shown and this issue does not occur.

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

<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 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>

</xcap-diff>

Figure 3: An example initial XCAP-Diff 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 there is only a single document
where the user has read privilege. The <services> element exists
within the rls-services "index" document and its content is shown.

6. IANA Considerations

This memo calls for specification instructs IANA to:

o register to add a new event package name per [RFC3265]. to the

Urpalainen Expires August 28, October 13, 2008 [Page 10] 13]

Internet-Draft xcap diff event February April 2008

6.1. Registration of the "xcap-diff" Event Package

This specification instructs IANA to register an event package in the

SIP Event Types Namespace, based on the registration procedures
defined in RFC 3265 [RFC3265]. Namespace registry. The following is the information
required for such a registration: new data to be added is:

Package Name: Name Type Contact Reference
------------- -------- ------- ---------
xcap-diff

Package or Template-Package: This is a package.

Published Document: RFCXXXX[[NOTE TO IANA/RFC-EDITOR: Please replace
XXXX with the RFC number of this specification.]]

Person to Contact: Jari Urpalainen, jari.urpalainen@nokia.com package IETF SIP Working Group [RFCXXXX]
<sip@ietf.org>

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 basic authorization policy for
resources and as the notifications
will contain similar fragment content of
XCAP resources resources, the security considerations of XCAP also apply.

8. Acknowledgments The author would like
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 to thank Jonathan Rosenberg for his valuable
comments and providing a long list of URIs MAY be too process-
intensive. The "pending" subscriptions to un-existing documents or
XCAP components impose the initial event package, and Aki Niemi,
Miguel Garcia, Pavel Dostal, Krisztian Kiss, Anders Lindgren, Sofie
Lassborn, same challenge as well as the diff-
generation algorithms, at least when they try to optimize the
required bandwidth usage to extremes.

The mechanism used for conveying this 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 it is RECOMMENDED that TLS [RFC4346] 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 October 13, 2008 [Page 14]

Internet-Draft xcap diff event April 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 and Hinton, Byron Campen Campen,
Avshalom Houri, Ben Campbell and Paul Kyzivat for their valuable
comments.

9. References

9.1. Normative References

[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.

Urpalainen Expires August 28, 2008 [Page 11]

Internet-Draft xcap diff event February 2008
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.

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

[RFC4234]

[RFC5234] Crocker, D., Ed. D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 4234, October 2005. 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] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.

[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-07
draft-ietf-simple-xcap-diff-08 (work in progress),
November 2007.
February 2008.

[I-D.ietf-simple-xml-patch-ops]
Urpalainen, J., "An Extensible Markup Language (XML) Patch
Operations Framework Utilizing XML Path Language (XPath)

Urpalainen Expires October 13, 2008 [Page 15]

Internet-Draft xcap diff event April 2008

Selectors", draft-ietf-simple-xml-patch-ops-04 (work in
progress), November 2007.

[I-D.ietf-sip-subnot-etags]
Niemi, A., "An Extension to Session Initiation Protocol
(SIP) Events for Conditional Event Notification",
draft-ietf-sip-subnot-etags-01 (work Event Notification",
draft-ietf-sip-subnot-etags-02 (work in progress),
February 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]
Lonnfors, M., Costa-Requena, J., Leppanen, E., and H.
Khartabil, "Session Initiation Protocol (SIP) extension
for Partial Notification of Presence Information",
draft-ietf-simple-partial-notify-10 (work in progress),
January 2008.

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" event package. 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.

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) (there's no Default
Document Namespace defined in this imaginary AU).

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

<?xml version="1.0" encoding="UTF-8"?>
<doc>

Urpalainen Expires October 13, 2008 [Page 16]

Internet-Draft xcap diff event April 2008

<note>This is a sample document</note>
</doc>

and then

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

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

A.2. An Initial Subscription

The user Joe whose XUI is "sip:joe@example.com" does 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 first NOTIFY looks like:

Urpalainen Expires October 13, 2008 [Page 17]

Internet-Draft xcap diff event April 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/">

</xcap-diff>

The subscriber realizes that there's only a single document on this
"tests" Application Usage and it has already an equivalent locally
cached version so it doesn't do any actions. Had it a different
version locally, it would most likely re-fetch the document.

If the subscriber had requested "tests/users/" 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 a value "0" this is effectively a similar request
than the PROPFIND method of WebDAV, the syntax's 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
another client running on a different device where the subscriber
runs or it is on the same. So he does an HTTP PUT to his AU
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>

Urpalainen Expires October 13, 2008 [Page 18]

Internet-Draft xcap diff event April 2008

</doc>

As a result to this HTTP PUT request the XCAP client gets a strong
HTTP ETag "terteer" for this new document.

Then the subscriber receives a notification afterwards:

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/">

</xcap-diff>

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

If it is the same device doing modifications and the subscription,
the subscriber typically ignores this event. If it were an another
device it would probably do a re-fetch of this new document.

If the subscriber decides now to refresh 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 XCAP patching
capability, so it does the following:

Urpalainen Expires October 13, 2008 [Page 19]

Internet-Draft xcap diff event April 2008

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 the XCAP client receives the new HTTP ETag "fgherhryt3" of the
updated "index" document as the insertion of the element is
successful.

Immediately thereafter the XCAP client does again (even pipe-lining
could work):

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>

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

And yet again the XCAP client does:

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 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 October 13, 2008 [Page 20]

Internet-Draft xcap diff event April 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"?>
<d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">

<d:document previous-etag="7ahggs3"
sel="tests/users/sip:joe@example.com/index"
new-etag="63hjjsll">
<d:add sel="*"
><foo>this is a new element</foo><bar>this is a bar element
</bar><foobar>this is a foobar element</foobar></d:add>
</d:document>

</d:xcap-diff>

So the subscriber applies this patch to the locally cached "index"
document and also detects the ETag update (and stores the last ETag
value). Note that how several XCAP component modifications were
aggregated together. Note also that if the client hadn't had a
locally cached version 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 would be probable. So 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 and
simpler way to avoid the issue, is to refresh the subscription with
the "xcap-patching" mode and later refresh to 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 the
notifier, so as an alternative, the NOTIFY response could have been:

Urpalainen Expires October 13, 2008 [Page 21]

Internet-Draft xcap diff event April 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"?>
<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 is a new 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 is a bar element
</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 is a foobar element</foobar></d:add</d:document>

</d:xcap-diff>

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

And lastly the notifier could (temporarily) fall back to the "no-
patching" mode:

Urpalainen Expires October 13, 2008 [Page 22]

Internet-Draft xcap diff event April 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:d="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">

</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 any time, the notifier may fall back to this simplest mode for
some (or all) of the subscribed documents.

A.5. An XCAP Component Subscription

The user Joe does an initial subscription:

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 first NOTIFY looks like since
there's nothing to indicate:

Urpalainen Expires October 13, 2008 [Page 23]

Internet-Draft xcap diff event April 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/"/>

Afterwards Joe's XCAP client updates the whole document root element
(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>

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

Then 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]

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

</xcap-diff>

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

Urpalainen Expires October 13, 2008 [Page 24]

Internet-Draft xcap diff event April 2008

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]

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

</xcap-diff>

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. by a 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 a full refresh can be avoided when there are no
changes in progress),
August 2007.

9.2. Informative References

[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, June 2007. resources. The user Joe does an initial subscription:

Urpalainen Expires August 28, October 13, 2008 [Page 12] 25]

Internet-Draft xcap diff event February April 2008

[I-D.ietf-simple-partial-notify]
Lonnfors, M., "Session Initiation Protocol (SIP) extension
for Partial Notification

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 the 200 OK response, the first NOTIFY looks like
(since there are now two documents at the repository):

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/">

</xcap-diff>

Note that the NOTIFY request responds with the SIP-ETag "xggfefe54".
So a subscription refresh where the "diff-processing" mode is changed
(or is requested to change), looks like:

Urpalainen Expires October 13, 2008 [Page 26]

Internet-Draft xcap diff event April 2008

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>

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

Author's Address

Jari Urpalainen
Nokia
Itamerenkatu 11-13
Helsinki 00180
Finland

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

Urpalainen Expires August 28, October 13, 2008 [Page 13] 27]

Internet-Draft xcap diff event February April 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.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).

Urpalainen Expires August 28, October 13, 2008 [Page 14] 28]

----