< draft-ietf-simple-xcap-diff-09.txt   draft-ietf-simple-xcap-diff-10.txt >
SIMPLE J. Rosenberg SIMPLE J. Rosenberg
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track J. Urpalainen Intended status: Standards Track J. Urpalainen
Expires: November 6, 2008 Nokia Expires: December 24, 2009 Nokia
May 5, 2008 June 22, 2009
An Extensible Markup Language (XML) Document Format for Indicating A An Extensible Markup Language (XML) Document Format for Indicating A
Change in XML Configuration Access Protocol (XCAP) Resources Change in XML Configuration Access Protocol (XCAP) Resources
draft-ietf-simple-xcap-diff-09 draft-ietf-simple-xcap-diff-10
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may not be modified,
have been or will be disclosed, and any of which he or she becomes and derivative works of it may not be created, except to format it
aware will be disclosed, in accordance with Section 6 of BCP 79. for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 6, 2008. This Internet-Draft will expire on December 24, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
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 Abstract
This specification defines a document format that can be used to This specification defines a document format that can be used to
indicate that a change has occurred in a document managed by the indicate that a change has occurred in a document managed by the
Extensible Markup Language (XML) Configuration Access Protocol Extensible Markup Language (XML) Configuration Access Protocol
(XCAP). This format indicates the document that has changed and its (XCAP). This format indicates the document that has changed and its
former and new entity tags. It also can indicate the specific change former and new entity tags. It also can indicate the specific change
that was made in the document, using an XML patch format. This that was made in the document, using an XML patch format. This
format allows also indications of element and attribute content of an format allows also indications of element and attribute content of an
skipping to change at page 2, line 23 skipping to change at page 3, line 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. application/xcap-diff+xml MIME Type . . . . . . . . . . . 11 7.1. application/xcap-diff+xml MIME Type . . . . . . . . . . . 11
7.2. URN Sub-Namespace Registration for 7.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 12 urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 12
7.3. Schema Registration . . . . . . . . . . . . . . . . . . . 13 7.3. Schema Registration . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
The Extensible Markup Language (XML) Configuration Access Protocol The Extensible Markup Language (XML) Configuration Access Protocol
(XCAP) [RFC4825] is a protocol that allows clients to manipulate XML (XCAP) [RFC4825] is a protocol that allows clients to manipulate XML
documents stored on a server. These XML documents serve as documents stored on a server. These XML documents serve as
configuration information for application protocols. As an example, configuration information for application protocols. As an example,
resource list [RFC4662] subscriptions (also known as presence lists) resource list [RFC4662] subscriptions (also known as presence lists)
allow a client to have a single SIP subscription to a list of users, allow a client to have a single SIP subscription to a list of users,
where the list is maintained on a server. The server will obtain where the list is maintained on a server. The server will obtain
skipping to change at page 3, line 49 skipping to change at page 3, line 49
just made, or due to a change another client made at around the same just made, or due to a change another client made at around the same
time. Furthermore, content indirections don't indicate how a time. Furthermore, content indirections don't indicate how a
document changed; they would only be able to indicate that it did document changed; they would only be able to indicate that it did
change. change.
To resolve these problems, this document defines a data format which To resolve these problems, this document defines a data format which
can convey the fact that an XML document managed by XCAP has changed. can convey the fact that an XML document managed by XCAP has changed.
This data format is an XML document format, called an XCAP diff This data format is an XML document format, called an XCAP diff
document. This format can indicate that a document has changed, and document. This format can indicate that a document has changed, and
provide its previous and new entity tags. It can also optionally provide its previous and new entity tags. It can also optionally
include a set of patch operations [I-D.ietf-simple-xml-patch-ops], include a set of patch operations [RFC5261], which indicate how to
which indicate how to transform the document from the version prior transform the document from the version prior to the change, to the
to the change, to the version after it. XML element and attribute version after it. XML element and attribute content of XCAP
content of XCAP documents can also be delivered with this format. documents can also be delivered with this format.
XML documents that are equivalent for the purposes of many XML documents that are equivalent for the purposes of many
applications may differ in their physical representation. Similar to applications may differ in their physical representation. Similar to
XCAP, the canonical form with comments [W3C.REC-xml-c14n-20010315] of XCAP, the canonical form with comments [W3C.REC-xml-c14n-20010315] of
an XML document determines the logical equivalence when this format an XML document determines the logical equivalence when this format
is used to patch XML documents. is used to patch XML documents.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 5, line 5 skipping to change at page 5, line 5
specification is a URN [RFC2141], using the namespace identifier specification is a URN [RFC2141], using the namespace identifier
'ietf' defined by [RFC2648] and extended by [RFC3688]. This URN is: 'ietf' defined by [RFC2648] and extended by [RFC3688]. This URN is:
urn:ietf:params:xml:ns:xcap-diff urn:ietf:params:xml:ns:xcap-diff
An XCAP diff document begins with the root element tag <xcap-diff>. An XCAP diff document begins with the root element tag <xcap-diff>.
This element has a single mandatory attribute, "xcap-root". The This element has a single mandatory attribute, "xcap-root". The
value of this attribute is the XCAP root URI for the documents in value of this attribute is the XCAP root URI for the documents in
which the changes have taken place. A single XCAP diff document can which the changes have taken place. A single XCAP diff document can
only represent changes in documents within the same XCAP root. The only represent changes in documents within the same XCAP root. The
content of the <xcap-diff> element is an unordered sequence of content of the <xcap-diff> element is a sequence of <document>,
<document>, <element> and <attribute> elements followed by any number <element> and <attribute> elements followed by any number of elements
of elements from other namespaces for the purposes of extensibility. from other namespaces for the purposes of extensibility. Any such
Any such unknown elements MUST be ignored by the client. Each unknown elements MUST be ignored by the client. If several
<document> element specifies changes in a specific document within <document> elements with the same "sel" selector value exist in the
the XCAP root. It has one mandatory attribute, "sel", and a two XCAP diff document, i.e. for example, the full ETag change history is
optional attributes, "new-etag" and "previous-etag". The "sel" indicated, the corresponding patches MUST be appliable in the given
attribute of the <document> element identifies the specific document document order. Each <document> element specifies changes in a
within the XCAP root for which changes are indicated. Its content specific document within the XCAP root. It has one mandatory
MUST be a relative path reference, with the base URI being equal to attribute, "sel", and a two optional attributes, "new-etag" and
the XCAP root URI. The "new-etag" attribute provides the entity tag "previous-etag". The "sel" attribute of the <document> element
(ETag) for the document after the application of the changes, identifies the specific document within the XCAP root for which
assuming the document exists after those changes. The "previous- changes are indicated. Its content MUST be a relative path
etag" attribute provides an identifier for the document instance reference, with the base URI being equal to the XCAP root URI. The
prior to the change. If the change being reported is the removal of "new-etag" attribute provides the entity tag (ETag) for the document
a document, the "previous-etag" MUST only be included and the "new- after the application of the changes, assuming the document exists
etag" attribute will not be present. The "new-etag" attribute MUST after those changes. The "previous-etag" attribute provides an
only exist alone when the document either exists or it was just identifier for the document instance prior to the change. If the
created (no patch included). Both attributes are present when a change being reported is the removal of a document, the "previous-
patch (or series of XCAP operations) has been applied to the etag" MUST only be included and the "new-etag" attribute will not be
resource. Also both attributes MAY be used to indicate an ETag present. The "new-etag" attribute MUST only exist alone when the
change without any document modifications (patches). document either exists or it was just created (no patch included).
Both attributes are present when a patch (or series of XCAP
operations) has been applied to the resource. Also both attributes
MAY be used to indicate an ETag change without any document
modifications (patches).
The "previous-etag" and "new-etag" need not have been sequentially The "previous-etag" and "new-etag" need not have been sequentially
assigned ETags at the server. An XCAP diff document can indicate assigned ETags at the server. An XCAP diff document can indicate
changes that have occurred over a series of XCAP operations. The changes that have occurred over a series of XCAP operations. The
only requirement then is that, the sequence of events, when executed only requirement then is that, the sequence of events, when executed
serially, will result in the transformation of the document with the serially, will result in the transformation of the document with the
ETag "previous-etag" to the one whose ETag is "new-etag". Also the ETag "previous-etag" to the one whose ETag is "new-etag". Also the
series of operations do not have to be the same exact series of series of operations do not have to be the same exact series of
operations that occurred at the server. If several <document> operations that occurred at the server.
elements with the same "sel" selector value exist in the XCAP diff
document, i.e. for example, the full ETag change history is
indicated, the corresponding patches MUST be appliable in the given
document order.
Each <document> element contains either a sequence of patching Each <document> element contains either a sequence of patching
instructions or an indication that the body hasn't semantically instructions or an indication that the body hasn't semantically
changed. The latter means that the document has been assigned a new changed. The latter means that the document has been assigned a new
ETag but its content is unchanged and it is indicated by the <body- ETag but its content is unchanged and it is indicated by the <body-
not-changed> element. Patching instructions are described by the not-changed> element. Patching instructions are described by the
<add>, <replace> and <remove> elements. These elements use the <add>, <replace> and <remove> elements. These elements use the
corresponding add, replace and remove types defined in corresponding add, replace and remove types defined in [RFC5261], and
[I-D.ietf-simple-xml-patch-ops], and define a set of patch operations define a set of patch operations that can be applied to transform the
that can be applied to transform the document. See document. See [RFC5261] for instructions on how this transformation
[I-D.ietf-simple-xml-patch-ops] for instructions on how this is effected. The <document> element can also contain elements from
transformation is effected. The <document> element can also contain other namespaces for the purposes of extensibility. The <add>,
elements from other namespaces for the purposes of extensibility. <replace> and <remove> elements allow extension attributes from any
The <add>, <replace> and <remove> elements allow extension attributes namespace. Any unknown elements <document> element or attributes of
from any namespace. Any unknown elements <document> element or patch operation elements MUST be ignored.
attributes of patch operation elements MUST be ignored.
Figure 1 shows <document> element content and how corresponding Figure 1 shows <document> element content and how corresponding
resource or metadata changes. An external document retrieval means resource or metadata changes. An external document retrieval means
in practice HTTP GET requests for target resources. in practice HTTP GET requests for target resources.
+-----------+----------+-----------+----------+-------------------+ +-----------+----------+-----------+----------+-------------------+
| previous- | new- | <add> | <body- | XCAP resource/ | | previous- | new- | <add> | <body- | XCAP resource/ |
| etag | etag | <replace> | not- | metadata change | | etag | etag | <replace> | not- | metadata change |
| | | <remove> | changed> | | | | | <remove> | changed> | |
+-----------+----------+-----------+----------+-------------------+ +-----------+----------+-----------+----------+-------------------+
skipping to change at page 6, line 45 skipping to change at page 6, line 44
Figure 1: <document> element content / corresponding resource changes Figure 1: <document> element content / corresponding resource changes
Each <element> element indicates the existing element content of an Each <element> element indicates the existing element content of an
XCAP document. It has one mandatory attribute, "sel", and one XCAP document. It has one mandatory attribute, "sel", and one
optional attribute, "exists". The "sel" attribute of the <element> optional attribute, "exists". The "sel" attribute of the <element>
element identifies an XML element of an XCAP document. It is a element identifies an XML element of an XCAP document. It is a
percent endoced relative URI following XCAP conventions when percent endoced relative URI following XCAP conventions when
selecting elements. The XCAP Node Selector MUST always locate a selecting elements. The XCAP Node Selector MUST always locate a
unique node, the "exists" attribute thus shows whether an element unique node, the "exists" attribute thus shows whether an element
exists or not in the XCAP document. When the "exists" attribute is exists or not in the XCAP document. When the "exists" attribute is
absent from the <element> element, it means that the indicated absent from the <element> element, the indicated element still exists
element still exists in the XCAP document. The located result in the XCAP document. The located result element exists as a child
element exists as a child element of the <element> element. It element of the <element> element. It should be noted, that only the
should be noted, that only the full content of an element is shown if full content of an element is shown if it exists, there are no
it exists, there are no conventions for patching these elements. In conventions for patching these elements. In a corner case where the
a corner case where the content of this element cannot be presented content of this element cannot be presented for some reason, although
for some reason, although it exists in the XCAP document, the it exists in the XCAP document, the <element> element MUST NOT have
<element> element MUST NOT have any child nodes. any child nodes.
As the result XML element is typically namespace qualified, all As the result XML element is typically namespace qualified, all
needed namespace declarations MUST exist within the <xml-diff> needed namespace declarations MUST exist within the <xml-diff>
document. The possible local namespace declarations within the document. The possible local namespace declarations within the
result element exist unmodified as in the source document, similar to result element exist unmodified as in the source document, similar to
XCAP conventions. Other namespace references MUST be resolved from XCAP conventions. Other namespace references MUST be resolved from
the context of the <element> or its parent elements. The prefixes of the context of the <element> or its parent elements. The prefixes of
qualified names (QName) [W3C.REC-xml-names-20060816] of XML nodes qualified names (QName) [W3C.REC-xml-names-20060816] of XML nodes
also remain as they exist originally in the source XCAP document. also remain as they exist originally in the source XCAP document.
Each <attribute> element indicates the existing attribute content of Each <attribute> element indicates the existing attribute content of
an XCAP document. It has one mandatory attribute, "sel", and one an XCAP document. It has one mandatory attribute, "sel", and one
optional attribute, "exists". The "sel" attribute of the <attribute> optional attribute, "exists". The "sel" attribute of the <attribute>
element identifies an XML attribute of an XCAP document. It is a element identifies an XML attribute of an XCAP document. It is a
percent endoced relative URI following XCAP conventions when percent endoced relative URI following XCAP conventions when
selecting attributes. The "exists" attribute indicates whether an selecting attributes. The "exists" attribute indicates whether an
attribute exists or not in the XCAP document. When the "exists" attribute exists or not in the XCAP document. When the "exists"
attribute is absent from the <attribute> element, it means that the attribute is absent from the <attribute> element, the indicated
indicated attribute still exists in the XCAP document. The child attribute still exists in the XCAP document. The child text node of
text node of the <attribute> element indicates the value of the the <attribute> element indicates the value of the located attribute.
located attribute. Note that if the attribute is namespace Note that if the attribute is namespace qualified, the query
qualified, the query parameter of the XCAP URI indicates the attached parameter of the XCAP URI indicates the attached namespace URI and
namespace URI and the prefix in the XCAP source document. the prefix in the XCAP source document.
4. XML Schema 4. XML Schema
The XML Schema for the XCAP diff format. The XML Schema for the XCAP diff format.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:xcap-diff" xmlns="urn:ietf:params:xml:ns:xcap-diff"
targetNamespace="urn:ietf:params:xml:ns:xcap-diff" targetNamespace="urn:ietf:params:xml:ns:xcap-diff"
elementFormDefault="qualified" elementFormDefault="qualified"
skipping to change at page 10, line 5 skipping to change at page 10, line 5
<!-- empty type --> <!-- empty type -->
<xs:complexType name="emptyType"/> <xs:complexType name="emptyType"/>
</xs:schema> </xs:schema>
5. Example Document 5. Example Document
The following is an example of a document compliant to the schema. The following is an example of a document compliant to the schema.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff" <xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/root/"> xcap-root="http://xcap.example.com/root/">
<document new-etag="7ahggs" <document new-etag="7ahggs"
sel="resource-lists/users/sip:joe@example.com/coworkers" sel="resource-lists/users/sip:joe@example.com/coworkers"
previous-etag="8a77f8d"/> previous-etag="8a77f8d"/>
<d:element sel="rls-services/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" /*/service%5b@uri='sip:marketing@example.com'%5d"
xmlns:d="urn:ietf:params:xml:ns:xcap-diff" xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xmlns="urn:ietf:params:xml:ns:rls-services" xmlns="urn:ietf:params:xml:ns:rls-services"
xmlns:rl="urn:ietf:params:xml:ns:resource-lists" xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
><service uri="sip:marketing@example.com"> ><service uri="sip:marketing@example.com">
<list name="marketing"> <list name="marketing">
<rl:entry uri="sip:joe@example.com"/> <rl:entry uri="sip:joe@example.com"/>
<rl:entry uri="sip:sudhir@example.com"/> <rl:entry uri="sip:sudhir@example.com"/>
</list> </list>
<packages> <packages>
<package>presence</package> <package>presence</package>
</packages> </packages>
</service></d:element> </service></d:element>
<attribute <attribute
sel="rls-services/users/sip:joe@example.com/index/~~/*/service/@uri" sel="rls-services/users/sip:joe@example.com/index/~~/*/service/@uri"
>sip:marketing@example.com</attribute> >sip:marketing@example.com</attribute>
</xcap-diff> </xcap-diff>
This indicates that the document with URI "http://xcap.example.com/ This indicates that the document with URI "http://xcap.example.com/
root/resource-lists/users/sip:joe@example.com/coworkers" has changed. root/resource-lists/users/sip:joe@example.com/coworkers" has changed.
Its previous entity tag is "8a77f8d" and its new one is "7ahggs" but Its previous entity tag is "8a77f8d" and its new one is "7ahggs" but
actual changes are not shown. The <service> element exists in the actual changes are not shown. The <service> element exists in the
rls-services "index" document and its full content is shown. Note rls-services "index" document and its full content is shown. Note
that the <service> element is attached with a default namespace that the <service> element is attached with a default namespace
declaration within the original document. Similarly, a "uri" declaration within the original document. Similarly, a "uri"
attribute content is shown from the same "index" document as an attribute content is shown from the same "index" document as an
illustrative example. illustrative example.
skipping to change at page 13, line 21 skipping to change at page 13, line 21
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net). Jonathan Rosenberg (jdrosen@jdrosen.net).
The XML for this schema can be found as the sole content of The XML for this schema can be found as the sole content of
Section 4. Section 4.
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Pavel Dostal, Jeroen van Bemmel, The authors would like to thank Pavel Dostal, Jeroen van Bemmel,
Martin Hynar, Anders Lindgren and Mary Barnes for their valuable Martin Hynar, Anders Lindgren, Mary Barnes and Ben Campbell for their
comments. valuable comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[W3C.REC-xml-20060816] [W3C.REC-xml-20060816]
Maler, E., Paoli, J., Bray, T., Yergeau, F., and C. Maler, E., Paoli, J., Bray, T., Yergeau, F., and C.
Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 Sperberg-McQueen, "Extensible Markup Language (XML) 1.0
(Fourth Edition)", World Wide Web Consortium (Fourth Edition)", World Wide Web Consortium
Recommendation REC-xml-20060816, August 2006, Recommendation REC-xml-20060816, August 2006,
skipping to change at page 14, line 18 skipping to change at page 14, line 18
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007. Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[I-D.ietf-simple-xml-patch-ops] [RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch
Urpalainen, J., "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath)
Operations Framework Utilizing XML Path Language (XPath) Selectors", RFC 5261, September 2008.
Selectors", draft-ietf-simple-xml-patch-ops-04 (work in
progress), November 2007.
9.2. Informative References 9.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
skipping to change at page 16, line 4 skipping to change at line 645
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Jari Urpalainen Jari Urpalainen
Nokia Nokia
Itamerenkatu 11-13 Itamerenkatu 11-13
Helsinki 00180 Helsinki 00180
Finland Finland
Phone: +358 7180 37686 Phone: +358 7180 37686
Email: jari.urpalainen@nokia.com Email: jari.urpalainen@nokia.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
 End of changes. 20 change blocks. 
93 lines changed or deleted 101 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/