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.

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





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


   Node Selector 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,
      node selector separator, and node selector, resulting in the
      selection of a specific XML node.

   XCAP Root URI:  An HTTP URI that represents 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.

   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



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


   namespace contains a set of tokens, each of which is registered with
   IANA.  These registrations occur with the publication of standards
   track RFCs [27], based on the guidelines in Section 15.  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 [12] (and using some
   of the BNF defined in RFC 3986 [13]), is:

   AUID             =  global-a-uid / vendor-a-uid
   global-a-uid     =  a-uid
   a-uid            =  1*a-uid-char
   vendor-a-uid     =  rev-hostname "." a-uid
   rev-hostname     =  toplabel *( "." domainlabel  )
   domainlabel      =  alphanum
                       / alphanum *( alphanum / "-" ) alphanum
   toplabel         =  ALPHA / ALPHA *( alphanum / "-" ) alphanum
   a-uid-char       =  a-uid-unreserved / pct-encoded / sub-delims
                       / ":" / "@"
                                  ;pct-encoded from RFC 3986
                                  ;sub-delims from RFC 3986
   alphanum         = ALPHA / DIGIT
                                  ;DIGIT from RFC 4234
                                  ;ALPHA from RFC 4234
   a-uid-unreserved = ALPHA / DIGIT / "-" / "_" / "~"

   The allowed characters for the auid production is a subset of the
   pchar production defined in RFC 3986.  In particular, it omits the
   ".", which allows for the auid to be separated from the reverse
   hostname.

5.2.  Default Document Namespace

   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
   in the URI without namespace prefixes.  The namespace binding context
   comes from two sources.  First, the mapping of namespace prefixes to
   namespace URIs is obtained from the URI itself (see Section 6.4).
   However, the default document namespace is defined by the application
   usage itself, and applies to all URIs referencing resources within



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


   that application usage.  All application usages MUST define a
   namespace URI that represents the default document namespace to be
   used when evaluating URIs.  The default document namespace does not
   apply to elements or attributes within the documents themselves -- it
   applies only to the evaluation of URIs within that application usage.
   Indeed, the term 'default document namespace' is distinct from the
   term 'default namespace'.  The latter has the standard meaning within
   XML documents, and the former refers to the default used in
   evaluation of XCAP URIs.  XCAP does not change in any way the
   mechanisms for determining the default namespace within XML
   documents.  However, if a document contains a URI representing an
   XCAP resource, the default document 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
   that 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 be only one instance of some
   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.





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


   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 clients
   MUST NOT depend on servers to maintain referential integrity.  XCAP
   clients are responsible for making all 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).

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 that is 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



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


   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.

   For many application usages, users need only a single document.  In
   such a case, it is RECOMMENDED that the application usage require
   that this document be called "index" and exist within the user's home
   directory.

   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