< draft-ietf-simple-xcap-package-00.txt   draft-ietf-simple-xcap-package-01.txt >
SIMPLE J. Rosenberg SIMPLE J. Rosenberg
Internet-Draft dynamicsoft Internet-Draft dynamicsoft
Expires: December 22, 2003 June 23, 2003 Expires: August 16, 2004 February 16, 2004
A Session Initiation Protocol (SIP) Event Package for Modification A Session Initiation Protocol (SIP) Event Package for Modification
Events for the Extensible Markup Language (XML) Configuration Access Events for the Extensible Markup Language (XML) Configuration Access
Protocol (XCAP) Managed Documents Protocol (XCAP) Managed Documents
draft-ietf-simple-xcap-package-00 draft-ietf-simple-xcap-package-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. 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 December 22, 2003. This Internet-Draft will expire on August 16, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This specification defines a Session Initiation Protocol (SIP) event This specification defines a Session Initiation Protocol (SIP) event
package for finding out about changes to documents managed by the package for finding out about changes to documents managed by the
Extensible Markup Language (XML) Configuration Access Protocol Extensible Markup Language (XML) Configuration Access Protocol
(XCAP). XCAP allows a client to manipulate XML documents on a server (XCAP). XCAP allows a client to manipulate XML documents on a server
which contain configuration information for application protocols. which contain configuration information for application protocols.
Multiple clients can potentially access the same document, in which Multiple clients can potentially access the same document, in which
case the other clients would like to be notified of a change in the case the other clients would like to be notified of a change in the
document made by another. This event package allows a client to do document made by another. This event package allows a client to do
that. that.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Change Event Package . . . . . . . . . . . . . . . 4 2. Document Change Event Package . . . . . . . . . . . . . . . 4
2.1 Package Name . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Package Name . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Event Package Parameters . . . . . . . . . . . . . . . . . . 4 2.2 Event Package Parameters . . . . . . . . . . . . . . . . . . 4
2.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . 4 2.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Subscription Duration . . . . . . . . . . . . . . . . . . . 5 2.4 Subscription Duration . . . . . . . . . . . . . . . . . . . 5
2.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 5 2.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 5
2.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . . 6 2.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . . 6
2.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . . 6 2.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . . 7
2.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 7 2.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . . 7
2.9 Handling of Forked Requests . . . . . . . . . . . . . . . . 7 2.9 Handling of Forked Requests . . . . . . . . . . . . . . . . 8
2.10 Rate of Notifications . . . . . . . . . . . . . . . . . . . 8 2.10 Rate of Notifications . . . . . . . . . . . . . . . . . . . 8
2.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . . 8 2.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . . 8
3. application/xml-change Media Type . . . . . . . . . . . . . 9 3. application/xml-change+xml Media Type . . . . . . . . . . . 9
3.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Example Document . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Example Document . . . . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
5.1 SIP Event Package . . . . . . . . . . . . . . . . . . . . . 12 5.1 SIP Event Package . . . . . . . . . . . . . . . . . . . . . 14
5.2 application/xcap-change+xml MIME Type . . . . . . . . . . . 12 5.2 application/xcap-change+xml MIME Type . . . . . . . . . . . 14
5.3 URN Sub-Namespace Registration for 5.3 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:xcap-change . . . . . . . . . . . . . 13 urn:ietf:params:xml:ns:xcap-change . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . 15 Normative References . . . . . . . . . . . . . . . . . . . . 17
Informative References . . . . . . . . . . . . . . . . . . . 16 Informative References . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . 19
1. Introduction 1. Introduction
The Extensible Markup Language (XML) Configuration Access Protocol The Extensible Markup Language (XML) Configuration Access Protocol
(XCAP) [10] is a protocol that allows clients to manipulate XML (XCAP) [10] 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 [11] subscriptions (also known as presence lists) allow resource list [11] subscriptions (also known as presence lists) allow
a client to have a single SIP subscription to a list of users, where 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 presence the list is maintained on a server. The server will obtain presence
skipping to change at page 4, line 27 skipping to change at page 4, line 27
[2], this value appears in the Event header field present in [2], this value appears in the Event header field present in
SUBSCRIBE and NOTIFY requests. SUBSCRIBE and NOTIFY requests.
2.2 Event Package Parameters 2.2 Event Package Parameters
The SIP event framework allows event packages to define additional The SIP event framework allows event packages to define additional
parameters carried in the Event header field. This package defines a parameters carried in the Event header field. This package defines a
single event header parameter, called "doc-component", which single event header parameter, called "doc-component", which
specifies a particular document and document component which is being specifies a particular document and document component which is being
to subscribed to. The request-URI specifies the user whose data is to subscribed to. The request-URI specifies the user whose data is
being subscribed to. By default, a subscription is for all XCAP data being subscribed to. To subscribe to global data, a user agent would
associated with that user. The header field parameter allows the subscribed to a special user name that is configured into the UA. The
subscription to specify a specific document and document sub-tree. name "global-xcap-user" is RECOMMENDED, and SHOULD be used if no
explicit user name is provisioned. By default, a subscription is for
all XCAP data associated with that user. The header field parameter
allows the subscription to specify a specific document and document
sub-tree.
The format of this header field parameter is a quoted string, whose The format of this header field parameter is a quoted string. The
value is the portion of an XCAP URI to the right of the directory for value of this string is the portion of an XCAP URI to the right of
the user. For example, if a user wishes to subscribe to http:// the directory for the user, in the case of user data, or to the right
of the global directory for global data. The XCAP URI can only refer
to a document or to an element within that document. When the URI
represents a document, the subscription is to changes anywhere in the
document. When it is to an element, the subscription is to changes
that occur in the attributes or content of that element, including
all children. For example, if a user wishes to subscribe to http://
xcap.example.com/services/presence-lists/users/joe/mydir/friends.xml, xcap.example.com/services/presence-lists/users/joe/mydir/friends.xml,
the event header parameter would be "mydir/friends.xml". the event header parameter would be "mydir/friends.xml".
OPEN ISSUE: What does the request URI look like for subscriptions
to global data? Should the request URI instead contain the XCAP
URI as the user part? Might make sense, but interacts badly with
general SIP routing which is user-based.
OPEN ISSUE: There is no way to specify that a subscription is to OPEN ISSUE: There is no way to specify that a subscription is to
multiple documents. Multiple subscriptions would be needed for multiple documents. Multiple subscriptions would be needed for
that. Is that limitation OK for now? A filter can fix that down that. Is that limitation OK for now? A filter can fix that down
the road. the road.
2.3 SUBSCRIBE Bodies 2.3 SUBSCRIBE Bodies
A SUBSCRIBE request MAY contain a body. The purpose of the body A SUBSCRIBE request MAY contain a body. The purpose of the body
depends on its type. Subscriptions will normally not contain bodies. depends on its type. Subscriptions will normally not contain bodies.
The Request-URI, which identifies the user whose data is being The Request-URI, which identifies the user whose data is being
skipping to change at page 6, line 5 skipping to change at page 6, line 10
of an XML document managed by XCAP, in addition to the changes in of an XML document managed by XCAP, in addition to the changes in
this document from the previous version. Note that a listing of this document from the previous version. Note that a listing of
changes from the previous version is only sent in a NOTIFY triggered changes from the previous version is only sent in a NOTIFY triggered
by a change to the document. NOTIFY requests sent in response to an by a change to the document. NOTIFY requests sent in response to an
initial SUBSCRIBE, or a SUBSCRIBE refresh, only indicate the current initial SUBSCRIBE, or a SUBSCRIBE refresh, only indicate the current
version of the XML document. They do not contain the actual full version of the XML document. They do not contain the actual full
contents of the XML document. In other words, the resource being contents of the XML document. In other words, the resource being
subscribed to is NOT the XML document itself, but rather, the version subscribed to is NOT the XML document itself, but rather, the version
history for the document. history for the document.
OPEN ISSUE: This is the main issue in this specification. There
are three potential scopes. The first is that subscription is to
the document itself, in which case a full state update in a NOTIFY
contains the current document. The second is a subscription to the
revision history, which gives you changes, but not the full state
of the document. The third option is to just subscribe to the
etag, so that you know that something changed, but the
notifications don't tell you anything about what changed. Which do
we need? The latter is the simplest, good for the case where third
party modification of documents is rare.
All subscribers and notifiers MUST support the "application/ All subscribers and notifiers MUST support the "application/
xcap-change+xml" data format described in Section 3. The subscribe xcap-change+xml" data format described in Section 3. The subscribe
request MAY contain an Accept header field. If no such header field request MAY contain an Accept header field. If no such header field
is present, it has a default value of "application/xcap-change+xml". is present, it has a default value of "application/xcap-change+xml".
If the header field is present, it MUST include "application/ If the header field is present, it MUST include "application/
xcap-change+xml", and MAY include any other types capable of xcap-change+xml", and MAY include any other types capable of
representing changes in XCAP documents. representing changes in XCAP documents.
2.6 Notifier Processing of SUBSCRIBE Requests 2.6 Notifier Processing of SUBSCRIBE Requests
skipping to change at page 9, line 5 skipping to change at page 9, line 5
notifications at a rate of more than once every five seconds. notifications at a rate of more than once every five seconds.
2.11 State Agents 2.11 State Agents
RFC 3265 [2] requires each package to consider the role of state RFC 3265 [2] requires each package to consider the role of state
agents in the package, and if they are used, to specify how agents in the package, and if they are used, to specify how
authentication and authorization are done. authentication and authorization are done.
State agents play no role in this package. State agents play no role in this package.
3. application/xml-change Media Type 3. application/xml-change+xml Media Type
An xml-change document is an XML [4] document that MUST be An xml-change document is an XML [4] document that MUST be
well-formed and SHOULD be valid. XML-change documents MUST be based well-formed and SHOULD be valid. XML-change documents MUST be based
on XML 1.0 and MUST be encoded using UTF-8. This specification makes on XML 1.0 and MUST be encoded using UTF-8. This specification makes
use of XML namespaces for identifying xml-change documents and use of XML namespaces for identifying xml-change documents and
document fragments. The namespace URI for elements defined by this document fragments. The namespace URI for elements defined by this
specification is a URN [5], using the namespace identifier 'ietf' specification is a URN [5], using the namespace identifier 'ietf'
defined by [7] and extended by [8]. This URN is: defined by [7] and extended by [8]. This URN is:
urn:ietf:params:xml:ns:xml-change urn:ietf:params:xml:ns:xml-change
An xml-change document begins with the root element tag "documents". An xml-change document begins with the root element tag "documents".
It consists of any number of "document" sub-elements, each of which It consists of any number of "document" sub-elements, each of which
conveys information on a particular document. Other elements from conveys information on a particular document. Other elements from
different namespaces MAY be present for the purposes of different namespaces MAY be present for the purposes of
extensibility; elements or attributes from unknown namespaces MUST be extensibility; elements or attributes from unknown namespaces MUST be
ignored. There is one attribute associated with this element: ignored.
uri: specifies the HTTP URI that references this document. This
attribute is mandatory.
Each "document" element consists of zero or more "change" elements, Each "document" element consists of zero or more "change" elements,
each of which conveys information about a specific change to the each of which conveys information about a specific change to the
document. Other elements from different namespaces MAY be present for document. Other elements from different namespaces MAY be present for
the purposes of extensibility; elements or attributes from unknown the purposes of extensibility; elements or attributes from unknown
namespaces MUST be ignored. There are three attributes associated namespaces MUST be ignored. There are four attributes associated with
with this element: the "document" element:
version: specifies the new version of the document, expressed as an uri: specifies the HTTP URI that identifies the document.
HTTP-Date [9]. This attribute is mandatory.
previous: specifies the previous version of the document, expressed new-etag: specifies the etag of the document after the application of
as an HTTP-Date, against which the changes are relative. This the change. This attribute is mandatory.
attribute MUST be present if any change sub-elements are present.
previous-etag: specifies the etag of the version of the document
against which the change was made. This attribute MUST be present
if any change sub-elements are present.
hash: specifies an HMAC of the new document, represented in canonical hash: specifies an HMAC of the new document, represented in canonical
form. See Section 2.8 for details on how this value is computed. form. See Section 2.8 for details on how this value is computed.
This attribute MUST be present if any change sub-elements are This attribute MUST be present if any change sub-elements are
present. present.
Each "change" element contains either text, or additional XML Each "change" element contains text. This text contains the exact
content. This content is the same as that which appeared in the body value present in the HTTP request that caused the change in the
of the HTTP request which caused modification of the document. There document. If that content was XML, it is represented in the
are two attributes associated with this element: xml-change document as CDATA. There are two attributes associated
with this element:
uri: contains the URI that the HTTP request contained in the uri: contains the URI that the HTTP request contained in the
Request-URI. This attribute is mandatory. Request-URI. This attribute is mandatory.
method: contains the method of the HTTP request. This attribute is method: contains the method of the HTTP request. This attribute is
mandatory. mandatory.
OPEN ISSUE: Probably it would be better to describe the changes OPEN ISSUE: Probably it would be better to describe the changes
more generically, rather than binding them to the specifics of more generically, rather than binding them to the specifics of
XCAP. XCAP. Indeed, if there is any non-determinism in how the server
computes the document resulting from an XCAP operation, this
approach will not work. We can either use patch or define a
specific XML patch format.
3.1 XML Schema 3.1 XML Schema
TBD. <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:xml-change"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:xml-change"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="documents">
<xs:complexType>
<xs:sequence>
<xs:element name="tns:document" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="tns:change" type="xs:string" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="tns:uri" type="xs:anyURI" use="required"/>
<xs:attribute name="tns:new-etag" type="xs:string" use="required"/>
<xs:attribute name="tns:previous-etag" type="xs:string" use="optional"/>
<xs:attribute name="tns:hash" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:simpleType name="httpMethod">
<xs:restriction base="xs:string">
<xs:enumeration value="PUT"/>
<xs:enumeration value="DELETE"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
3.2 Example Document 3.2 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"?>
<documents xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <documents xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<document <document
uri="http://xcap.example.com/s/presence-lists/users/bill/foo.xml" uri="http://xcap.example.com/s/presence-lists/users/bill/foo.xml"
version="Mon, 26 May 2003 19:43:31 GMT" new-etag="asdnasd9asd8asd7"
previous="Sun, 25 May 2003 12:22:38 GMT" previous-etag="s99s99s9s9sjja"
hash="TBD"> hash="<hash value>">
<change method="PUT" <change method="DELETE"
uri="http://xcap.example.com/s/presence-lists/ uri="http://xcap.example.com/s/presence-lists/
users/bill/foo.xml?presence-lists/entry[@name="bob"]/uri"> users/bill/foo.xml?presence-lists/entry[@name="bob"]/uri"/>
sip:bob@example.com</change>
</document> </document>
</documents> </documents>
4. Security Considerations 4. Security Considerations
The security considerations for this package are similar to those of The security considerations for this package are similar to those of
XCAP. The configuration data can contain sensitive information, and XCAP. The configuration data can contain sensitive information, and
both the client and the server need to authenticate each other. As both the client and the server need to authenticate each other. As
such, a notifier for this package MUST support HTTP Digest to such, a notifier for this package MUST support HTTP Digest to
authenticate subscribers. Notifiers and subscribers MAY use SIPs S/ authenticate subscribers. Notifiers and subscribers MAY use SIPs S/
skipping to change at page 12, line 16 skipping to change at page 14, line 16
There are several IANA considerations associated with this There are several IANA considerations associated with this
specification. specification.
5.1 SIP Event Package 5.1 SIP Event Package
This specification registers an event package, based on the This specification registers an event package, based on the
registration procedures defined in RFC 3265 [2]. The following is the registration procedures defined in RFC 3265 [2]. The following is the
information required for such a registration: information required for such a registration:
Package Name: presence Package Name: xml-change
Package or Template-Package: This is a package. Package or Template-Package: This is a package.
Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX
with the RFC number of this specification). with the RFC number of this specification).
Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net. Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.
5.2 application/xcap-change+xml MIME Type 5.2 application/xcap-change+xml MIME Type
skipping to change at page 13, line 47 skipping to change at page 15, line 47
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>XCAP Change Namespace</title> <title>XCAP Change Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for XCAP Change</h1> <h1>Namespace for XCAP Change</h1>
<h2>application/xcap-change+xml</h2> <h2>urn:ietf:params:xml:ns:change-xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
Normative References Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[3] Boyer, J., "Canonical XML Version 1.0", W3C REC [3] Boyer, J., "Canonical XML Version 1.0", W3C REC
REC-xml-c14n-20010315, March 2001. REC-xml-c14n-20010315, March 2001.
[4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, [4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
REC REC-xml-20001006, October 2000. FirstEdition REC-xml-20001006, October 2000.
[5] Moats, R., "URN Syntax", RFC 2141, May 1997. [5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[6] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC [6] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001. 3023, January 2001.
[7] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, [7] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999. August 1999.
[8] Mealling, M., "The IETF XML Registry", [8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
draft-mealling-iana-xmlns-registry-05 (work in progress), June January 2004.
2003.
[9] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., [9] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[10] Rosenberg, J., "The Extensible Markup Language (XML) [10] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", Configuration Access Protocol (XCAP)",
draft-rosenberg-simple-xcap-00 (work in progress), May 2003. draft-ietf-simple-xcap-01 (work in progress), October 2003.
Informative References Informative References
[11] Rosenberg, J., Roach, A. and B. Campbell, "A Session Initiation [11] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation
Protocol (SIP) Event Notification Extension for Resource Protocol (SIP) Event Notification Extension for Resource
Lists", draft-ietf-simple-event-list-04 (work in progress), Lists", draft-ietf-simple-event-list-04 (work in progress),
June 2003. June 2003.
[12] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing [12] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997. for Message Authentication", RFC 2104, February 1997.
[13] Rosenberg, J., "An Extensible Markup Language (XML) [13] Rosenberg, J., "An Extensible Markup Language (XML)
Configuration Access Protocol (XCAP) Usage for Presence Lists", Configuration Access Protocol (XCAP) Usage for Presence
draft-rosenberg-simple-xcap-list-usage-00 (work in progress), Lists", draft-ietf-simple-xcap-list-usage-01 (work in
May 2003. progress), October 2003.
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
skipping to change at page 17, line 29 skipping to change at page 19, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 18, line 7 skipping to change at page 20, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 33 change blocks. 
68 lines changed or deleted 117 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/