document from which a specific step is evaluated.  The document
   context begins at the root node of the document.  When a step
   determines an element within that context, that element becomes the
   new context for evaluation of the next step.  Each step can select an
   element by its name (expanded), by a combination of name and
   attribute value, by name and position, or by name, position and
   attribute.  In all cases, the name can be wildcarded, so that all
   elements get selected.

   The selection operation operates as follows.  Within the current
   document context, the children of that context are enumerated in
   document order.  If the context is the root node of the document, its
   child element is the root element of the document.  If the context is
   an element, its children are all of the children of that element
   (naturally).  Next, those elements whose name is not a match for
   NameorAny are discarded.  An element name is a match if NameorAny is
   the wildcard, or, if its not a wildcard, the element name matches
   NameorAny.  Matching is discussed below.  The result is an ordered
   list of elements.

   The elements in the list are further filtered by the predicates,
   which are the expressions in square brackets following NameorAny.
   Each predicate further prunes the elements from the current ordered
   list.  These predicates are evaluated in order.  If the content of
   the predicate is a position, the position-th element is selected
   (that is, treat "position" as a variable, and take the element whose
   position equals that variable), and all others are discarded.  If
   there are fewer elements in the list than the value of position, the
   result is a no-match.

   If the content of the predicate is an attribute name and value, all
   elements possessing that attribute with that value are selected, and
   all others are discarded.  Note that, although a document can have



Rosenberg                Expires April 16, 2007                [Page 20]

Internet-Draft                    XCAP                      October 2006


   namespace declarations within elements, those elements cannot be
   selected using a namespace declaration as a predicate.  That is, a
   step like "el-name[@xmlns='namespace']" will never match an element,
   even if there is an element in the list that specifies a default
   namespace of "namespace".  In other words, a namespace node is NOT an
   attribute.  If the namespaces in scope for an element are needed,
   they can be selected using the namespace-selector described below.
   If there are no elements with attributes having the given name and
   value, the result is a no-match.

   After the predicates have been applied, the result will be a no-
   match, one element, or multiple elements.  If the result is multiple
   elements, the node selector is invalid.  Each step in a node selector
   MUST produce a single element to form the context for the next step.
   This is more restrictive than general XPath expressions, which allow
   a context to contain multiple nodes.  If the result is a no-match,
   the node selector is invalid.  The node selector is only valid if a
   single element was selected.  This element becomes the context for
   the evaluation of the next step in the node selector expression.

   The last location step is either the previously described element
   selector or a "terminal selector".  If the terminal selector is an
   attribute selector, the server checks to see if there is an attribute
   with the same expanded name in the current element context.  If there
   is not, the result is considered a no-match.  Otherwise, that
   attribute is selected.  If the terminal selector is a namespace
   selector, the result is equal to the set of namespace bindings in
   scope for the element, including the possible default namespace
   declaration.  This specification defines a syntax for representing
   namespace bindings, so they can be returned to the client in an HTTP
   response.

   As a result, once the entire node selector is evaluated against the
   document, the result will either be a no-match, invalid, a single
   element, a single attribute or a set of namespace bindings.

   Matching of element names is performed as follows.  The element being
   compared in the step has its name expanded as described in XML
   namespaces [3].  The element name in the step is also expanded.  This
   expansion requires that any namespace prefix is converted to its
   namespace URI.  Doing that requires a set of bindings from prefixes
   to namespace URIs.  This set of bindings is obtained from the query
   component of the URI (see Section 6.4).  If the prefix of the QName
   of an element is empty, the corresponding URI is then the default
   document namespace URI defined by the application usage, or null if
   not defined.  Comparisons are then performed as described in XML
   namespaces [3].  Note that the namespace prefix expansions described
   here are different than those specified in the XPath 1.0



Rosenberg                Expires April 16, 2007                [Page 21]

Internet-Draft                    XCAP                      October 2006


   specification, but are closer to those currently defined by the XPath
   2.0 specification [24].

   Matching of attribute names proceeds in a similar way.  The attribute
   in the document has its name expanded as described in XML namespaces
   [3].  If the attribute name in the attribute selector has a namespace
   prefix, its name is expanded using the namespace bindings obtained
   from the query component of the URI.  An unprefixed attribute QName
   is in no namespace.

   Comments, text content (including whitespace), and processing
   instructions can be present in a document, but cannot be selected by
   the expressions defined here.  Of course, if such information is
   present in a document, and a user selects an XML element enclosing
   that data, that information would be included in a resulting GET, for
   example.  Furthermore, whitespace is respected by XCAP.  If a client
   PUTs an element or document that contains whitespace, the server
   retains that whitespace, and will return the element or document back
   to the client with exactly the same whitespace.  Similarly, when an
   element is inserted, no additional whitespace is added around the
   inserted element, and the element gets inserted in a very specific
   location relative to any whitespace, comments or processing
   instructions around it.  Section 8.2.3 describes where the insertion
   occurs.

   As an example, consider the following XML document:


   <?xml version="1.0"?>
   <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
                version="0" state="full">
     <watcher-list resource="sip:professor@example.net"
                   package="presence">
       <watcher status="active"
                id="8ajksjda7s"
                duration-subscribed="509"
                event="approved">sip:userA@example.net</watcher>
       <watcher status="pending"
                id="hh8juja87s997-ass7"
                display-name="Mr. Subscriber"
                event="subscribe">sip:userB@example.org</watcher>
     </watcher-list>
   </watcherinfo>

   Figure 3: Example XML Document

   Assuming that the default document namespace for this application
   usage is "urn:ietf:params:xml:ns:watcherinfo", the node selector



Rosenberg                Expires April 16, 2007                [Page 22]

Internet-Draft                    XCAP                      October 2006


   watcherinfo/watcher-list/watcher[@id="8ajksjda7s"] would select the
   following XML element:


   <watcher status="active"
       id="8ajksjda7s"
       duration-subscribed="509"
       event="approved">sip:userA@example.net</watcher>

6.4.  Namespace Bindings for the Selector

   In order to expand the namespace prefixes used in the node selector,
   a set of bindings from those namespace prefixes to namespace URI must
   be used.  Those bindings are contained in the query component of the
   URI.  If no query component is present, it means that only the
   default document namespace (as identified by the application usage)
   is defined.  The query component is formatted as a valid xpointer
   expression [5] after suitable URI encoding as defined in Section 4.1
   of the Xpointer framework.  This xpointer expression SHOULD only
   contain expressions from the xmlns() scheme [4].  A server compliant
   to this specification MUST ignore any xpointer expressions not from
   the xmlns() scheme.  The xmlns() xpointer expressions define the set
   of namespace bindings in use for evaluating the URI.

   Note that xpointer expressions were originally designed for usage
   within fragment identifiers of URIs.  However, within XCAP, they are
   used within query components of URIs.

   The following example shows a more complex matching operation, this
   time including the usage of namespace bindings.  Consider the
   following document:


   <?xml version="1.0"?>
   <foo xmlns="urn:test:default-namespace">
     <ns1:bar xmlns:ns1="urn:test:namespace1-uri"
              xmlns="urn:test:namespace1-uri">
       <baz/>
       <ns2:baz xmlns:ns2="urn:test:namespace2-uri"/>
     </ns1:bar>
     <ns3:hi xmlns:ns3="urn:test:namespace3-uri">
       <there/>
     </ns3:hi>
   </foo>

   Assume that this document has a document URI of
   "http://xcap.example.com/test/users/sip:joe@example.com/index", where
   "test" is the application usage.  This application usage defines a



Rosenberg                Expires April 16, 2007                [Page 23]

Internet-Draft                    XCAP                      October 2006


   default document namespace of "urn:test:default-namespace".  The XCAP
   URI:


   http://xcap.example.com/test/users/sip:joe@example.com/index/
   ~~/foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri)
   xmlns(b=urn:test:namespace1-uri)

   will select the first <baz> child element of the <bar> element in the
   document.  The XCAP URI:


   http://xcap.example.com/test/users/sip:joe@example.com/index/
   ~~/foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri)
   xmlns(b=urn:test:namespace2-uri)

   will select the second <baz> child element of the <bar> element in
   the document.  The following XCAP URI will also select the second
   element in the document:


   http://xcap.example.com/test/users/sip:joe@example.com/index/
   ~~/d:foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri)
   xmlns(b=urn:test:namespace2-uri)
   xmlns(d=urn:test:default-namespace)


7.  Client Operations

   An XCAP client is an HTTP/1.1 compliant client.  Specific data
   manipulation tasks are accomplished by invoking the right set of HTTP
   methods with the right set of headers on the server.  This section
   describes those in detail.

   In all cases where the client modifies a document, by deleting or
   inserting a document, element or attribute resource, the client
   SHOULD verify that, if the operation were to succeed, the resulting
   document would meet the data constraints defined by the application
   usage, including schema validation.  For example, if the client
   performs a PUT operation to "http://xcap.example.com/rls-services/
   users/sip:joe@example.com/mybuddies", rls-services is the application
   unique ID, and the constraints defined by it SHOULD be followed.

   The client will know what URI to use based on the naming conventions
   described by the application usage.

   If the document, after modification, does not meet the data
   constraints, the server will reject it with a 409.  The 409 response



Rosenberg                Expires April 16, 2007                [Page 24]

Internet-Draft                    XCAP                      October 2006


   may contain an XML body, formatted according to the schema in
   Section 11.2, which provides further informati