draft-ietf-simple-xcap-07.txt

最新的xcap协议

SIMPLE                                                      J. Rosenberg
Internet-Draft                                             Cisco Systems
Expires: December 13, 2005                                 June 11, 2005


   The Extensible Markup Language (XML) Configuration Access Protocol
                                 (XCAP)
                       draft-ietf-simple-xcap-07

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 December 13, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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               Expires December 13, 2005               [Page 1]

Internet-Draft                    XCAP                         June 2005


Table of Contents

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



Rosenberg               Expires December 13, 2005               [Page 2]

Internet-Draft                    XCAP                         June 2005


     10.2   XML Schema . . . . . . . . . . . . . . . . . . . . . . .  41
   11.  XCAP Server Capabilities . . . . . . . . . . . . . . . . . .  44
     11.1   Application Unique ID (AUID) . . . . . . . . . . . . . .  45
     11.2   XML Schema . . . . . . . . . . . . . . . . . . . . . . .  45
     11.3   Default Namespace  . . . . . . . . . . . . . . . . . . .  46
     11.4   MIME Type  . . . . . . . . . . . . . . . . . . . . . . .  46
     11.5   Validation Constraints . . . . . . . . . . . . . . . . .  46
     11.6   Data Semantics . . . . . . . . . . . . . . . . . . . . .  46
     11.7   Naming Conventions . . . . . . . . . . . . . . . . . . .  47
     11.8   Resource Interdependencies . . . . . . . . . . . . . . .  47
     11.9   Authorization Policies . . . . . . . . . . . . . . . . .  47
   12.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  47
   13.  Security Considerations  . . . . . . . . . . . . . . . . . .  50
   14.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  51
     14.1   XCAP Application Unique IDs  . . . . . . . . . . . . . .  51
     14.2   MIME Types . . . . . . . . . . . . . . . . . . . . . . .  52
       14.2.1   application/xcap-el+xml MIME Type  . . . . . . . . .  52
       14.2.2   application/xcap-att+xml MIME Type . . . . . . . . .  53
       14.2.3   application/xcap-error+xml MIME Type . . . . . . . .  54
       14.2.4   application/xcap-caps+xml MIME Type  . . . . . . . .  55
     14.3   URN Sub-Namespace Registrations  . . . . . . . . . . . .  55
       14.3.1   urn:ietf:params:xml:ns:xcap-error  . . . . . . . . .  56
       14.3.2   urn:ietf:params:xml:ns:xcap-caps . . . . . . . . . .  56
     14.4   XML Schema Registrations . . . . . . . . . . . . . . . .  57
       14.4.1   XCAP Error Schema Registration . . . . . . . . . . .  57
       14.4.2   XCAP Capabilities Schema Registration  . . . . . . .  57
   15.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  58
   16.  References . . . . . . . . . . . . . . . . . . . . . . . . .  58
     16.1   Normative References . . . . . . . . . . . . . . . . . .  58
     16.2   Informative References . . . . . . . . . . . . . . . . .  59
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  60
        Intellectual Property and Copyright Statements . . . . . . .  61



















Rosenberg               Expires December 13, 2005               [Page 3]

Internet-Draft                    XCAP                         June 2005


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 [27].  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 [17]
   SUBSCRIBE [29] 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) [26], 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.

2.  Overview of Operation

   Each application 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 [7].  An XCAP server acts as
   a repository for collections of XML documents.  There will be



Rosenberg               Expires December 13, 2005               [Page 4]

Internet-Draft                    XCAP                         June 2005


   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 which 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.

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

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.

   XCAP Server: An HTTP server that understands how to follow the naming
      and validation constraints defined in this specification.

   XCAP Client: An HTTP client that understands how to follow the naming
      and validation constraints defined in this specification.

   Application: A collection of software components within a network
      whose operation depends on data managed and stored on an XCAP
      server.