SIMPLE WG R. Mahy
Internet-Draft Airespace
Expires: August 2, 2005 Feb 2005
An alternative to XML Configuration Access Protocol (XCAP) for
manipulating resource lists and authorization lists, Using HyperText
Transport Protocol (HTTP) extensions for Distributed Authoring and
Versioning (DAV)
draft-mahy-simple-xcap-alternative-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 2, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes an alternative to XCAP (XML Configuration
Access Protocol) for manipulating SIMPLE resource and authorization
lists using WebDAV. This alternative is motivated by initial
performance data that suggest that when XCAP Servers verify requests
satisfy a required property of HTTP (idempotency), performance may
Mahy Expires August 2, 2005 [Page 1]
Internet-Draft A WebDAV alternative to XCAP Feb 2005
drop non-trivially.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. A WebDAV Based Approach . . . . . . . . . . . . . . . . . . . 4
2.1 Operations on entire lists or rulesets . . . . . . . . . . 5
2.2 Operations on individual entries or rules . . . . . . . . 8
2.3 Pipelined operations on multiple entries or rules . . . . 9
3. Conclusion and recommendations: . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 10
7.2 Informational References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
Mahy Expires August 2, 2005 [Page 2]
Internet-Draft A WebDAV alternative to XCAP Feb 2005
1. Introduction
XCAP [1] (XML [5] Configuration Access Protocol) was originally
designed as a generic configuration protocol for many purposes.
While this vision is very compelling, some of the originally intended
users of this technology (ex: conference policy control [12])
selected other approaches which do not use a document metaphor for
their data. Currently XCAP usages are defined only for resource
lists [2] and authorization lists [3].
As a protocol layered on top of HTTP [8], XCAP requests must be
idempotent. This requires an XCAP Server to check if each
modification request is idempotent or not. Initial implementation
experience with these usages of XCAP suggests that there may be
substantial performance penalties verifying the idempotent nature of
PUT requests in XCAP. This document describes an alternative that
uses a small subset of ordinary WebDAV [9] extensions to HTTP. This
approach has the advantage that implementors can use off-the-shelf
web servers and WebDAV client libraries.
The extraordinary flexibility of XCAP is somewhat limited by the
requirement that XCAP uses HTTP request, which must be idempotent.
Since XCAP uses XPath [7] expressions and XML document fragments, it
is possible that a client could submit a request which is not
idempotent. The XCAP server needs to check if a request is
idempotent before accepting or rejecting it. Initial implementation
experience suggests that verifying the idempotency property is
extremely performance intensive. The time required to process an
insert operation in one implementation with and without this
verification step varies by several orders of magnitude.
In practice the full flexibility of XCAP is rarely needed by current
XCAP usages. XCAP clients are unlikely to independently access the
deepest nodes of an XML schema [6]. Typically, clients just need
access to one or two levels of hierarchy inside an XML document.
The primary requirement which motivated XCAP was the requirement for
some clients (especially wireless devices) to manipulate individual
peers ("buddies") in a presence list. These peers are represented by
"entry" elements in a resource list. Typically operations will
operate either on an entire list, or on individual entries in a list.
Similarly, an authorization list or "ruleset" consist of individual
"rule" elements. Typically clients will manipulate whole rulesets or
individual rules.
Instead this document describes an approach where standard WebDAV
servers are used. Document fragments representing "rule" and "entry"
elements are represented by specific WebDAV resources. Entire XML
Mahy Expires August 2, 2005 [Page 3]
Internet-Draft A WebDAV alternative to XCAP Feb 2005
documents representing "ruleset" elements and "list" elements are
easily represented using dynamically generated documents from
specific collections.
2. A WebDAV Based Approach
Briefly, WebDAV describes resources, collections, and properties. In
a typical file system, resources are represented as files or
directories, collections are represented as directories, and
properties are specific pieces of metadata associated with a
resource. However, WebDAV does not maintain rigid requirements about
the representation of resources. In practice, many resources and
even collections are dynamically generated. By definition
collections are simply resources which can contain other resources.
A URL referring to a collection always ends in a slash "/".
The key to the approach described in this document is that XML
documents that are designed for use with XCAP are described as
collections. Individual resources, and even other collections are
represented inside such a collection. Schema with potentially a
large number of similar objects are split so that some subparts of
the schema are represented as ordinary resources, and others are
represented as collections. This approach is similar to the pattern
used by CalDAV [13].
This document provides two specific schema mappings described below.
For resource lists:
Elements "resource-list" and "list" are modeled as collections.
Elements which are direct children of a list element (such as
"entry", "external", "entry-ref", and "display-name" elements) are
modeled as non-collection resources
The resource name of the collection corresponding to "list"
elements is the name of the list.
The resource name of the collection representing the root of the
document is "resource-list".
The resource name of "entry", "entry-ref", or "external" element
is the "uri", "ref", or "anchor" attribute of that element
(respectively).
Other attributes of "resource-list", "list", and of the direct
children of a list element are modeled as WebDAV properties.
For common policy documents:
The element "ruleset" is modeled as a collection
All direct children of a "ruleset" element ("rule" elements) are
modeled as non-collection resources
The "id" attribute of a "rule" element is its resource name.
Mahy Expires August 2, 2005 [Page 4]
Internet-Draft A WebDAV alternative to XCAP Feb 2005
The resource name of a ruleset can have any name.
WebDAV does not specify the specific behavior for GET, PUT, and POST
operations on collections. In practice, most implementations allow
for configurable or programmable handling of these operations for a
specific subtree in the URL hierarchy. Many implementations use the
Content-Type header as a hint to indicate how to process actions on
collections.
This approach can be implemented easily on existing web servers
very easily. Non-collection resources can be handled with almost
no new code, except to verify that the schema is correct when
content is created or changed. PUT requests to a collection can
be transformed into existing methods available on the server, by
breaking the collection up into individual resources. GET
requests on a collection can be transformed into a simple
aggregation of the resources accessible through existing methods
available on the server.
This document suggests using GET, PUT, and other operations on a
collection, to read or write a valid XML document at the
corresponding level in the hierarchy.
[TODO: Describe schema mapping in terms on an XPath or an XML
Expression.] Note that sort order of collection can be specified
using WebDAV ordered collections [14].
2.1 Operations on entire lists or rulesets
To create or modify an entire XML document which is accessible with
subhierarchy, the client just generates a PUT request with the entire
document. In this example, the client creates several resource
lists. In this case, the client uses the If-None-Match header to
make sure no content exists yet at this URI.
Mahy Expires August 2, 2005 [Page 5]
Internet-Draft A WebDAV alternative to XCAP Feb 2005
PUT /resource-lists/
If-None-Match: *
Content-Type: application/resource-list+xml
Bill Doe
Close Friends
Joe Smith
Nancy Gross
Marketing
Later, the client can fetch the entire document or a list at any
level of the hierarchy by sending a GET request for the corresponding
resource name for the collection. Here the client fetches just the
"close-friends" list.
Mahy Expires August 2, 2005 [Page 6]
Internet-Draft A WebDAV alternative to XCAP Feb 2005
GET /resource-list/Amigos/close-friends/ HTTP/1.1
Content-Type: application/resource-lists+xml
HTTP/1.1 200 OK
Content-Type: application/resource-lsits+xml
Close Friends
Joe Smith
Nancy Gross
Marketing
Similarly, the client can use the PUT request to replace a whole
subtree or create a new list, or DELETE to delete a new list.
PUT /resource-lists/enemies/
If-None-Match: *
Content-Type: application/resource-list+xml
DELETE /resource-lists/enemies/
If-Match: 329fj3
Deptch: infinity
MKCOL /resource-lists/enemies/
Mahy Expires August 2, 2005 [Page 7]
Internet-Draft A WebDAV alternative to XCAP Feb 2005
The MKCOL request would cause the server to create an empty
collection and initialize it with default values. The example below
would create a new list at the top level with the name attribute set
to "enemies". The MOVE and COPY requests would operate as expected,
allowing a client to rename a list, move a list, or copy a list from
one URI to another. Finally, the client could use PROPFIND and
PROPPATCH to read and write WebDAV properties. Below, the client
queries the xml:lang attribute on the "Amigos" collection.
PROPFIND /resource-lists/Amigos/ HTTP/1.1
Depth: 1
Content-Type: text/xml
HTTP/1.1 200 OK
Content-Type: text/xml
es
2.2 Operations on individual entries or rules
Operations on individual entries, entry-refs, and rules are similarly
easy.
GET /resource-lists/Amigos/close-friends/sip:joe@example.com
Content-Type: application/xml
HTTP/1.1 200 OK
Content-Type: application/xml
Joe Smith
Mahy Expires August 2, 2005 [Page 8]
Internet-Draft A WebDAV alternative to XCAP Feb 2005
To insert into a collection, the client selects a name for the
resource according to the rules in the schema mapping, and uses the
If-None-Match header to insure that there is no existing resource
with that same name. Modification of a specific resource is similar.
PUT /rulesets/pres/03489qdf8sd
If-None-Match: *
Content-Type: application/xml
PUT /resource-lists/Amigos/sip:fred@example.com
If-None-Match: *
Content-Type: application/xml
Deleting, renaming, moving, and copying individual resources all work
as expected.
2.3 Pipelined operations on multiple entries or rules
Occasionally, a client would like to add, delete, or modify multiple
snippets of a document while avoiding either multiple roundtrips or
operating on the entire document. Using HTTP Pipelining, a client
can send several requests in succession without waiting for a
roundtrip. This works very well for insert operations, and works
fine for modifications and deletions if the frequency of simultaneous
modification of the overall document is low.
3. Conclusion and recommendations:
The SIP/SIMPLE community needs to immediately examine implementation
performance of XCAP Servers with idempotency verification in
realistic environments. If initial performance data is
representative of production systems, the community should
investigate switching to another approach for list management. If
performance impact of idempotency verification is less than one order
of magnitude, the community this author recommends continuing with
XCAP.
4. Security Considerations
This document discusses two HTTP-based alternatives for manipulating
Mahy Expires August 2, 2005 [Page 9]
Internet-Draft A WebDAV alternative to XCAP Feb 2005
configuration documents with the same schema. The security
properties of the two approaches are expected to be extremely
similar, and the security considerations discussed in XCAP therefore
apply. Clients and servers implementing this approach MUST implement
HTTP over TLS [10] and HTTP Digest authentication [11]. Note that by
using WebDAV, clients may take advantage of WebDAV Access Control
[15] to set access control for relevant WebDAV resources.
5. IANA Considerations
This document requires no action by IANA.
6. Acknowledgments
Thanks for Lisa Dusseault for reviewing this document.
7. References
7.1 Normative References
[1] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-05 (work in progress), November 2004.
[2] Rosenberg, J., "Extensible Markup Language (XML) Formats for
Representing Resource Lists",
draft-ietf-simple-xcap-list-usage-04 (work in progress),
October 2004.
[3] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-01 (work in progress), October
2004.
[4] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences", draft-ietf-geopriv-common-policy-03 (work in
progress), October 2004.
[5] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
October 2000, .
[6] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001,
.
[7] Clark, J. and S. DeRose, "XML Path Language (XPath) Version
1.0", W3C Recommendation xpath, November 1999,
.
Mahy Expires August 2, 2005 [Page 10]
Internet-Draft A WebDAV alternative to XCAP Feb 2005
[8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[9] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen,
"HTTP Extensions for Distributed Authoring -- WEBDAV", RFC
2518, February 1999.
[10] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[11] 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.
7.2 Informational References
[12] Khartabil, H., "The Conference Policy Control Protocol (CPCP)",
draft-ietf-xcon-cpcp-01 (work in progress), October 2004.
[13] Dusseault, L., "Calendar Server Extensions for WebDAV
(CalDAV)", draft-dusseault-caldav-04 (work in progress),
December 2004.
[14] Whitehead, J. and J. Reschke, Ed., "Web Distributed Authoring
and Versioning (WebDAV) Ordered Collections Protocol", RFC
3648, December 2003.
[15] Clemm, G., Reschke, J., Sedlar, E. and J. Whitehead, "Web
Distributed Authoring and Versioning (WebDAV) Access Control
Protocol", RFC 3744, May 2004.
Author's Address
Rohan Mahy
Airespace
110 Nortech Pkwy
San Jose, CA 95134
USA
EMail: rohan@ekabal.com
Mahy Expires August 2, 2005 [Page 11]
Internet-Draft A WebDAV alternative to XCAP Feb 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Mahy Expires August 2, 2005 [Page 12]