SIMPLE WG R. Mahy
Internet-Draft Plantronics
Expires: September 4, 2006 March 3, 2006
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-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes an alternative to XCAP (XML Configuration
Access Protocol) for manipulating SIMPLE resource and authorization
lists using WebDAV. XCAP and WebDAV are similar in that they are
both usages of HTTP. Since servers could support both
simultaneously, WebDAV support is a logical progression from XCAP for
clients that require locking, version control, document moves or
Mahy Expires September 4, 2006 [Page 1]
Internet-Draft A WebDAV alternative to XCAP March 2006
other features of WebDAV.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. A WebDAV Based Approach . . . . . . . . . . . . . . . . . . . 3
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 . . . . 10
3. Comparison of URLs in XCAP and WebDAV . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1 Normative References . . . . . . . . . . . . . . . . . . . 11
7.2 Informational References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 14
Mahy Expires September 4, 2006 [Page 2]
Internet-Draft A WebDAV alternative to XCAP March 2006
1. Introduction
XCAP [1] (XML [6] 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 [13])
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].
XCAP is layered on top of HTTP [9], and uses XPath [8] expressions
and XML document fragments to hierarchically access subtrees of an
XML document. In practice the full flexibility of XCAP is rarely
needed by currently standardized usages of XCAP. XCAP clients
implementing these usages are unlikely to independently access the
deepest nodes of an XML schema [7]. 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 HTTP
servers with WebDAV [10] extensions are used. Document fragments
representing "rule" and "entry" elements are represented by specific
WebDAV resources. Entire XML documents representing "ruleset"
elements and "list" elements are easily represented using dynamically
generated documents from specific collections.
XCAP operations are limited to single inserts, modifications, and
deletions; and XCAP has no concept of transactions or locking.
WebDAV supports moves, renames, locking, versioning, inherent access
control, and a framework to store supplementary metadata. Where
clients require these additional features (especially locking), or
when a client already implements WebDAV for calendaring or more
traditional file sharing applications, WebDAV becomes a logical
alternative to XCAP for resource-lists and ruleset maintenance.
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
Mahy Expires September 4, 2006 [Page 3]
Internet-Draft A WebDAV alternative to XCAP March 2006
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 [14].
This document provides two specific schema mappings described below.
For resource lists:
1. Elements "resource-lists" and "list" are collections.
2. The resource name of the collection representing the root of the
document is "resource-lists".
3. The resource name of the collection corresponding to "list"
elements is the name of the list.
4. Each "entry" element is an ordinary non-collection resource.
Each "external" element is a WebDAV redirectref resource [5]
whose reftarget property points to a "list" collection. Each
"entry-ref" element is a WebDAV redirect resource whose reftarget
property points to an "entry" resource.
5. Anywhere the "display-name" element appears, it is represented as
a WebDAV property.
6. The resource name of an "entry" element is its "uri" attribute.
The resource name of an "entry-ref" element is the "uri"
attribute of the entry resource at the targetref. Likewise, the
resource name of an "external" element is the "name" attribute of
the entry resource at the targetref.
7. Other attributes of "resource-lists", "list", and of the direct
children of a list element are modeled as WebDAV properties.
For common policy documents:
1. The element "ruleset" is modeled as a collection
2. All direct children of a "ruleset" element ("rule" elements) are
modeled as non-collection resources
3. The "id" attribute of a "rule" element is its resource name.
4. 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
Mahy Expires September 4, 2006 [Page 4]
Internet-Draft A WebDAV alternative to XCAP March 2006
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.
Note that sort order of collection can be specified using WebDAV
ordered collections [15].
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 September 4, 2006 [Page 5]
Internet-Draft A WebDAV alternative to XCAP March 2006
PUT /resource-lists/
If-None-Match: *
Content-Type: application/resource-lists+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 September 4, 2006 [Page 6]
Internet-Draft A WebDAV alternative to XCAP March 2006
GET /resource-list/Amigos/close-friends/ HTTP/1.1
Content-Type: application/resource-lists+xml
HTTP/1.1 200 OK
Content-Type: application/resource-lists+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 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 September 4, 2006 [Page 7]
Internet-Draft A WebDAV alternative to XCAP March 2006
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 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 September 4, 2006 [Page 8]
Internet-Draft A WebDAV alternative to XCAP March 2006
Operations on entry-ref and external elements use redirectref
resources.
MKREDIRECTREF /resource-lists/Coworkers/sip:fred@example.com
Content-Type: text/xml; charset="utf-8"
/resource-lists/Amigos/work/sip:fred@example.com
HTTP/1.1 201 Created
GET /resource-lists/Coworkers/sip:fred@example.com
HTTP/1.1 302 Found
Redirect-Ref: /resource-lists/Amigos/work/sip:fred@example.com
MKREDIRECTREF /resource-lists/Coworkers/myteam
Content-Type: text/xml; charset="utf-8"
/resource-lists/dreamteam/
HTTP/1.1 201 Created
GET /resource-lists/Coworkers/myteam/
HTTP/1.1 302 Found
Redirect-Ref: /resource-lists/dreamteam/
GET /resource-lists/Coworkers/
HTTP/1.1 200 OK
Content-Type: application/resource-lists+xml
Mahy Expires September 4, 2006 [Page 9]
Internet-Draft A WebDAV alternative to XCAP March 2006
Bill Doe
myteam
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.
Mahy Expires September 4, 2006 [Page 10]
Internet-Draft A WebDAV alternative to XCAP March 2006
3. Comparison of URLs in XCAP and WebDAV
Below are portions of the http: URL used to access certain parts of
the same resource-list or ruleset using XCAP and WebDAV.
XCAP WebDAV
http://example.com/ http://example.com/lists/~bob/
resource-lists/ OR
users/bob/ http://example.com/~bob/lists/
~~/resource-lists/
list[@name="Amigos"]/ Amigos/
entry[@uri="sip:alice@example.com"] sip:alice@example.com
ruleset[@name="privacy-rules"]/ privacy-rules/
rule[@id="1234"] 1234
4. Security Considerations
This document discusses two HTTP-based alternatives for manipulating
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 [11] and HTTP Digest authentication [12]. Note that by
using WebDAV, clients may take advantage of WebDAV Access Control
[16] to set access control for relevant WebDAV resources.
5. IANA Considerations
This document requires no action by IANA.
6. Acknowledgments
Thanks to 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-08 (work in progress), October 2005.
[2] Rosenberg, J., "Extensible Markup Language (XML) Formats for
Representing Resource Lists",
draft-ietf-simple-xcap-list-usage-05 (work in progress),
Mahy Expires September 4, 2006 [Page 11]
Internet-Draft A WebDAV alternative to XCAP March 2006
February 2005.
[3] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-04 (work in progress),
October 2005.
[4] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences", draft-ietf-geopriv-common-policy-06 (work in
progress), October 2005.
[5] Whitehead, J., "Web Distributed Authoring and Versioning
(WebDAV) Redirect Reference Resources",
draft-ietf-webdav-redirectref-protocol-13 (work in progress),
October 2005.
[6] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
October 2000, .
[7] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001,
.
[8] Clark, J. and S. DeRose, "XML Path Language (XPath) Version
1.0", W3C Recommendation xpath, November 1999,
.
[9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[10] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV",
RFC 2518, February 1999.
[11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[12] 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
[13] Khartabil, H., "The Conference Policy Control Protocol (CPCP)",
draft-ietf-xcon-cpcp-01 (work in progress), October 2004.
[14] Dusseault, L., "Calendaring Extensions to WebDAV (CalDAV)",
Mahy Expires September 4, 2006 [Page 12]
Internet-Draft A WebDAV alternative to XCAP March 2006
draft-dusseault-caldav-09 (work in progress), December 2005.
[15] Whitehead, J. and J. Reschke, Ed., "Web Distributed Authoring
and Versioning (WebDAV) Ordered Collections Protocol",
RFC 3648, December 2003.
[16] 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
Plantronics
345 Encincal Street
Santa Cruz, CA
USA
Email: rohan@ekabal.com
Mahy Expires September 4, 2006 [Page 13]
Internet-Draft A WebDAV alternative to XCAP March 2006
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 (2006). 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 September 4, 2006 [Page 14]