Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4825

The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)

Pages: 71
Proposed Standard
Part 3 of 3 – Pages 47 to 71
First   Prev   None

Top   ToC   RFC4825 - Page 47   prevText

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
Top   ToC   RFC4825 - Page 48
   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.
Top   ToC   RFC4825 - Page 49
   <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>
Top   ToC   RFC4825 - Page 50

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>
Top   ToC   RFC4825 - Page 51
     <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>
Top   ToC   RFC4825 - Page 52
    </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>
Top   ToC   RFC4825 - Page 53
    <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
Top   ToC   RFC4825 - Page 54
   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">
Top   ToC   RFC4825 - Page 55
        <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>
Top   ToC   RFC4825 - Page 56

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
Top   ToC   RFC4825 - Page 57
   <?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
Top   ToC   RFC4825 - Page 58
   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
Top   ToC   RFC4825 - Page 59
   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
Top   ToC   RFC4825 - Page 60
   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.
Top   ToC   RFC4825 - Page 61
   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
Top   ToC   RFC4825 - Page 62
   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
Top   ToC   RFC4825 - Page 63
         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.
Top   ToC   RFC4825 - Page 64

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].
Top   ToC   RFC4825 - Page 65
   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).
Top   ToC   RFC4825 - Page 66
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
Top   ToC   RFC4825 - Page 67

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>.
Top   ToC   RFC4825 - Page 68
   [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.
Top   ToC   RFC4825 - Page 69
   [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.
Top   ToC   RFC4825 - Page 70
   [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
Top   ToC   RFC4825 - Page 71
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.