SIMPLE WG R. Mahy
Internet-Draft Plantronics
Expires: September 6, 2006 March 5, 2006
A profile of the XML Configuration Access Protocol (XCAP) for
manipulating resource lists and authorization lists
draft-mahy-simple-xcap-profile-01.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 6, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a profile of XCAP (XML Configuration Access
Protocol) for manipulating SIMPLE resource lists and common policy
rule sets. While XCAP allows access to arbitrary XML document
subtrees, most XCAP implementations only need access to documents at
the specific points in the XML schema described by this profile.
Mahy Expires September 6, 2006 [Page 1]
Internet-Draft XCAP Resource-List Profile March 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Profile for XCAP Resource Lists . . . . . . . . . . . . . . 3
3. Profile for Common Policy Documents . . . . . . . . . . . . 6
4. A note about server validation . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . 10
Mahy Expires September 6, 2006 [Page 2]
Internet-Draft XCAP Resource-List Profile March 2006
1. Introduction
XCAP [1] (XML [5] Configuration Access Protocol) is a generic
configuration protocol layered on top of HTTP [8]. It uses XPath [7]
expressions and XML document fragments to hierarchically access
arbitrary subtrees of an XML document. In practice the full
flexibility of XCAP is often not needed by currently standardized
usages of XCAP. XCAP clients implementing these usages 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.
A major requirement which motivated the development of 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 [2].
Typically operations will operate either on an entire list, or on
individual entries in a list. Similarly, a presence authorization
list [3] is a common policy [4] document or "ruleset" that consists
of individual "rule" elements. Typically clients will only
manipulate whole rulesets or individual rules.
This document describes a Profile of XCAP which only accesses XCAP
documents at specific places in the XML document hierarchy. XCAP
Clients are encouraged to perform XCAP operations on groups or
individual resource-list entries, and on individual rules, but not to
access arbitrarily deep elements of the XCAP hierarchy. This profile
has two implementation benefits. Clients restricted to this profile
can easily construct XCAP URIs without using an XPath library.
Servers could optimize to this profile such that in-profile request
have greatly simplified schema validation requirements.
Note: In some places in this document, an XPath expression, an
HTTP URI or an XML attribute is "split" across multiple lines
This is done only to meet formatting requirements of this
document. Line splitting is not allowed "on the wire".
2. Profile for XCAP Resource Lists
When manipulating resource lists, requests within this profile are
limited so that XCAP clients only present XCAP URIs which manipulate
an entire resource-list XML document or one of the following specific
parent elements.
a single resource-list "list" element, accessed by its "name"
attribute, at any level of the document hierarchy up to the
maximum nesting depth.
Mahy Expires September 6, 2006 [Page 3]
Internet-Draft XCAP Resource-List Profile March 2006
an individual "entry" element accessed by its "uri" attribute
an individual "external" element accessed by its "anchor"
attribute
an individual "entry-ref" element accessed by its "ref" attribute
For the purposes of this profile, the maximum nesting depth for a
"list" element is 8. A "list" element which is the immediate child
of the "resource-lists" element has a depth of 1. A "list" element
at depth 8 is allowed, but if an XCAP client presents an XCAP URI
which includes a "list" element accessed at depth 9 or greater, the
request is not a profile-compliant request.
Performing XCAP operations on an XCAP URI with no path separator
("/~~") and no node selector refers to an entire XML resource-list
document, including the preamble. Performing XCAP
operations using one of these XPath expressions as the XCAP node
selector refers to an XML subtree which includes the referenced
node and all its decendants.
resource-lists
|
|- list
| |- entry
| |- entry-ref
| |- entry
| |- external
| |- list
| |- entry
| |- entry
|- list
|- entry
|- entry
For example, the following XPath expressions are all valid within
this profile for the provided example document.
Mahy Expires September 6, 2006 [Page 4]
Internet-Draft XCAP Resource-List Profile March 2006
Valid XPath expression in this profile
resource-lists/list[@name="Amigos"]
resource-lists/list[@name="Amigos"]/entry[@uri="sip:bob@example.com"]
resource-lists/list[@name="Amigos"]/entry-ref[@ref="aaaa"]
resource-lists/list[@name="Amigos"]/list[@name="close-friends"]
resource-lists/list[@name="Amigos"]/list[@name="close-friends"] \
/entry[@uri="sip:joe@example.com"]
resource-lists/list[@name="Amigos"]/list[@name="close-friends"] \
/external[@anchor="bbbb"]
Example Document
Bill Doe
Close Friends
Joe Smith
Nancy Gross
Marketing
The BNF for a resource list Node Selector (XPath expression) which
corresponds to this profile, is given below.
Mahy Expires September 6, 2006 [Page 5]
Internet-Draft XCAP Resource-List Profile March 2006
rl-node-sel = "resource-lists/" 1*16group [res-item]
group = "list" LSQ "@name=" DQUOT list-name DQUOT RSQ "/"
res-item = entry / entry-ref / external
entry = "entry" LSQ "@uri=" DQUOT uri DQUOT RSQ
entry-ref = "entry-ref" LSQ "@ref=" DQUOT uri DQUOT RSQ
external = "external" LSQ "@anchor=" DQUOT uri DQUOT RSQ
DQUOT = %22 ; <"> character, must be % encoded in URI
LSQ = %5b ; [ character, must be % encoded in URI
RSQ = %5d ; ] character, must be % encoded in URI
3. Profile for Common Policy Documents
When manipulating common policy documents, request within this
profile limit XCAP clients so they only present XCAP URIs which
manipulate an entire common policy XML document or an individual
"rule" element accessed by its "id" attribute". For example, the
following XPath expression is legal under this profile.
ruleset/rule[@id="f3gr2j"]
Below is the BNF for a common policy document node selector (XPath
expression).
cp-node-sel = "ruleset/rule" LSQ "@id=" DQUOT id DQOUT RSQ
DQUOT = %22 ; <"> character, must be % encoded in URI
LSQ = %5b ; [ character, must be % encoded in URI
RSQ = %5d ; ] character, must be % encoded in URI
4. A note about server validation
An XCAP server attempting to validate an XML subtree starting from an
individual list, entry, entry-ref, external element can merely
sandwich the provided XML document fragment inside an XML header and
a "test" list element, and pass the resulting XML to a validator
library. For example the following header and footer snippets are
suitable.
Mahy Expires September 6, 2006 [Page 6]
Internet-Draft XCAP Resource-List Profile March 2006
HEADER
FOOTER
Likewise, an XCAP server attempting to validate an XML subtree
starting from an individual rule element can merely sandwich the
provided XML document fragment inside an XML header and a top-level
ruleset element, as shown in this example.
HEADER
FOOTER
resource-lists
|
|- list
| |- entry
| |- entry-ref
| |- entry
| |- external
| |- list
| |- entry
| |- entry
|- list
|- entry
|- entry
5. Security Considerations
This document discusses a profile of XCAP (itself a usage of HTTP).
Mahy Expires September 6, 2006 [Page 7]
Internet-Draft XCAP Resource-List Profile March 2006
The security considerations of XCAP naturally apply to this document
as well. In addition, servers which implement this profile may take
advantage of the simplified URI grammar to use regular expressions
within a server. Extra care should be taken when implementing escape
encoding and decoding to prevent clients from using maliciously
crafted URIs to cause an unauthorized side effect. Clients and
servers implementing this approach MUST implement HTTP over TLS [9]
and HTTP Digest authentication [10].
6. IANA Considerations
This document requires no action by IANA.
7. 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),
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-07 (work in
progress), February 2006.
[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,
.
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
Mahy Expires September 6, 2006 [Page 8]
Internet-Draft XCAP Resource-List Profile March 2006
[9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 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.
Author's Address
Rohan Mahy
Plantronics
345 Encincal Street
Santa Cruz, CA
USA
Email: rohan@ekabal.com
Mahy Expires September 6, 2006 [Page 9]
Internet-Draft XCAP Resource-List Profile 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 6, 2006 [Page 10]