draft-ietf-simple-xcap-07.txt

最新的xcap协议

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


   Application Usage: Detailed information on the interaction of an
      application with the XCAP server.

   Application Unique ID (AUID): A unique identifier within the
      namespace of application unique IDs created by this specification
      that differentiates XCAP resources accessed by one application
      from XCAP resources accessed by another.

   Naming Conventions: The part of an application usage that specifies
      well-known URIs used by an application, or more generally,
      specifies the URIs that are typically accessed by an application
      during its processing.

   XCAP User Identifier (XUI): The XUI is a string, valid as a path
      element in an HTTP URI, that is associated with each user served
      by the XCAP server.

   XCAP Root: A context that contains all of the documents across all
      application usages and users that are managed by the server.

   Document Selector: A sequence of path segments, with each segment
      being separated by a "/", that identify the XML document within an
      XCAP root that is being selected.

   Node Selector: A sequence of path segments, with each segment being
      separated by a "/", that identify the XML node (element or
      attribute) being selected within a document.

   Path Separator: A single path segment equal to two tilde characters
      "~~" that is used to separate the document selector from the node
      selector within an HTTP URI.

   Document URI: The HTTP URI containing the XCAP root and document
      selector, resulting in the selection of a specific document.  As a
      result, performing a GET against the document URI would retrieve
      the document.

   Node URI: The HTTP URI containing the XCAP root, document selector,
      path separator and node selector, resulting in the selection of a
      specific XML node.

   XCAP Root URI: An HTTP URI that representing the XCAP root.  Although
      a syntactically valid URI, the XCAP Root URI does not correspond
      to an actual resource on an XCAP server.  Actual resources are
      created by appending additional path information to the XCAP Root
      URI.





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


   Global Tree: A URI that represents the parent for all global
      documents for a particular application usage within a particular
      XCAP root.

   Home Directory: A URI that represents the parent for all documents
      for a particular user for a particular application usage within a
      particular XCAP root.

   Positional Insertion: A PUT operation that results in the insertion
      of a new element into a document such that its position relative
      to other children of the same parent is set by the client.


5.  Application Usages

   Each XCAP resource on a server is associated with an application.  In
   order for an application to use those resources, application specific
   conventions must be specified.  Those conventions include the XML
   schema that defines the structure and constraints of the data, well
   known URIs to bootstrap access to the data, and so on.  All of those
   application specific conventions are defined by the application
   usage.

5.1  Application Unique ID (AUID)

   Each application usage is associated with a name, called an
   Application Unique ID (AUID).  This name uniquely identifies the
   application usage within the namespace of application usages, and is
   different from AUIDs used by other applications.  AUIDs exist in one
   of two namespaces.  The first namespace is the IETF namespace.  This
   namespace contains a set of tokens, each of which is registered with
   IANA.  These registrations occur with the publication of standards
   track RFCs [28] based on the guidelines in Section 14.  The second
   namespace is the vendor-proprietary namespace.  Each AUID in that
   namespace is prefixed with the reverse domain name of the
   organization creating the AUID, followed by a period, followed by any
   vendor defined token.  As an example, the example.com domain can
   create an AUID with the value "com.example.foo" but cannot create one
   with the value "org.example.foo".  AUIDs within the vendor namespace
   do not need to be registered with IANA.  The vendor namespace is also
   meant to be used in lab environments where no central registry is
   needed.  The syntax for AUIDs, expressed in ABNF [13] (and using some
   of the BNF defined in RFC 3986 [14]) is:








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


   AUID             =  global-auid / vendor-auid
   global-auid      =  auid
   auid             =  1*pchar
   vendor-auid      =  rev-hostname "." auid
   rev-hostname     =  toplabel *( "." domainlabel  )
   domainlabel      =  alphanum
                       / alphanum *( alphanum / "-" ) alphanum
   toplabel         =  ALPHA / ALPHA *( alphanum / "-" ) alphanum


5.2  Default Namespace Binding

   In order for the XCAP server to match a URI to an element or
   attribute of a document, any XML namespace prefixes used within the
   URI must be expanded [3].  This expansion requires a namespace
   binding context.  That context maps namespace prefixes to namespace
   URIs.  It also defines a default namespace that applies to elements
   without namespace prefixes.  The namespace binding context comes from
   two sources.  Firstly, the mapping of namespace prefixes to namespace
   URIs is obtained from the URI itself (see Section 6.4).  However, the
   default namespace URI is defined by the application usage itself, and
   applies to all URIs referencing resources within that application
   usage.  All application usages MUST define a namespace URI that
   represents the default namespace to be used when evaluating URIs.
   The default namespace does not apply to elements or attributes within
   the documents themselves.  However, if a document contains a URI
   representing an XCAP resource, the default namespace defined by the
   application usage applies to that URI as well.

5.3  Data Validation

   One of the responsibilities of an XCAP server is to validate the
   content of each XCAP resource when an XCAP client tries to modify
   one.  This is done using two mechanisms.  Firstly, all application
   usages MUST describe their document contents using XML schema [2].
   The application usage MUST also identify the MIME type for documents
   compliant to that schema.

   Unfortunately, XML schemas cannot represent every form of data
   constraint.  As an example, one XML element may contain an integer
   which defines the maximum number of instances of another element.
   This constraint cannot be represented with XML schema.  However, such
   constraints may be important to the application usage.  The
   application usage defines any additional constraints beyond those in
   the schema.

   Of particular importance are uniqueness constraints.  In many cases,
   an application will require that there only be one instance of some



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


   element or attribute within a particular scope.  Each uniqueness
   constraint needs to be specified by identifying the field, or
   combinations of fields, that need to be unique, and then identifying
   the scope in which that uniqueness applies.  One typical scope is the
   set of all elements of a certain name within the same parent.
   Another typical scope is the set of all URIs valid within a
   particular domain.  In some cases these constraints can be specified
   using XML schema, which provides the <unique> element for this
   purpose.  Other uniqueness constraints, such as URI uniqueness across
   a domain, cannot be expressed by schema.  Whether or not the schema
   is used to express some of the uniqueness requirements, the
   application usage MUST specify all uniqueness requirements when it
   defines its data validation needs.

   For example, the resource lists application usage [22] requires that
   each <list> element have a unique value for the "name" attribute
   within a single parent.  As another example, the RLS services
   application usage [22] requires that the value of the "uri" attribute
   of the <service> element be a URI that is unique within the domain of
   the URI.

   URI constraints represent another form of constraints.  These are
   constraints on the scheme or structure of the scheme specific part of
   the URI.  These kinds of constraints cannot be expressed in an XML
   schema.  If these constraints are important to an application usage,
   they need to be explicitly called out.

   Another important data constraint is referential integrity.
   Referential integrity is important when the name or value of an
   element or attribute is used as a key to select another element or
   attribute.  An application usage MAY specify referential integrity
   constraints.  However, XCAP servers are not a replacement for
   Relational Database Management Systems (RDBMS), and therefore servers
   are never responsible for maintaining referential integrity.  XCAP
   clients are responsible for making all of the appropriate changes to
   documents in order to maintain referential integrity.

   Another constraint is character encoding.  XML allows documents to be
   encoded using several different character sets.  However, this
   specification mandates that all documents used with XCAP MUST be
   encoded using UTF-8.  This cannot be changed by an application usage.

   The data validation information is consumed by both clients, which
   use them to make sure they construct requests that will be accepted
   by the server, and by servers, which validate the constraints when
   they receive a request (with the exception of referential integrity
   constraints, which are not validated by the server).




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


5.4  Data Semantics

   For each application usage, the data present in the XML document has
   a well defined semantic.  The application usage defines that
   semantic, so that a client can properly construct a document in order
   to achieve the desired result.  They are not used by the server, as
   it is purposefully unaware of the semantics of the data it is
   managing.  The data semantics are expressed in English prose by the
   application usage.

   One particularly important semantic is the base URI to be used for
   the resolution of any relative URI references pointed to XCAP
   resources.  As discussed below, relative URI references pointing to
   XCAP resources cannot be resolved using the retrieval URI as the base
   URI.  Therefore, it is up to the application usage to specify the
   base URI.

5.5  Naming Conventions

   In addition to defining the meaning of the document in the context of
   a particular application, an application usage has to specify how the
   applications obtain the documents they need.  In particular, it needs
   to define any well-known URIs used for bootstrapping purposes, and
   document any other conventions on the URIs used by an application.
   It should also document how documents reference each other.  These
   conventions are called naming conventions.

   As an example, the RLS services application usage allows an RLS to
   obtain the contents of a resource list when the RLS receives a
   SUBSCRIBE request for a SIP URI identifying an RLS service.  The
   application usage specifies that the list of service definitions is
   present within a specific document with a specific name within the
   global tree.  This allows the RLS to perform a single XCAP request to
   fetch the service definition for the service associated with the SIP
   URI in a SUBSCRIBE request.

   Naming conventions are used by XCAP clients to construct their URIs.
   The XCAP server does not make use of them.

5.6  Resource Interdependencies