SIMPLE J. Rosenberg
Internet-Draft dynamicsoft
Expires: August 15, 2004 February 15, 2004
The Extensible Markup Language (XML) Configuration Access Protocol
(XCAP)
draft-ietf-simple-xcap-02
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 15, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This specification defines the Extensible Markup Language (XML)
Configuration Access Protocol (XCAP). XCAP allows a client to read,
write and modify application configuration data, stored in XML format
on a server. XCAP is not a new protocol. XCAP maps XML document
sub-trees and element attributes to HTTP URIs, so that these
components can be directly accessed by HTTP.
Rosenberg Expires August 15, 2004 [Page 1]
Internet-Draft XCAP February 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
4. Application Usages . . . . . . . . . . . . . . . . . . . . 7
4.1 Application Usage ID (AUID) . . . . . . . . . . . . . . . 7
4.2 Data Validation . . . . . . . . . . . . . . . . . . . . . 7
4.3 Data Semantics . . . . . . . . . . . . . . . . . . . . . . 8
4.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . 8
4.5 Data Interdependencies . . . . . . . . . . . . . . . . . . 8
4.6 Authorization Policies . . . . . . . . . . . . . . . . . . 8
4.7 Data Extensibility . . . . . . . . . . . . . . . . . . . . 9
4.7.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 10
4.8 Documenting Application Usages . . . . . . . . . . . . . . 10
5. URI Construction . . . . . . . . . . . . . . . . . . . . . 11
5.1 Identifying the XML Document . . . . . . . . . . . . . . . 11
5.2 Identifying the XML Nodes . . . . . . . . . . . . . . . . 12
6. Client Operations . . . . . . . . . . . . . . . . . . . . 15
6.1 Create or Replace a Document . . . . . . . . . . . . . . . 15
6.2 Delete a Document . . . . . . . . . . . . . . . . . . . . 15
6.3 Fetch a Document . . . . . . . . . . . . . . . . . . . . . 15
6.4 Create or Replace an Element . . . . . . . . . . . . . . . 16
6.5 Delete an Element . . . . . . . . . . . . . . . . . . . . 17
6.6 Fetch an Element . . . . . . . . . . . . . . . . . . . . . 17
6.7 Create or Replace an Attribute . . . . . . . . . . . . . . 17
6.8 Delete an Attribute . . . . . . . . . . . . . . . . . . . 18
6.9 Fetch an Attribute . . . . . . . . . . . . . . . . . . . . 18
6.10 Read/Modify/Write Transactions . . . . . . . . . . . . . . 19
6.11 Reading Server Assigned Data . . . . . . . . . . . . . . . 19
7. Server Behavior . . . . . . . . . . . . . . . . . . . . . 21
7.1 POST Handling . . . . . . . . . . . . . . . . . . . . . . 21
7.2 PUT Handling . . . . . . . . . . . . . . . . . . . . . . . 22
7.2.1 Detailed Conflict Reports . . . . . . . . . . . . . . . . 23
7.2.1.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 25
7.3 GET Handling . . . . . . . . . . . . . . . . . . . . . . . 27
7.4 DELETE Handling . . . . . . . . . . . . . . . . . . . . . 28
7.5 Managing Etags . . . . . . . . . . . . . . . . . . . . . . 28
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . 33
10. IANA Considerations . . . . . . . . . . . . . . . . . . . 34
10.1 XCAP Application Usage IDs . . . . . . . . . . . . . . . . 34
10.2 application/xml-fragment-body MIME Type . . . . . . . . . 34
10.3 application/xml-attribute-value MIME Type . . . . . . . . 35
10.4 application/xcap-error+xml MIME Type . . . . . . . . . . . 36
10.5 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:xcap-must-understand . . . . . . . 37
10.6 URN Sub-Namespace Registration for
Rosenberg Expires August 15, 2004 [Page 2]
Internet-Draft XCAP February 2004
urn:ietf:params:xml:ns:xcap-error . . . . . . . . . . . . 38
10.7 XCAP Error Schema Registration . . . . . . . . . . . . . . 38
10.8 XCAP Mandatory Namespace Schema Registration . . . . . . . 39
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 40
Normative References . . . . . . . . . . . . . . . . . . . 41
Informative References . . . . . . . . . . . . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . 45
Rosenberg Expires August 15, 2004 [Page 3]
Internet-Draft XCAP February 2004
1. Introduction
In many communications applications, such as Voice over IP, instant
messaging, and presence, it is necessary for network servers to
access per-user information in the process of servicing a request.
This per-user information resides within the network, but is managed
by the end user themselves. Its management can be done through a
multiplicity of access points, including the web, a wireless handset,
or a PC application.
Examples of per-user information are presence [17] authorization
policy and presence lists. Presence lists are lists of users whose
presence is desired by a watcher. One way to obtain presence
information for the list of is to subscribe to a resource which
represents that list [20]. In this case, the Resource List Server
(RLS) requires access to this list in order to process a SIP
[15]SUBSCRIBE [25] request for it. Another way to obtain presence for
the users on the list is for a watcher to subscribe to each user
individually. In that case, it is convenient to have a server store
the list, and when the client boots, it fetches the list from the
server. This would allow a user to access their resource lists from
different clients.
Requirements for manipulation of presence lists and authorization
policies have been specified by the SIMPLE working group [21].
This specification describes a protocol that can be used to
manipulate this per-user data. It is called the Extensible Markup
Language (XML) Configuration Access Protocol (XCAP). XCAP is not a
new protocol. Rather, it is a set of conventions for mapping XML
documents and document components into HTTP URIs, rules for how the
modification of one resource affects another, data validation
constraints, and authorization policies associated with access to
those resources. Because of this structure, normal HTTP primitives
can be used to manipulate the data. XCAP is based heavily on ideas
borrowed from the Application Configuration Access Protocol (ACAP)
[23], but it is not an extension of it, nor does it have any
dependencies on it. Like ACAP, XCAP is meant to support the
configuration needs for a multiplicity of applications, rather than
just a single one.
Rosenberg Expires August 15, 2004 [Page 4]
Internet-Draft XCAP February 2004
2. Overview of Operation
Each application that makes use of XCAP specifies an application
usage (Section 4). This application usage defines the XML schema [2]
for the data used by the application, along with other key pieces of
information. The principal task of XCAP is to allow clients to read,
write, modify, create and delete pieces of that data. These
operations are supported using HTTP 1.1 [5]. An XCAP server acts as a
repository for collections of XML documents. There will be documents
stored for each application. Within each application, there are
documents stored for each user. Each user can have a multiplicity of
documents for a particular application. To access some component of
one of those documents, XCAP defines an algorithm for constructing a
URI that can be used to reference that component. Components refer to
any subtree of the document, or any attribute for any element within
the document. Thus, the HTTP URIs used by XCAP point to pieces of
information that are finer grained than the XML document itself.
With a standardized naming convention for mapping components of XML
documents to HTTP URIs, the basic operations for accessing the data
are provided by existing HTTP primitives. Reading one of the
components is accomplished with HTTP GET, creating or modifying one
of the components is done with an HTTP PUT, and removing one of the
components is done with an HTTP DELETE. To provide atomic read/
modify/write operations, HTTP entity tags are used.
Rosenberg Expires August 15, 2004 [Page 5]
Internet-Draft XCAP February 2004
3. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [6] and
indicate requirement levels for compliant implementations.
Rosenberg Expires August 15, 2004 [Page 6]
Internet-Draft XCAP February 2004
4. Application Usages
A central concept in XCAP is that of an application usage. An
application usage defines the way in which a specific application
makes use of XCAP.
4.1 Application Usage ID (AUID)
Each application usage is associated with a name, called an AUID.
This name uniquely identifies the application usage, and is different
from all other AUIDs. AUIDs exist in one of two namespaces. The first
namespace is the IETF namespace. This namespace contains a set of
tokens, each of which is registered with IANA. These registrations
occur with the publication of standards track RFCs [24] based on the
guidelines in Section 10. The second namespace is the
vendor-proprietary namespace. Each AUID in that namespace is prefixed
with the reverse domain name name of the organization creating the
AUID, followed by a period, followed by any vendor defined token. As
an example, the example.com domain can create an AUID with the value
"com.example.foo" but cannot create one with the value
"org.example.foo". AUIDs within the vendor namespace do not need to
be registered with IANA. The vendor namespace is also meant to be
used in lab environments where no central registry is needed. The
syntax for AUIDs, expressed in ABNF [11] (and using some of the BNF
defined in RFC 2396 [12]) is:
AUID = global-auid / vendor-auid
global-auid = auid
auid = alphanum / mark
vendor-auid = rev-hostname "." auid
rev-hostname = toplabel *( "." domainlabel )
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
4.2 Data Validation
One of the responsibilities of the server is to validate the data
generated by the client. This is done using two mechanisms. Firstly,
all application usages MUST describe their document contents using
XML schema [2]. Unfortunately, XML schemas cannot represent every
form of data constraint. As an example, one XML element may contain
an integer which defines the maximum number of instances of another
element. This constraint cannot be represented with XML schema.
However, such constraints may be important to the application usage.
The application usage defines any additional constraints beyond those
Rosenberg Expires August 15, 2004 [Page 7]
Internet-Draft XCAP February 2004
in the schema.
4.3 Data Semantics
For each application usage, the data present in the XML document has
a well defined semantic. The application usage defines that semantic,
so that a client can properly construct a document in order to
achieve the desired result.
4.4 Naming Conventions
In addition to defining the meaning of the document in the context of
a particular application, and application usage has to specify how
elements in that application obtain the various documents necessary
for operation of that application. In particular, what the relevant
URIs are that point to documents used by the application.
As an example, one application that can make use of XCAP is a SIP
event list subscription [20]. In this application, an entity is
defined called a Resource List Server (RLS). When the RLS receives a
subscription to a SIP URI that represents a list, it "expands" the
list and subscribes to its members. The XCAP resource list
application usage [22] specifies how the RLS uses XCAP to find the
XML document that defines the contents of the list.
These conventions are defined as naming conventions.
4.5 Data Interdependencies
In many cases, when a user modifies an XCAP resource, other data
managed by the server needs to change as well. Such interdependencies
are application usage dependent. As an example, when a user performs
a PUT operation to create a new presence list, the server may need to
fill in the URI associated with that list. These interdependencies
need to be specified by the application usage.
4.6 Authorization Policies
By default, an XCAP server will only allow a user to access (read,
write, delete or modify) their own documents. The application usage
can specify differing default authorization policies. An application
usage can also specify whether another application usage is used to
define the authorization policies. An application usage for setting
authorization policies can also be defined subsequent to the
definition of the the main application usage. In such a case, the
main application usage needs only to specify that such a usage will
be defined in the future.
Rosenberg Expires August 15, 2004 [Page 8]
Internet-Draft XCAP February 2004
4.7 Data Extensibility
An XCAP server MUST understand an application usage in order to
process an HTTP request made against a resource for that particular
application usage. However, it is not required for the server to
understand all of the contents of a document used by an application
usage. A server is required to understand the baseline schema defined
by the application usage. However, those schemas can define points of
extensibility where new content can be added from other namespaces
and corresponding schemas. Sometimes, the server will understand
those namespaces and therefore have access to their schemas.
Sometimes, it will not.
A server MUST allow for documents that contain elements from
namespaces not known to the server. In such a case, the server cannot
validate that such content is schema compliant; it will only verify
that the XML is well-formed.
Unfortunately, it may be the case that a client needs the server to
understand these new namespaces in order to process a document. This
will be the case when the new content contains data interdependcies
that the server has to understand. To allow for this, this
specification defines an XML element called "mandatory-ns". A server
will look for the presence of this element as the child of the root
node of any document. If it finds it, the server will make sure that
it is familiar with any namespaces (and their corresponding schemas)
listed there.
The implication is that the schema for all XCAP application usages
MUST allow for the "mandatory-ns" element to be present as a child of
the root node of any document. This can be done by explicitly
importing its namespace and including it in the schema, or allowing
elements from other namespaces to be present in the schema as
children of the root node.
Rosenberg Expires August 15, 2004 [Page 9]
Internet-Draft XCAP February 2004
4.7.1 XML Schema
Then, Bill decides he doesnt want Petri on the list, so he deletes
the entry (Section 6.5):
DELETE
http://xcap.example.com/services/presence-lists/users/bill/fr.xml/
presence-lists/list/list/entry[@name="Petri"] HTTP/1.1
Bill decides to check on the URI for Nancy, so he fetches a
particular attribute (Section 6.6):
Rosenberg Expires August 15, 2004 [Page 31]
Internet-Draft XCAP February 2004
GET
http://xcap.example.com/services/presence-lists/users/bill/fr.xml/
presence-lists/list/list/entry[@name="Nancy"]/@uri HTTP/1.1
and the server responds:
HTTP/1.1 200 OK
Etag: "ad88"
Content-Type:application/xml-attribute-value
"sip:nancy@example.com"
Rosenberg Expires August 15, 2004 [Page 32]
Internet-Draft XCAP February 2004
9. Security Considerations
Frequently, the data manipulated by XCAP contains sensitive
information. To avoid eavesdroppers from seeing this information, it
is RECOMMENDED that an admistrator hand out an https URI as the XCAP
root services URI. This will result in TLS-encrypted communications
between the client and server, preventing any eavesdropping.
Client and server authentication are also important. A client needs
to be sure it is talking to the server it believes it is contacting.
Otherwise, it may be given false information, which can lead to
denial of service attacks against a client. To prevent this, a client
SHOULD attempt to upgrade [14] any connections to TLS. Similarly,
authorization of read and write operations against the data is
important, and this requires client authentication. As a result, a
server SHOULD challenge a client using HTTP Digest [10] to establish
its identity, and this SHOULD be done over a TLS connection.
Rosenberg Expires August 15, 2004 [Page 33]
Internet-Draft XCAP February 2004
10. IANA Considerations
There are several IANA considerations associated with this
specification.
10.1 XCAP Application Usage IDs
This specification instructs IANA to create a new registry for XCAP
application usage IDs (AUIDs).
XCAP AUIDs are registered by the IANA when they are published in
standards track RFCs. The IANA Considerations section of the RFC
must include the following information, which appears in the IANA
registry along with the RFC number of the publication.
Name of the AUID. The name MAY be of any length, but SHOULD be no
more than twenty characters long. The name MUST consist of
alphanum [15] characters only.
Descriptive text that describes the application usage.
10.2 application/xml-fragment-body MIME Type
This specification registers a new MIME type according to the
procedures of RFC 2048 [7] and guidelines in RFC 3023 [8].
MIME media type name: application
MIME subtype name: xml-fragment-body
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [8].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [8].
Security considerations: See Section 10 of RFC 3023 [8].
Interoperability considerations: none.
Published specification: The XML Fragment Interchange [4], which
defines an XML fragment body as a well-balanced region of an XML
document being considered as (logically and/or physically)
separate from the rest of the document for the purposes of
defining it as a fragment.
Rosenberg Expires August 15, 2004 [Page 34]
Internet-Draft XCAP February 2004
Applications which use this media type: This document type has been
used to support transport of XML fragment bodies in RFC XXXX
[[NOTE TO RFC EDITOR: Please replace XXXX with the published RFC
number of this specification.]], the XML Configuration Access
Protocol (XCAP).
Additional Information:
Magic Number: None
File Extension: .xfb or .xml
Macintosh file type code: "TEXT"
Personal and email address for further information: Jonathan
Rosenberg, jdrosen@jdrosen.net
Intended usage: COMMON
Author/Change controller: The IETF.
10.3 application/xml-attribute-value MIME Type
This specification registers a new MIME type according to the
procedures of RFC 2048 [7] and guidelines in RFC 3023 [8].
MIME media type name: application
MIME subtype name: xml-attribute-value
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [8].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [8].
Security considerations: See Section 10 of RFC 3023 [8].
Interoperability considerations: none.
Published specification: An entity of this MIME type is compliant to
the grammar for AttValue as specified in XML 1.0 [1].
Rosenberg Expires August 15, 2004 [Page 35]
Internet-Draft XCAP February 2004
Applications which use this media type: This document type has been
used to support transport of XML attribute values in RFC XXXX
[[NOTE TO RFC EDITOR: Please replace XXXX with the published RFC
number of this specification.]], the XML Configuration Access
Protocol (XCAP).
Additional Information:
Magic Number: None
File Extension: .xav
Macintosh file type code: "TEXT"
Personal and email address for further information: Jonathan
Rosenberg, jdrosen@jdrosen.net
Intended usage: COMMON
Author/Change controller: The IETF.
10.4 application/xcap-error+xml MIME Type
This specification registers a new MIME type according to the
procedures of RFC 2048 [7] and guidelines in RFC 3023 [8].
MIME media type name: application
MIME subtype name: xcap-error+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [8].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [8].
Security considerations: See Section 10 of RFC 3023 [8].
Interoperability considerations: none.
Published specification: This specification.
Applications which use this media type: This document type conveys
error conditions defined in RFC XXXX. [[NOTE TO RFC EDITOR: Please
replace XXXX with the published RFC number of this
Rosenberg Expires August 15, 2004 [Page 36]
Internet-Draft XCAP February 2004
specification.]]
Additional Information:
Magic Number: None
File Extension: .xe
Macintosh file type code: "TEXT"
Personal and email address for further information: Jonathan
Rosenberg, jdrosen@jdrosen.net
Intended usage: COMMON
Author/Change controller: The IETF.
10.5 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:xcap-must-understand
This section registers a new XML namespace, as per the guidelines in
RFC 3688 [16].
URI: The URI for this namespace is
urn:ietf:params:xml:ns:xcap-must-understand
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
XML:
BEGIN
See RFCXXXX.
Rosenberg Expires August 15, 2004 [Page 37] Internet-Draft XCAP February 2004 END 10.6 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:xcap-error This section registers a new XML namespace, as per the guidelines in RFC 3688 [16]. URI: The URI for this namespace is urn:ietf:params:xml:ns:xcap-error Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net). XML: BEGINSee RFCXXXX.
END 10.7 XCAP Error Schema Registration This section registers an XML schema per the procedures in [16]. URI: please assign. Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net). Rosenberg Expires August 15, 2004 [Page 38] Internet-Draft XCAP February 2004 The XML for this schema can be found as the sole content of Section 7.2.1.1. 10.8 XCAP Mandatory Namespace Schema Registration This section registers an XML schema per the procedures in [16]. URI: please assign. Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net). The XML for this schema can be found as the sole content of Section 4.7.1. Rosenberg Expires August 15, 2004 [Page 39] Internet-Draft XCAP February 2004 11. Acknowledgements The author would like to thank Ben Campbell, Eva-Maria Leppanen, Hisham Khartabil, and Chris Newman for their input and comments. Rosenberg Expires August 15, 2004 [Page 40] Internet-Draft XCAP February 2004 Normative References [1] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C FirstEdition REC-xml-20001006, October 2000. [2] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, May 2001. [3] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C REC REC-xml-names-19990114, January 1999. [4] Grosso, P. and D. Veillard, "XML Fragment Interchange", W3C CR CR-xml-fragment-20010212, February 2001. [5] 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. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [8] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [9] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", W3C REC REC-xpath-19991116, November 1999. [10] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [11] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [13] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [14] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. Rosenberg Expires August 15, 2004 [Page 41] Internet-Draft XCAP February 2004 [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [16] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. Rosenberg Expires August 15, 2004 [Page 42] Internet-Draft XCAP February 2004 Informative References [17] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work in progress), January 2003. [18] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", draft-ietf-simple-winfo-package-05 (work in progress), January 2003. [19] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", draft-ietf-simple-winfo-format-04 (work in progress), January 2003. [20] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", draft-ietf-simple-event-list-04 (work in progress), June 2003. [21] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of Data Elements in Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Systems", draft-ietf-simple-data-req-03 (work in progress), June 2003. [22] Rosenberg, J., "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Presence Lists", draft-ietf-simple-xcap-list-usage-01 (work in progress), October 2003. [23] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997. [24] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [25] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. Rosenberg Expires August 15, 2004 [Page 43] Internet-Draft XCAP February 2004 Author's Address Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 EMail: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net Rosenberg Expires August 15, 2004 [Page 44] Internet-Draft XCAP February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Rosenberg Expires August 15, 2004 [Page 45] Internet-Draft XCAP February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Rosenberg Expires August 15, 2004 [Page 46]