SIMPLE WG R. Mahy
Internet-Draft SIP Edge LLC
Expires: April 20, 2006 October 17, 2005
A profile of the XML Configuration Access Protocol (XCAP) for
manipulating resource lists and authorization lists
draft-mahy-simple-xcap-profile-00.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 April 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
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 April 20, 2006 [Page 1]
Internet-Draft XCAP Resource-List Profile October 2005
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 April 20, 2006 [Page 2]
Internet-Draft XCAP Resource-List Profile October 2005
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 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 [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 can perform XCAP operations on groups or individual resource-
list entries, and on individual rules, but cannot 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
restricted to this profile can greatly simplify their 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, this profile restricts XCAP clients
so they 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.
an individual "entry" element accessed by its "uri" attribute
Mahy Expires April 20, 2006 [Page 3]
Internet-Draft XCAP Resource-List Profile October 2005
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 an XCAP client which supports this profile
MUST NOT present an XCAP URI which includes a "list" element accessed
at depth 9 or greater.
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 for the
provided example document.
Mahy Expires April 20, 2006 [Page 4]
Internet-Draft XCAP Resource-List Profile October 2005
Valid XPath expression in this profile
resource-lists/list[@name="Amigos"]
resource-lists/list[@name="Amigos"]/entry[@uri="sip:bill@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 April 20, 2006 [Page 5]
Internet-Draft XCAP Resource-List Profile October 2005
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, this profile restricts
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 April 20, 2006 [Page 6]
Internet-Draft XCAP Resource-List Profile October 2005
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 April 20, 2006 [Page 7]
Internet-Draft XCAP Resource-List Profile October 2005
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 mailiciously
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-07 (work in progress), June 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-03 (work in progress),
July 2005.
[4] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences", draft-ietf-geopriv-common-policy-05 (work in
progress), July 2005.
[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 April 20, 2006 [Page 8]
Internet-Draft XCAP Resource-List Profile October 2005
[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
SIP Edge LLC
Email: rohan@ekabal.com
Mahy Expires April 20, 2006 [Page 9]
Internet-Draft XCAP Resource-List Profile October 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 April 20, 2006 [Page 10]