rfc4825-xcap.txt

关于XCAP协议的rfc文档

Network Working Group                                       J. Rosenberg
Request for Comments: 4825                                         Cisco
Category: Standards Track                                       May 2007


                 The Extensible Markup Language (XML)
                  Configuration Access Protocol (XCAP)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

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 maps XML document sub-trees and element attributes
   to HTTP URIs, so that these components can be directly accessed by
   HTTP.























Rosenberg                   Standards Track                     [Page 1]

RFC 4825                          XCAP                          May 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Application Usages . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Application Unique ID (AUID) . . . . . . . . . . . . . . .  7
     5.2.  Default Document Namespace . . . . . . . . . . . . . . . .  8
     5.3.  Data Validation  . . . . . . . . . . . . . . . . . . . . .  9
     5.4.  Data Semantics . . . . . . . . . . . . . . . . . . . . . . 10
     5.5.  Naming Conventions . . . . . . . . . . . . . . . . . . . . 11
     5.6.  Resource Interdependencies . . . . . . . . . . . . . . . . 11
     5.7.  Authorization Policies . . . . . . . . . . . . . . . . . . 12
     5.8.  Data Extensibility . . . . . . . . . . . . . . . . . . . . 12
     5.9.  Documenting Application Usages . . . . . . . . . . . . . . 13
     5.10. Guidelines for Creating Application Usages . . . . . . . . 13
   6.  URI Construction . . . . . . . . . . . . . . . . . . . . . . . 15
     6.1.  XCAP Root  . . . . . . . . . . . . . . . . . . . . . . . . 15
     6.2.  Document Selector  . . . . . . . . . . . . . . . . . . . . 16
     6.3.  Node Selector  . . . . . . . . . . . . . . . . . . . . . . 18
     6.4.  Namespace Bindings for the Selector  . . . . . . . . . . . 23
   7.  Client Operations  . . . . . . . . . . . . . . . . . . . . . . 24
     7.1.  Create or Replace a Document . . . . . . . . . . . . . . . 26
     7.2.  Delete a Document  . . . . . . . . . . . . . . . . . . . . 26
     7.3.  Fetch a Document . . . . . . . . . . . . . . . . . . . . . 26
     7.4.  Create or Replace an Element . . . . . . . . . . . . . . . 26
     7.5.  Delete an Element  . . . . . . . . . . . . . . . . . . . . 29
     7.6.  Fetch an Element . . . . . . . . . . . . . . . . . . . . . 30
     7.7.  Create or Replace an Attribute . . . . . . . . . . . . . . 30
     7.8.  Delete an Attribute  . . . . . . . . . . . . . . . . . . . 31
     7.9.  Fetch an Attribute . . . . . . . . . . . . . . . . . . . . 31
     7.10. Fetch Namespace Bindings . . . . . . . . . . . . . . . . . 32
     7.11. Conditional Operations . . . . . . . . . . . . . . . . . . 32
   8.  Server Behavior  . . . . . . . . . . . . . . . . . . . . . . . 34
     8.1.  POST Handling  . . . . . . . . . . . . . . . . . . . . . . 35
     8.2.  PUT Handling . . . . . . . . . . . . . . . . . . . . . . . 35
       8.2.1.  Locating the Parent  . . . . . . . . . . . . . . . . . 35
       8.2.2.  Verifying Document Content . . . . . . . . . . . . . . 36
       8.2.3.  Creation . . . . . . . . . . . . . . . . . . . . . . . 37
       8.2.4.  Replacement  . . . . . . . . . . . . . . . . . . . . . 41
       8.2.5.  Validation . . . . . . . . . . . . . . . . . . . . . . 42
       8.2.6.  Conditional Processing . . . . . . . . . . . . . . . . 43
       8.2.7.  Resource Interdependencies . . . . . . . . . . . . . . 44
     8.3.  GET Handling . . . . . . . . . . . . . . . . . . . . . . . 44
     8.4.  DELETE Handling  . . . . . . . . . . . . . . . . . . . . . 45
     8.5.  Managing Etags . . . . . . . . . . . . . . . . . . . . . . 46
   9.  Cache Control  . . . . . . . . . . . . . . . . . . . . . . . . 47



Rosenberg                   Standards Track                     [Page 2]

RFC 4825                          XCAP                          May 2007


   10. Namespace Binding Format . . . . . . . . . . . . . . . . . . . 47
   11. Detailed Conflict Reports  . . . . . . . . . . . . . . . . . . 47
     11.1. Document Structure . . . . . . . . . . . . . . . . . . . . 48
     11.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 50
   12. XCAP Server Capabilities . . . . . . . . . . . . . . . . . . . 53
     12.1. Application Unique ID (AUID) . . . . . . . . . . . . . . . 54
     12.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 54
     12.3. Default Document Namespace . . . . . . . . . . . . . . . . 56
     12.4. MIME Type  . . . . . . . . . . . . . . . . . . . . . . . . 56
     12.5. Validation Constraints . . . . . . . . . . . . . . . . . . 56
     12.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 56
     12.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 56
     12.8. Resource Interdependencies . . . . . . . . . . . . . . . . 56
     12.9. Authorization Policies . . . . . . . . . . . . . . . . . . 56
   13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 59
   15. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 60
     15.1. XCAP Application Unique IDs  . . . . . . . . . . . . . . . 60
     15.2. MIME Types . . . . . . . . . . . . . . . . . . . . . . . . 61
       15.2.1. application/xcap-el+xml MIME Type  . . . . . . . . . . 61
       15.2.2. application/xcap-att+xml MIME Type . . . . . . . . . . 62
       15.2.3. application/xcap-ns+xml MIME Type  . . . . . . . . . . 63
       15.2.4. application/xcap-error+xml MIME Type . . . . . . . . . 64
       15.2.5. application/xcap-caps+xml MIME Type  . . . . . . . . . 64
     15.3. URN Sub-Namespace Registrations  . . . . . . . . . . . . . 65
       15.3.1. urn:ietf:params:xml:ns:xcap-error  . . . . . . . . . . 65
       15.3.2. urn:ietf:params:xml:ns:xcap-caps . . . . . . . . . . . 66
     15.4. XML Schema Registrations . . . . . . . . . . . . . . . . . 67
       15.4.1. XCAP Error Schema Registration . . . . . . . . . . . . 67
       15.4.2. XCAP Capabilities Schema Registration  . . . . . . . . 67
   16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 67
     17.2. Informative References . . . . . . . . . . . . . . . . . . 69

















Rosenberg                   Standards Track                     [Page 3]

RFC 4825                          XCAP                          May 2007


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.

   There are many examples of per-user information.  One is presence
   [20] authorization policy, which defines rules about which watchers
   are allowed to subscribe to a presentity, and what information they
   are allowed to access.  Another is presence lists, which are lists of
   users whose presence is desired by a watcher [26].  One way to obtain
   presence information for the list is to subscribe to a resource which
   represents that list [21].  In this case, the Resource List Server
   (RLS) requires access to this list in order to process a SIP [16]
   SUBSCRIBE [28] 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.

   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 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) [25], 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.

   XCAP was not designed as a general purpose XML search protocol, XML
   database update protocol, nor a general purpose, XML-based
   configuration protocol for network elements.









Rosenberg                   Standards Track                     [Page 4]

RFC 4825                          XCAP                          May 2007


2.  Overview of Operation

   Each application (where an application refers to a use case that
   implies a collection of data and associated semantics) that makes use
   of XCAP specifies an application usage (Section 5).  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 [6].  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 element or attribute within the document.  Thus, the HTTP URIs
   used by XCAP point to a document, or to pieces of information that
   are finer grained than the XML document itself.  An HTTP resource
   that follows the naming conventions and validation constraints
   defined here is called an XCAP resource.

   Since XCAP resources are also HTTP resources, they can be accessed
   using HTTP methods.  Reading an XCAP resource is accomplished with
   HTTP GET, creating or modifying one is done with HTTP PUT, and
   removing one of the resources is done with an HTTP DELETE.  XCAP
   resources do not represent processing scripts; as a result, POST
   operations to HTTP URIs representing XCAP resources are not defined.
   Properties that HTTP associates with resources, such as entity tags,
   also apply to XCAP resources.  Indeed, entity tags are particularly
   useful in XCAP, as they allow a number of conditional operations to
   be performed.

   XML documents that are equivalent for the purposes of many
   applications may differ in their physical representation.  With XCAP
   resources, the canonical form with comments [19] of an XML document
   determines the logical equivalence.  In other words, the canonical
   specification determines how significant whitespace MUST be
   processed.  It also implies that, for example, new inserted
   attributes may appear in any order within the physical
   representation.

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 [7] and
   indicate requirement levels for compliant implementations.



Rosenberg                   Standards Track                     [Page 5]

RFC 4825                          XCAP                          May 2007


4.  Definitions

   The following terms are used throughout this document:

   XCAP Resource:  An HTTP resource representing an XML document, an
      element within an XML document, or an attribute of an element
      within an XML document that follows the naming and validation
      constraints of XCAP.