9.  Cache Control

   An XCAP resource is a valid HTTP resource, and therefore, it can be
   cached by clients and network caches.  Network caches, however, will
   not be aware of the interdependencies between XCAP resources.  As
   such, a change to an element in a document by a client will
   invalidate other XCAP resources affected by the change.  For
   application usages containing data that is likely to be dynamic or
   written by clients, servers SHOULD indicate a no-cache directive.

10.  Namespace Binding Format

   A node-selector can identify a set of namespace bindings that are in
   scope for a particular element.  In order to convey these bindings in
   a GET response, a way is needed to encode them.

   Encoding is trivially done by including a single XML element in an
   XML fragment body.  This element has the same local-name as the
   element whose namespace bindings are desired, and also the same
   namespace-prefix.  The element has an xmlns attribute identifying the
   default namespace in scope, and an xmlns:prefix declaration for each
   prefix that is in scope.

   For example, consider the XML document in Section 6.4.  The node-
   selector df:foo/df2:bar/df2:baz/namespace::* will select the
   namespaces in scope for the <baz> element in the document, assuming
   the request is accompanied by a query component that contains
   xmlns(df=urn:test:default-namespace) and
   xmlns(df2=urn:test:namespace1-uri).  A GET containing this node
   selector and namespace bindings will produce the following result:

   <baz xmlns="urn:test:namespace1-uri"
        xmlns:ns1="urn:tes:namespace1-uri"/>

   It is important to note that the client does not need to know the
   actual namespace bindings in order to construct the URI.  It does
   need to know the namespace URI for each element in the node-selector.
   The namespace bindings present in the query component are defined by
   the client, mapping those URIs to a set of prefixes.  The bindings
   returned by the server are the actual bindings used in the document.

11.  Detailed Conflict Reports

   In cases where the server returns a 409 error response, that response
   will usually include a document in the body of the response which
   provides further details on the nature of the error.  This document
   is an XML document, formatted according to the schema of

   Section 11.2.  Its MIME type, registered by this specification, is
   "application/xcap-error+xml".

11.1.  Document Structure

   The document structure is simple.  It contains the root element
   <xcap-error>.  The content of this element is a specific error
   condition.  Each error condition is represented by a different
   element.  This allows for different error conditions to provide
   different data about the nature of the error.  All error elements
   support a "phrase" attribute, which can contain text meant for
   rendering to a human user.

   The following error elements are defined by this specification:

   <not-well-formed>:  This indicates that the body of the request was
      not a well-formed XML document.

   <not-xml-frag>:  This indicates that the request was supposed to
      contain a valid XML fragment body, but did not.  Most likely this
      is because the XML in the body was malformed or not balanced.

   <no-parent>:  This indicates that an attempt to insert a document,
      element, or attribute failed because the directory, document, or
      element into which the insertion was supposed to occur does not
      exist.  This error element can contain an optional <ancestor>
      element, which provides an HTTP URI that represents the closest
      parent that would be a valid point of insertion.  This HTTP URI
      MAY be a relative URI, relative to the document itself.  Because
      this is a valid HTTP URI, its node selector component MUST be
      percent-encoded.

   <schema-validation-error>:  This element indicates that the document
      was not compliant to the schema after the requested operation was
      performed.

   <not-xml-att-value>:  This indicates that the request was supposed to
      contain a valid XML attribute value, but did not.

   <cannot-insert>:  This indicates that the requested PUT operation
      could not be performed because a GET of that resource after the
      PUT would not yield the content of the PUT request.

   <cannot-delete>:  This indicates that the requested DELETE operation
      could not be performed because it would not be idempotent.

   <uniqueness-failure>:  This indicates that the requested operation
      would result in a document that did not meet a uniqueness
      constraint defined by the application usage.  For each URI,
      element, or attribute specified by the client that is not unique,
      an <exists> element is present as the content of the error
      element.  Each <exists> element has a "field" attribute that
      contains a relative URI identifying the XML element or attribute
      whose value needs to be unique, but wasn't.  The relative URI is
      relative to the document itself, and will therefore start with the
      root element.  The query component of the URI MUST be present if
      the node selector portion of the URI contains namespace prefixes.
      Since the "field" node selector is a valid HTTP URI, it MUST be
      percent-encoded.  The <exists> element can optionally contain a
      list of <alt-value> elements.  Each one is a suggested alternate
      value that does not currently exist on the server.

   <constraint-failure>:  This indicates that the requested operation
      would result in a document that failed a data constraint defined
      by the application usage, but not enforced by the schema or a
      uniqueness constraint.

   <extension>:  This indicates an error condition that is defined by an
      extension to XCAP.  Clients that do not understand the content of
      the extension element MUST discard the xcap-error document and
      treat the error as an unqualified 409.

   <not-utf-8>:  This indicates that the request could not be completed
      because it would have produced a document not encoded in UTF-8.

   As an example, the following document indicates that the user
   attempted to create an RLS service using the URI
   sip:friends@example.com, but that URI already exists:

   <?xml version="1.0" encoding="UTF-8"?>
   <xcap-error xmlns="urn:ietf:params:xml:ns:xcap-error">
    <uniqueness-failure>
     <exists field="rls-services/service/@uri">
       <alt-value>sip:mybuddies@example.com</alt-value>
     </exists>
    </uniqueness-failure>
   </xcap-error>

11.2.  XML Schema

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:xcap-error"
    xmlns="urn:ietf:params:xml:ns:xcap-error"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified">

    <xs:element name="error-element" abstract="true"/>
    <xs:element name="xcap-error">
     <xs:annotation>
      <xs:documentation>Indicates the reason for the error.
     </xs:documentation>
     </xs:annotation>
     <xs:complexType>
      <xs:sequence>
       <xs:element ref="error-element"/>
      </xs:sequence>
     </xs:complexType>
    </xs:element>

    <xs:element name="extension" substitutionGroup="error-element">
     <xs:complexType>
      <xs:sequence>
       <xs:any namespace="##any" processContents="lax"
               minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
     </xs:complexType>
    </xs:element>

    <xs:element name="schema-validation-error"
     substitutionGroup="error-element">
     <xs:annotation>
      <xs:documentation>This element indicates
   that the document was not compliant to the schema after the requested
   operation was performed.</xs:documentation>
     </xs:annotation>
     <xs:complexType>
      <xs:attribute name="phrase" type="xs:string" use="optional"/>
     </xs:complexType>
    </xs:element>

    <xs:element name="not-xml-frag" substitutionGroup="error-element">
     <xs:annotation>
      <xs:documentation>This indicates that the request was supposed to
   contain a valid XML fragment body, but did not.</xs:documentation>
     </xs:annotation>

     <xs:complexType>
      <xs:attribute name="phrase" type="xs:string" use="optional"/>
     </xs:complexType>
    </xs:element>

    <xs:element name="no-parent" substitutionGroup="error-element">
     <xs:annotation>
      <xs:documentation>This indicates that an attempt to insert
   an element, attribute, or document failed because the document or
   element into which the insertion was
   supposed to occur does not exist.</xs:documentation>
     </xs:annotation>
     <xs:complexType>
      <xs:sequence>
       <xs:element name="ancestor" type="xs:anyURI" minOccurs="0">
        <xs:annotation>
         <xs:documentation>Contains an HTTP URI that points to the
   element that is the closest ancestor that does exist.
         </xs:documentation>
        </xs:annotation>
       </xs:element>
      </xs:sequence>
      <xs:attribute name="phrase" type="xs:string" use="optional"/>
     </xs:complexType>
    </xs:element>

    <xs:element name="cannot-insert" substitutionGroup="error-element">
     <xs:annotation>
      <xs:documentation>This indicates that the requested
   PUT operation could not be performed because a GET of that resource
   after the PUT would not yield the content of the PUT request.
      </xs:documentation>
     </xs:annotation>
     <xs:complexType>
      <xs:attribute name="phrase" type="xs:string" use="optional"/>
     </xs:complexType>
    </xs:element>

    <xs:element name="not-xml-att-value"
     substitutionGroup="error-element">
     <xs:annotation>
      <xs:documentation>This indicates that the
   request was supposed to contain a valid XML attribute value, but did
   not.</xs:documentation>
     </xs:annotation>
     <xs:complexType>
      <xs:attribute name="phrase" type="xs:string" use="optional"/>
     </xs:complexType>

    </xs:element>

    <xs:element name="uniqueness-failure"
     substitutionGroup="error-element">
     <xs:annotation>
      <xs:documentation>This indicates that the
   requested operation would result in a document that did not meet a
   uniqueness constraint defined by the application usage.
      </xs:documentation>
     </xs:annotation>
     <xs:complexType>
      <xs:sequence>
       <xs:element name="exists" maxOccurs="unbounded">
        <xs:annotation>
         <xs:documentation>For each URI,
   element, or attribute specified by the client that is not unique,
   one of these is present.</xs:documentation>
        </xs:annotation>
        <xs:complexType>
         <xs:sequence minOccurs="0">
          <xs:element name="alt-value" type="xs:string"
           maxOccurs="unbounded">
           <xs:annotation>
            <xs:documentation>An optional set of alternate values can be
   provided.</xs:documentation>
           </xs:annotation>
          </xs:element>
         </xs:sequence>
         <xs:attribute name="field" type="xs:string" use="required"/>
        </xs:complexType>
       </xs:element>
      </xs:sequence>
      <xs:attribute name="phrase" type="xs:string" use="optional"/>
     </xs:complexType>
    </xs:element>

    <xs:element name="not-well-formed"
     substitutionGroup="error-element">
     <xs:annotation>
      <xs:documentation>This indicates that the body of the request was
   not a well-formed document.</xs:documentation>
     </xs:annotation>
     <xs:complexType>
      <xs:attribute name="phrase" type="xs:string" use="optional"/>
     </xs:complexType>
    </xs:element>

    <xs:element name="constraint-failure"
     substitutionGroup="error-element">
     <xs:annotation>
      <xs:documentation>This indicates that the
   requested operation would result in a document that failed a data
   constraint defined by the application usage, but not enforced by the
   schema or a uniqueness constraint.</xs:documentation>
     </xs:annotation>
     <xs:complexType>
      <xs:attribute name="phrase" type="xs:string" use="optional"/>
     </xs:complexType>
    </xs:element>

    <xs:element name="cannot-delete" substitutionGroup="error-element">
     <xs:annotation>
      <xs:documentation>This indicates that the requested DELETE
   operation could not be performed because it would not be
   idempotent.</xs:documentation>
     </xs:annotation>
     <xs:complexType>
      <xs:attribute name="phrase" type="xs:string" use="optional"/>
     </xs:complexType>
    </xs:element>

    <xs:element name="not-utf-8" substitutionGroup="error-element">
     <xs:annotation>
      <xs:documentation>This indicates that the request could not be
         completed because it would have produced a document not
         encoded in UTF-8.</xs:documentation>
     </xs:annotation>
     <xs:complexType>
      <xs:attribute name="phrase" type="xs:string" use="optional"/>
     </xs:complexType>
    </xs:element>
   </xs:schema>


12.  XCAP Server Capabilities

   XCAP can be extended through the addition of new application usages
   and extensions to the core protocol.  Application usages may define
   MIME types with XML schemas that allow new extension nodes from new
   namespaces.  It will often be necessary for a client to determine
   what extensions, application usages, or namespaces a server supports
   before making a request.  To enable that, this specification defines
   an application usage with the AUID "xcap-caps".  All XCAP servers
   MUST support this application usage.  This usage defines a single

   document within the global tree that lists the capabilities of the
   server.  Clients can read this well-known document, and therefore
   learn the capabilities of the server.

   The structure of the document is simple.  The root element is <xcap-
   caps>.  Its children are <auids>, <extensions>, and <namespaces>.
   Each of these contain a list of AUIDs, extensions, and namespaces
   supported by the server.  Extensions are named by tokens defined by
   the extension, and typically define new selectors.  Namespaces are
   identified by their namespace URI.  To 'support' a namespace, the
   server must have the schemas for all elements within that namespace,
   and be able to validate them if they appear within documents.  Since
   all XCAP servers support the "xcap-caps" AUID, it MUST be listed in
   the <auids> element, and the "urn:ietf:params:xml:ns:xcap-caps"
   namespace MUST be listed in the <namespaces> element.

   The following sections provide the information needed to define this
   application usage.

12.1.  Application Unique ID (AUID)

   This specification defines the "xcap-caps" AUID within the IETF tree,
   via the IANA registration in Section 15.

12.2.  XML Schema

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:xcap-caps"
    xmlns="urn:ietf:params:xml:ns:xcap-caps"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:element name="xcap-caps">
     <xs:annotation>
      <xs:documentation>Root element for xcap-caps</xs:documentation>
     </xs:annotation>
     <xs:complexType>
      <xs:sequence>
       <xs:element name="auids">
        <xs:annotation>
         <xs:documentation>List of supported AUID.</xs:documentation>
        </xs:annotation>
        <xs:complexType>
         <xs:sequence minOccurs="0" maxOccurs="unbounded">
          <xs:element name="auid" type="auidType"/>
         </xs:sequence>
        </xs:complexType>
       </xs:element>
       <xs:element name="extensions" minOccurs="0">

        <xs:annotation>
         <xs:documentation>List of supported extensions.
         </xs:documentation>
        </xs:annotation>
        <xs:complexType>
         <xs:sequence minOccurs="0" maxOccurs="unbounded">
          <xs:element name="extension" type="extensionType"/>
         </xs:sequence>
        </xs:complexType>
       </xs:element>
       <xs:element name="namespaces">
        <xs:annotation>
         <xs:documentation>List of supported namespaces.
         </xs:documentation>
        </xs:annotation>
        <xs:complexType>
         <xs:sequence minOccurs="0" maxOccurs="unbounded">
          <xs:element name="namespace" type="namespaceType"/>
         </xs:sequence>
        </xs:complexType>
       </xs:element>
       <xs:any namespace="##other" processContents="lax"
        minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
     </xs:complexType>
    </xs:element>
    <xs:simpleType name="auidType">
     <xs:annotation>
      <xs:documentation>AUID Type</xs:documentation>
     </xs:annotation>
     <xs:restriction base="xs:string"/>
    </xs:simpleType>
    <xs:simpleType name="extensionType">
     <xs:annotation>
      <xs:documentation>Extension Type</xs:documentation>
     </xs:annotation>
     <xs:restriction base="xs:string"/>
    </xs:simpleType>
    <xs:simpleType name="namespaceType">
     <xs:annotation>
      <xs:documentation>Namespace type</xs:documentation>
     </xs:annotation>
     <xs:restriction base="xs:anyURI"/>
    </xs:simpleType>
   </xs:schema>

12.3.  Default Document Namespace

   The default document namespace used in evaluating a URI is
   urn:ietf:params:xml:ns:xcap-caps.

12.4.  MIME Type

   Documents conformant to this schema are known by the MIME type
   "application/xcap-caps+xml", registered in Section 15.2.5.

12.5.  Validation Constraints

   There are no additional validation constraints associated with this
   application usage.

12.6.  Data Semantics

   Data semantics are defined above.

12.7.  Naming Conventions

   A server MUST maintain a single instance of the document in the
   global tree, using the filename "index".  There MUST NOT be an
   instance of this document in the user's tree.

12.8.  Resource Interdependencies

   There are no resource interdependencies in this application usage
   beyond those defined by the schema.

12.9.  Authorization Policies

   This application usage does not change the default authorization
   policy defined by XCAP.

13.  Examples

   This section goes through several examples, making use of the
   resource-lists and rls-services [22] XCAP application usages.

   First, a user Bill creates a new document (see Section 7.1).  This
   document is a new resource-list, initially with a single list, called
   friends, with no users in it:

   PUT
   /resource-lists/users/sip:bill@example.com/index HTTP/1.1
   Content-Type:application/resource-lists+xml
   Host: xcap.example.com

   <?xml version="1.0" encoding="UTF-8"?>
   <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
     <list name="friends">
     </list>
   </resource-lists>

                          Figure 24: New Document

   Next, Bill creates an RLS services document defining a single RLS
   service referencing this list.  This service has a URI of
   sip:myfriends@example.com (URIs are line-folded for readability):

   PUT
   /rls-services/users/sip:bill@example.com/index HTTP/1.1
   Content-Type:application/rls-services+xml
   Host: xcap.example.com

   <?xml version="1.0" encoding="UTF-8"?>
   <rls-services xmlns="urn:ietf:params:xml:ns:rls-services">
   <service uri="sip:myfriends@example.com">
     <resource-list>http://xcap.example.com/resource-lists/users/
   sip:bill@example.com/index/~~/resource-lists/
   list%5b@name=%22friends%22%5d
   </resource-list>
     <packages>
      <package>presence</package>
     </packages>
    </service>
   </rls-services>

                      Figure 25: RLS Services Example

   Next, Bill creates an element in the resource-lists document
   (Section 7.4).  In particular, he adds an entry to the list:

   PUT
   /resource-lists/users/sip:bill@example.com/index
   /~~/resource-lists/list%5b@name=%22friends%22%5d/entry HTTP/1.1
   Content-Type:application/xcap-el+xml
   Host: xcap.example.com

   <entry uri="sip:bob@example.com">
       <display-name>Bob Jones</display-name>
     </entry>

                    Figure 26: Resource Lists Document

   Next, Bill fetches the document (Section 7.3):

   GET
   /resource-lists/users/sip:bill@example.com/index HTTP/1.1

                        Figure 27: Fetch Operation

   And the result is (note how white space text nodes appear in the
   document):

   HTTP/1.1 200 OK
   Etag: "wwhha"
   Content-Type: application/resource-lists+xml

   <?xml version="1.0" encoding="UTF-8"?>
   <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
     <list name="friends">
     <entry uri="sip:bob@example.com">
       <display-name>Bob Jones</display-name>
     </entry></list>
   </resource-lists>

                        Figure 28: Results of Fetch

   Next, Bill adds another entry to the list, which is another list that
   has three entries.  This is another element creation (Section 7.4):

   PUT
   /resource-lists/users/sip:bill@example.com/index/~~/
   resource-lists/list%5b@name=%22friends%22%5d/
   list%5b@name=%22close-friends%22%5d HTTP/1.1
   Content-Type: application/xcap-el+xml
   Host: xcap.example.com

   <list name="close-friends">
      <entry uri="sip:joe@example.com">
        <display-name>Joe Smith</display-name>
      </entry>
      <entry uri="sip:nancy@example.com">
        <display-name>Nancy Gross</display-name>
      </entry>
      <entry uri="sip:petri@example.com">
        <display-name>Petri Aukia</display-name>
      </entry>
   </list>

                        Figure 29: Adding an Entry

   Then, Bill decides he doesn't want Petri on the list, so he deletes
   the entry (Section 7.5):

   DELETE
   /resource-lists/users/sip:bill@example.com/index/
   ~~/resource-lists/list/list/
   entry%5b@uri=%22sip:petri@example.com%22%5d HTTP/1.1
   Host: xcap.example.com

                       Figure 30: Deleting an Entry

   Bill decides to check on the URI for Nancy, so he fetches a
   particular attribute (Section 7.6):

   GET
   /resource-lists/users/sip:bill@example.com/index/
   ~~/resource-lists/list/list/entry%5b2%5d/@uri HTTP/1.1
   Host: xcap.example.com

                     Figure 31: Fetching an Attribute

   and the server responds:

   HTTP/1.1 200 OK
   Etag: "ad88"
   Content-Type:application/xcap-att+xml

   "sip:nancy@example.com"

                        Figure 32: Results of Fetch

14.  Security Considerations

   Frequently, the data manipulated by XCAP contains sensitive
   information.  To avoid eavesdroppers from seeing this information, it
   is RECOMMENDED that an administrator hand out an HTTPS URI as the
   XCAP root URI.  This will result in TLS-encrypted communications
   between the client and server, preventing any eavesdropping.  Clients
   MUST implement TLS, assuring that such URIs will be usable by the
   client.

   Client and server authentication are also important.  A client needs
   to be sure it is talking to the server it believes it is contacting.
   Otherwise, it may be given false information, which can lead to
   denial-of-service attacks against a client.  To prevent this, a
   client SHOULD attempt to upgrade [15] any connections to TLS.
   Similarly, authorization of read and write operations against the
   data is important, and this requires client authentication.  As a

   result, a server SHOULD challenge a client using HTTP Digest [11] to
   establish its identity, and this SHOULD be done over a TLS
   connection.  Clients MUST implement digest authentication, assuring
   interoperability with servers that challenge the client.  Servers
   MUST NOT perform basic authentication without a TLS connection to the
   client.

   Because XCAP is a usage of HTTP and not a separate protocol, it runs
   on the same port numbers as HTTP traffic normally does.  This makes
   it difficult to apply port-based filtering rules in firewalls to
   separate the treatment of XCAP traffic from other HTTP traffic.

   However, this problem exists broadly today because HTTP is used to
   access a wide breadth of content, all on the same port, and XCAP
   views application configuration documents as just another type of
   HTTP content.  As such, separate treatment of XCAP traffic from other
   HTTP traffic requires firewalls to examine the URL itself.  There is
   no foolproof way to identify a URL as pointing to an XCAP resource.
   However, the presence of the double tilde (~~) is a strong hint that
   the URL points to an XML element or attribute.  As always, care must
   be taken in looking for the double-tilde due to the breadth of ways
   in which a URI can be encoded on-the-wire [29] [13].

15.  IANA Considerations

   There are several IANA considerations associated with this
   specification.

15.1.  XCAP Application Unique IDs

   Per this specification's instructions, IANA created a new registry
   for XCAP application unique IDs (AUIDs).  This registry is defined as
   a table that contains three columns:

   AUID:  This will be a string provided in the IANA registrations into
      the registry.

   Description:  This is text that is supplied by the IANA registration
      into the registry.

   Reference:  This is a reference to the RFC containing the
      registration.

   Per this specification's instructions, IANA created this table with
   an initial entry.  The resulting table looks like:

   Application Unique
       ID (AUID)          Description                      Reference
   --------------------   -------------------------------  ---------
   xcap-caps              Capabilities of an XCAP server   RFC 4825

   XCAP AUIDs are registered by the IANA when they are published in
   standards track RFCs.  The IANA Considerations section of the RFC
   must include the following information, which appears in the IANA
   registry along with the RFC number of the publication.

   o  Name of the AUID.  The name MAY be of any length, but SHOULD be no
      more than 20 characters long.  The name MUST consist of alphanum
      and mark [16] characters only.

   o  Descriptive text that describes the application usage.

15.2.  MIME Types

   This specification requests the registration of several new MIME
   types according to the procedures of RFC 4288 [8] and guidelines in
   RFC 3023 [9].

15.2.1.  application/xcap-el+xml MIME Type

   MIME media type name:  application

   MIME subtype name:  xcap-el+xml

   Mandatory parameters:  none

   Optional parameters:  Same as charset parameter application/xml as
      specified in RFC 3023 [9].

   Encoding considerations:  Same as encoding considerations of
      application/xml as specified in RFC 3023 [9].

   Security considerations:  See Section 10 of RFC 3023 [9].

   Interoperability considerations:  none

   Published specification:  RFC 4825

   Applications that use this media type:  This document type has been
      used to support transport of XML fragment bodies in RFC 4825, the
      XML Configuration Access Protocol (XCAP).

   Additional Information:

         Magic Number: none

         File Extension: .xel

         Macintosh file type code: "TEXT"

   Personal and email address for further information:
      Jonathan Rosenberg, jdrosen@jdrosen.net

   Intended usage:  COMMON

   Author/Change controller:  The IETF.

15.2.2.  application/xcap-att+xml MIME Type

   MIME media type name:  application

   MIME subtype name:  xcap-att+xml

   Mandatory parameters:  none

   Optional parameters:  Same as charset parameter application/xml as
      specified in RFC 3023 [9].

   Encoding considerations:  Same as encoding considerations of
      application/xml as specified in RFC 3023 [9].

   Security considerations:  See Section 10 of RFC 3023 [9].

   Interoperability considerations:  none

   Published specification:  RFC 4825

   Applications that use this media type:  This document type has been
      used to support transport of XML attribute values in RFC 4825, the
      XML Configuration Access Protocol (XCAP).

   Additional Information:

         Magic Number: none

         File Extension: .xav

         Macintosh file type code: "TEXT"

   Personal and email address for further information:
      Jonathan Rosenberg, jdrosen@jdrosen.net

   Intended usage:  COMMON

   Author/Change controller:  The IETF.

15.2.3.  application/xcap-ns+xml MIME Type

   MIME media type name:  application

   MIME subtype name:  xcap-ns+xml

   Mandatory parameters:  none

   Optional parameters:  Same as charset parameter application/xml as
      specified in RFC 3023 [9].

   Encoding considerations:  Same as encoding considerations of
      application/xml as specified in RFC 3023 [9].

   Security considerations:  See Section 10 of RFC 3023 [9].

   Interoperability considerations:  none

   Published specification:  RFC 4825

   Applications that use this media type:  This document type has been
      used to support transport of XML fragment bodies in RFC 4825, the
      XML Configuration Access Protocol (XCAP).

   Additional Information:

      Magic Number:  none

      File Extension:  .xns

      Macintosh file type code:  "TEXT"

   Personal and email address for further information:
      Jonathan Rosenberg, jdrosen@jdrosen.net

   Intended usage:  COMMON

   Author/Change controller:  The IETF.

15.2.4.  application/xcap-error+xml MIME Type

   MIME media type name:  application

   MIME subtype name:  xcap-error+xml

   Mandatory parameters:  none

   Optional parameters:  Same as charset parameter application/xml as
      specified in RFC 3023 [9].

   Encoding considerations:  Same as encoding considerations of
      application/xml as specified in RFC 3023 [9].

   Security considerations:  See Section 10 of RFC 3023 [9].

   Interoperability considerations:  none

   Published specification:  RFC 4825

   Applications that use this media type:  This document type conveys
      error conditions defined in RFC 4825

   Additional Information:

      Magic Number:  none

      File Extension:  .xer

      Macintosh file type code:  "TEXT"

   Personal and email address for further information:
      Jonathan Rosenberg, jdrosen@jdrosen.net

   Intended usage:  COMMON

   Author/Change controller:  The IETF.

15.2.5.  application/xcap-caps+xml MIME Type

   MIME media type name:  application

   MIME subtype name:  xcap-caps+xml

   Mandatory parameters:  none

   Optional parameters:  Same as charset parameter application/xml as
      specified in RFC 3023 [9].

   Encoding considerations:  Same as encoding considerations of
      application/xml as specified in RFC 3023 [9].

   Security considerations:  See Section 10 of RFC 3023 [9].

   Interoperability considerations:  none

   Published specification:  RFC 4825

   Applications that use this media type:  This document type conveys
      capabilities of an XML Configuration Access Protocol (XCAP)
      server, as defined in RFC 4825.

   Additional Information:

      Magic Number:  none

      File Extension:  .xca

      Macintosh file type code:  "TEXT"

   Personal and email address for further information:
      Jonathan Rosenberg, jdrosen@jdrosen.net

   Intended usage:  COMMON

   Author/Change controller:  The IETF.

15.3.  URN Sub-Namespace Registrations

   This specification registers several new XML namespaces, as per the
   guidelines in RFC 3688 [17].

15.3.1.  urn:ietf:params:xml:ns:xcap-error

   URI:  The URI for this namespace is urn:ietf:params:xml:ns:xcap-error

   Registrant Contact:  IETF, SIMPLE working group, (simple@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).

XML:
           BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
              "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml">
           <head>
             <meta http-equiv="content-type"
                content="text/html;charset=iso-8859-1"/>
             <title>XCAP Error Namespace</title>
           </head>
           <body>
             <h1>Namespace for XCAP Error Documents</h1>
             <h2>urn:ietf:params:xml:ns:xcap-error</h2>
             <p>See <a href="http://www.rfc-editor.org/rfc/rfc4825.txt">
                RFC4825</a></p>
           </body>
           </html>
           END

15.3.2.  urn:ietf:params:xml:ns:xcap-caps

   URI:  The URI for this namespace is urn:ietf:params:xml:ns:xcap-caps

   Registrant Contact:  IETF, SIMPLE working group, (simple@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).

XML:
           BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
              "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml">
           <head>
             <meta http-equiv="content-type"
                content="text/html;charset=iso-8859-1"/>
             <title>XCAP Capabilities Namespace</title>
           </head>
           <body>
             <h1>Namespace for XCAP Capability Documents</h1>
             <h2>urn:ietf:params:xml:ns:xcap-caps</h2>
             <p>See <a href="http://www.rfc-editor.org/rfc/rfc4825.txt">
                RFC4825</a></p>
           </body>
           </html>
           END

15.4.  XML Schema Registrations

   This section registers two XML schemas per the procedures in [17].

15.4.1.  XCAP Error Schema Registration

   URI:  urn:ietf:params:xml:schema:xcap-error

   Registrant Contact:  IETF, SIMPLE working group, (simple@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).

   XML Schema:  The XML for this schema can be found as the sole content
      of Section 11.2.

15.4.2.  XCAP Capabilities Schema Registration

   URI:  urn:ietf:params:xml:schema:xcap-caps

   Registrant Contact:  IETF, SIMPLE working group, (simple@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).

   XML Schema:  The XML for this schema can be found as the sole content
      of Section 12.2.

16.  Acknowledgements

   The author would like to thank Jari Urpalainen, who has contributed
   many important comments and has assisted with edit passes in the
   document.  The author would also like to thank Ben Campbell,
   Eva-Maria Leppanen, Hisham Khartabil, Chris Newman, Joel Halpern,
   Lisa Dusseault, Tim Bray, Pete Cordell, Jeroen van Bemmel, Christian
   Schmidt, and Spencer Dawkins for their input and comments.  A special
   thanks to Ted Hardie for his input and support.

17.  References

17.1.  Normative References

   [1]   Maler, E., Yergeau, F., Paoli, J., Bray, T., and C. Sperberg-
         McQueen, "Extensible Markup Language (XML) 1.0 (Third
         Edition)", World Wide Web Consortium FirstEdition REC-xml-
         20040204, February 2004,
         <http://www.w3.org/TR/2004/REC-xml-20040204>.

   [2]   Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, "XML
         Schema Part 1: Structures Second Edition", World Wide Web
         Consortium Recommendation REC-xmlschema-1-20041028,
         October 2004,
         <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.

   [3]   Layman, A., Hollander, D., and T. Bray, "Namespaces in XML",
         World Wide Web Consortium FirstEdition REC-xml-names-19990114,
         January 1999,
         <http://www.w3.org/TR/1999/REC-xml-names-19990114>.

   [4]   Daniel, R., DeRose, S., Maler, E., and J. Marsh, "XPointer
         xmlns() Scheme", World Wide Web Consortium Recommendation REC-
         xptr-xmlns-20030325, March 2003,
         <http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325>.

   [5]   Grosso, P., Marsh, J., Maler, E., and N. Walsh, "XPointer
         Framework", World Wide Web Consortium Recommendation REC-xptr-
         framework-20030325, March 2003,
         <http://www.w3.org/TR/2003/REC-xptr-framework-20030325>.

   [6]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [8]   Freed, N. and J. Klensin, "Media Type Specifications and
         Registration Procedures", BCP 13, RFC 4288, December 2005.

   [9]   Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
         RFC 3023, January 2001.

   [10]  Clark, J. and S. DeRose, "XML Path Language (XPath) Version
         1.0", World Wide Web Consortium Recommendation REC-xpath-
         19991116, November 1999,
         <http://www.w3.org/TR/1999/REC-xpath-19991116>.

   [11]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
         Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
         Basic and Digest Access Authentication", RFC 2617, June 1999.

   [12]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 4234, October 2005.

   [13]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
         January 2005.

   [14]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [15]  Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1",
         RFC 2817, May 2000.

   [16]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [17]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
         January 2004.

   [18]  Yergeau, F., "UTF-8, a transformation format of ISO 10646",
         STD 63, RFC 3629, November 2003.

   [19]  Boyer, J., "Canonical XML Version 1.0", World Wide Web
         Consortium Recommendation REC-xml-c14n-20010315, March 2001,
         <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.

17.2.  Informative References

   [20]  Rosenberg, J., "A Presence Event Package for the Session
         Initiation Protocol (SIP)", RFC 3856, August 2004.

   [21]  Roach, A., Campbell, B., and J. Rosenberg, "A Session
         Initiation Protocol (SIP) Event Notification Extension for
         Resource Lists", RFC 4662, August 2006.

   [22]  Rosenberg, J., "Extensible Markup Language (XML) Formats for
         Representing Resource Lists", RFC 4826, May 2007.

   [23]  Grosso, P. and D. Veillard, "XML Fragment Interchange", World
         Wide Web Consortium CR CR-xml-fragment-20010212, February 2001,
         <http://www.w3.org/TR/2001/CR-xml-fragment-20010212>.

   [24]  Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., Kay, M.,
         Robie, J., and J. Simeon, "XML Path Language (XPath) 2.0",
         World Wide Web Consortium
         CR http://www.w3.org/TR/2005/CR-xpath20-20051103,
         November 2005.

   [25]  Newman, C. and J. Myers, "ACAP -- Application Configuration
         Access Protocol", RFC 2244, November 1997.

   [26]  Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
         and Instant Messaging", RFC 2778, February 2000.

   [27]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434,
         October 1998.

   [28]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [29]  Duerst, M. and M. Suignard, "Internationalized Resource
         Identifiers (IRIs)", RFC 3987, January 2005.

Author's Address

   Jonathan Rosenberg
   Cisco
   Edison, NJ
   US

   EMail: jdrosen@cisco.com
   URI:   http://www.jdrosen.net

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.