SIMPLE WG                                                  J. Urpalainen
Internet-Draft                                                     Nokia
Intended status: Standards Track                            July 5,                       November 16, 2007
Expires: January 6, May 19, 2008

   The Extensible Markup Language (XML) Configuration Access Protocol
   (XCAP) co-operation with HTTP Extensions for Distributed Authoring
                                (WEBDAV)
                 draft-urpalainen-simple-xcap-webdav-03
                 draft-urpalainen-simple-xcap-webdav-04

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 6, May 19, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The Extensible Markup Language (XML) Configuration Access Protocol
   (XCAP) allows a client to read, write and modify application
   configuration data, stored in XML format on an HTTP server.  HTTP
   Extensions for Distributed Authoring (WebDAV) provides many useful
   HTTP extensions for web content authoring.  This document describes
   conventions for the co-operation of XCAP resources with WebDAV.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  WebDAV Extensions to XCAP  . . . . . . . . . . . . . . . . . .  3
     4.1.  Collections  . . . . . . . . . . . . . . . . . . . . . . .  4
     4.2.  Locking  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.3.  Conditional requests with the If-header  . . . . . . . . .  4  5
     4.4.  Access Control Lists . . . . . . . . . . . . . . . . . . .  5
       4.4.1.  Server provisioned ACL after a successful PUT  . . . .  6
       4.4.2.  Server provisioned ACL after a successful MKCOL  . . . 10
       4.4.3.  Privileges . . . . . . . . . . . . . . . . . . . . . . 10
       4.4.4.  Aggregation of privileges  . . . . . . . . . . . . . . 10
     4.5.  Properties . . . . . . . . . . . . . . . . . . . . . . . . 11
       4.5.1.  XCAP root directory property . . . . . . . . . . . . . 11
   5.  Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 11
   6.  XCAP Server Capabilities extension . . . . . . . . . . . . . . 12
   7.  RELAX NG Schemas . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Precondition error element . . . . . . . . . . . . . . . . 12
     7.2.  XCAP root directory property . . . . . . . . . . . . . . . 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  URN sub-namespace XML namespace registration for
           'urn:ietf:params:xml:ns:xcap'  . . . . . . . . . . . . . . 13
     8.2.  RELAX NG Schema for XCAP Precondition Error  . . . . . . . 14
     8.3.  RELAX NG Schema for XCAP Home Property . . . . . . . . . . 14
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16 17

1.  Introduction

   The Extensible Markup Language (XML) [2] [W3C.REC-xml-20060816]
   Configuration Access Protocol (XCAP) [3] [RFC4825] was designed to store
   XML documents on an HTTP server.  Also patching of XML document
   components, i.e.  XML elements and attributes can be achieved with
   basic HTTP PUT and DELETE methods.  Thus XML documents contain
   usually many XCAP resources and access to them is achieved by using a
   node selector in the path segment of the request URI.  The document
   tree structure is also described by the core XCAP protocol.

   HTTP Extensions for Distributed Authoring (WebDAV) [4] [RFC4918] provides
   many useful HTTP [6] [RFC2616] extensions for web content authoring
   including many other MIME types than just XML documents.  The
   extension set includes properties, collections, locks and namespace
   operations of WebDAV resources.  With WebDAV access control protocol [7]
   [RFC3744] access to shared resources can easily be allowed or denied.

   This document describes conventions for XCAP servers utilizing these
   WebDAV authoring extensions.  The aim is to use existing
   specifications with compatibility in mind, an existing XCAP client
   can still use resources of the server which complies with the rules
   described in this document.

2.  Terminology

   In this document, the

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119, BCP 14
   [1]
   [RFC2119] and indicate requirement levels for compliant
   implementations.

3.  Definitions

   This document uses terms defined in WebDAV [4], [RFC4918], XCAP [3] [RFC4825]
   and WebDAV access control protocol (ACL) [7]. [RFC3744].

4.  WebDAV Extensions to XCAP

   In XCAP, the request URI contains a node selector when an XML
   document component is being updated.  This selector value can be used
   to locate for example, an XML element to be removed from the XML
   document.  WebDAV in general does not utilize this sort of
   granularity of an XML document.  This document does not thus propose
   such a model mostly because of simplicity and compatibility reasons
   and instead, all WebDAV features, for example properties and locks
   operate only on an XML document level, that is, it is not allowed to
   set some property of an XML element or lock an XML element along with
   its descendants.  In other words, if the request URI contains an XCAP
   node selector with e.g. a PROPPATCH or any other WebDAV method, an
   error may MAY be produced.  Especially "locked empty resources" with LOCK
   method might otherwise be created unless this rule is obeyed.

      Note: Actual implementations can then easily utilize existing
      libraries as they can dispatch request handlers to appropriate
      ones: WebDAV or XCAP according to request URIs and HTTP methods:
      typically, if the request URI contains a node selector and a node
      selector separator with GET, PUT or DELETE method, XCAP handlers
      are used and otherwise requests are passed to WebDAV handlers.
      These handlers are then free to respond with appropriate formats
      as there are minimal inter-dependencies.  In other words, XCAP
      features do not overlap with WebDAV ones.

4.1.  Collections

   A collection is a container which references child resources.  The
   core XCAP protocol does not support the creation of collections.
   WebDAV [4] [RFC4918] MKCOL method can then be used to create a
   collection.  A collection can be removed with the DELETE method.
   This WebDAV property is advertised with the OPTIONS query response by
   "Class 1" compliance.

      Note: The current XCAP application usages do not specify
      collection usages in their user "home directories" and some of
      them only support only single entities (files).  In application
      usages where it makes sense to support collections it is up to the
      server to decide whether it is allowed or not.

4.2.  Locking

   Locks complement the conditional (ETag) request usages of XCAP
   resources as they can temporarily disallow other users from making
   any changes to users resources.  Write locking is an optional feature
   of a WebDAV server.  It is advertised with the OPTIONS query response
   by "Class 2" compliance.  Like properties these are supported only at
   the XML document level.  If locks are supported on the server, before
   the server applies an XCAP component update, addition or removal, the
   server has to look for possible locks on the corresponding XML
   document or ancestor collections.

4.3.  Conditional requests with the If-header

   The If request header defined by [4] [RFC4918] is intended to have
   similar functionality to the If-Match header defined in Section 14.24
   of [6]. [RFC2616].  However, the If-header handles any state token as well
   as ETags.  This If-header can thus also be used with conditional XCAP
   requests especially when using lock tokens.  If resources are
   referenced within the If-header, they MUST not NOT contain an XCAP node
   selector.

4.4.  Access Control Lists

   In terms of WebDAV access control lists, the core XCAP specifies that
   the owner of a resource has typically <DAV:read> and <DAV:write>
   access rights.  With WebDAV ACLs [7] [RFC3744] a more fine-grained
   privileges can be given to users, especially when sharing resources.
   The privileges (<DAV:read>, <DAV:write> and so on) are used by access
   control elements (ACE).  Several ACEs are combined into an access
   control list (ACL).  The owners of documents are principals which are
   manifested to clients as an HTTP resource, identified by a URI.  A
   server that implements both WebDAV and XCAP MUST support the same
   principal namespace for both WebDAV ACL usage and XCAP user
   identities (XUI).  That is, every valid WebDAV principal MUST also be
   a XUI, and vice versa.

   XCAP recommends an XCAP root URI is like "http://xcap.example.com"
   for a domain "example.com".  This document RECOMMENDS that the last
   path segments of a principal URI is of the form "joe/self" for a user
   "joe" (XUI), in other words, an XUI represents a collection.  It is
   anticipated that users can create private groups onto these
   collections, for example then the user "joe" has then <DAV:bind> privilege
   e.g. to the collection "http://xcap.example.com/principals/joe/".
   The principal can then create group resources, i.e. group principal
   resources or other collections into this collection.  It should be
   noted that a collection is not regarded as a principal.  The "DAV:group-member-
   set" "DAV:
   group-member-set" property contains then the principal URIs belonging
   to the group.  These group resources may then be referenced by ACEs.
   Also group principal URIs may be referenced by the "DAV:group-member-set" "DAV:group-member-
   set" property allowing thus nested groups.  For new created groups of
   a
   principal principal, the server MUST provision <DAV:all> privileges to the
   owner (principal) shown later in this document.  If the server does
   not intend to support user defined groups the user will not be
   provisioned <DAV:bind> privilege to his/her principal collection so
   clients trying to create a private principal group URI will be
   responded with 403 "Forbidden" return code.

   It is RECOMMENDED that while provisioning users for XCAP application
   usages, users are given <DAV:all> privileges to their application
   usage "home directories".  This allows users full control to them:
   creation of sub-directories, setting access control rights and so on.

4.4.1.  Server provisioned ACL after a successful PUT

   After a successful PUT (201) request a new XCAP resource has been
   created to the server.  The server may then create an appropriate
   initial ACL for the document as the WebDAV ACL [7] [RFC3744]
   specification does not mandate any specific server behavior.  In
   order to ease implementations and to guarantee compatibility with
   XCAP clients that don't support ACLs, the server MUST thus provision
   an ACL for the newly created resource which allows <DAV:read> and
   <DAV:write> access for the owner of the a resource.  Similarly the servers
   MUST set the authenticated user the owner of the a document, which means
   mapping of the user ID (XUI) to a principal URI.  An example ACL
   document after the creation of a new XCAP resource:

   <?xml version="1.0" encoding="UTF-8" ?>
   <acl xmlns="DAV:">
     <ace>
       <principal>
         <href>http://xcap.example.com/principals/joe/self</href>
       </principal>
       <grant>
         <privilege><all/></privilege>
       </grant>
     </ace>
   </acl>

   The client can always request the created ACL with PROPFIND method
   from the server and update it to his/her likings but ACL unaware
   clients can still continue updating this new resource.  An ACL for a
   WebDAV resource can be set with the ACL method which always publishes
   the full access control list.  The request URI refers to a HTTP
   resource and it MUST not NOT contain an XCAP node selector.

   PROPFIND /resource-lists/users/joe/
   Host: xcap.example.com
   Depth: 1
   Content-Type: application/xml
   Content-Length: xxx

   <?xml version="1.0" encoding="UTF-8" ?>
   <propfind xmlns="DAV:">
     <prop>
       <owner/>
       <acl/>
       <getetag/>
     </prop>
   </propfind>

   Response:

   HTTP/1.1 207 Multi-Status
   Content-Type: application/xml
   Content-Length: xxxx

   <?xml version="1.0" encoding="UTF-8" ?>
   <multistatus xmlns="DAV:">
    <response>
     <href>http://xcap.example.com/resource-lists/users/joe/</href>
     <propstat>
      <prop>
       <owner>
        <href>http://xcap.example.com/principals/joe/self</href>
       </owner>
       <acl>
        <ace>
         <principal>
          <property><owner/></property>
         </principal>
         <grant>
          <privilege><all/></privilege>
         </grant>
        </ace>
       </acl>
       <getetag>"cf223434-cc347899"</getetag>
      </prop>
      <status>HTTP/1.1 200 OK</status>
     </propstat>
    </response>
    <response>
     <href>http://xcap.example.com/resource-lists/users/joe/index</href>
     <propstat>
      <prop>
       <owner>
        <href>http://xcap.example.com/principals/joe/self</href>
       </owner>
       <acl>
        <ace>
         <principal>
          <href>http://xcap.example.com/principals/joe/self</href>
         </principal>
         <grant>
          <privilege><all/></privilege>

         </grant>
        </ace>
       </acl>
       <getetag>"de33443434-af343455"</getetag>
      </prop>
      <status>HTTP/1.1 200 OK</status>
     </propstat>
    </response>
   </multistatus>

   An example about giving read access to "friends":

   ACL /resource-lists/users/joe/index
   Host: xcap.example.com
   Depth: 0
   Content-Type: application/xml
   Content-Length: xxx

   <?xml version="1.0" encoding="UTF-8" ?>
   <acl xmlns="DAV:">
     <ace>
       <principal>
         <href>http://xcap.example.com/principals/joe/self</href>
       </principal>
       <grant>
         <privilege><all/></privilege>
       </grant>
     </ace>
     <ace>
       <principal>
         <href>http://xcap.example.com/principals/joe/friends</href>
       </principal>
       <grant>
         <privilege><read/></privilege>
       </grant>
     </ace>
   </acl>

   Response:

   HTTP/1.1 200 OK

   And the referenced "friends" group can be queried:

   PROPFIND /principals/joe/
   Host: xcap.example.com
   Depth: 1
   Content-Type: application/xml
   Content-Length: xxx

   <?xml version="1.0" encoding="UTF-8" ?>
   <propfind xmlns="DAV:">
     <prop>
       <group-membership/>
       <displayname/>
     </prop>
   </propfind>

   Response:

   HTTP/1.1 207 Multi-Status
   Content-Type: application/xml
   Content-Length: xxxx

   <?xml version="1.0" encoding="UTF-8" ?>
   <multistatus xmlns="DAV:">
    <response>
     <href>http://xcap.example.com/principals/joe/</href>
     <propstat>
      <prop>
       <group-membership/>
       <displayname/>
      </prop>
      <status>HTTP/1.1 403 Forbidden</status>
     </propstat>
    </response>
    <response>
     <href>http://xcap.example.com/principals/joe/self</href>
     <propstat>
      <prop>
       <displayname>Joe Smith</displayname>
      </prop>
      <status>HTTP/1.1 200 OK</status>
     </propstat>
     <propstat>
      <prop>
       <group-membership/>
      </prop>
      <status>HTTP/1.1 404 Not Found</status>
     </propstat>
    </response>
    <response>
     <href>http://xcap.example.com/principals/joe/friends</href>
     <propstat>
      <prop>
       <displayname>Friends of Joe Smith</displayname>
       <group-membership>
        <href>http://xcap.example.com/principals/lisa/self</href>
        <href>http://xcap.example.com/principals/jack/self</href>
        <href>http://xcap.example.com/principals/tom/friends</href>
       </group-membership>
      </prop>
      <status>HTTP/1.1 200 OK</status>
     </propstat>
    </response>
   </multistatus>

4.4.2.  Server provisioned ACL after a successful MKCOL

   After a successful MKCOL (201) request a new collection has been
   created to the server.  Similar to a successful PUT, the server
   provisions <DAV:all> privilege to the owner of this new collection
   and sets the authenticated user the owner of a resource.

4.4.3.  Privileges

   The Appendix B of WebDAV ACL [7] [RFC3744] specification lists normative
   privileges for different methods.  This specification extends this
   table for DELETE method so that <DAV:unbind> privilege on a target
   resource allows also the unbinding of the resource from the parent
   collection.

      Note: In practice this means  Note that if a user has a <DAV:all> or a
      <DAV:write> <DAV:
   write> privilege on a resource, the user is able to perform resource does not allow a successful DELETE operation.
   operation on a resource, instead the <DAV:unbind> privilege on a
   parent collection is required.

4.4.4.  Aggregation of privileges

   The chapter 3.12 of WebDAV ACL [7] [RFC3744] specification defines some
   allowed and disallowed aggregation rules for <DAV:read> and <DAV:write> <DAV:
   write> and other privileges.  Given these constraints and while it is
   also possible to query the implemented aggregation model of a server
   with <DAV:supported-privilege-set> it is RECOMMENDED that <DAV:read>
   contains only <DAV:read-current-user-privilege-set>, i.e. it does not
   contain <read-acl> privilege and similarly, <DAV:write> does not
   contain <write-acl> privilege. <DAV:write> will then contain <DAV:
   bind>, <DAV:unbind>, <DAV:write-properties> and <DAV:write-content>
   privileges.

4.5.  Properties

   This document does not introduce any constraints to WebDAV [4] [RFC4918]
   properties except that it is only allowed to set/get properties on
   the document level.  XCAP doesn't describe any way to request or set
   a property of a resource although it uses ETags for conditional
   updates.  For instance these ETag values can easily be queried with
   PROPFIND method and the result may contain all resources from a
   collection.  This can for example, be used to maintain a simple sync
   synchronisation of remote XCAP documents.

      The PROPPATCH method sets properties of resources based on
      qualified names (QName) [8] [W3C.REC-xml-names-20060816] and "values"
      of them.  The value of a property is usually a text node content
      but it may also be of mixed type [9].

      Note: [W3C.REC-xmlschema-2-20041028].

      For example, after a successful PUT of an XML element, an XCAP
      server has to create a new ETag for the document.  This ETag is a
      WebDAV "live" property which MUST be accessible to a WebDAV
      handler when the ETag value of a resource is being requested.
      There is thus an inter-dependency between XCAP and WebDAV
      handling.

4.5.1.  XCAP root directory property

   Principal properties SHOULD be extended with a new WebDAV property:
   <xcap-root-directories>.  This property will list the XCAP root URIs
   of a user.  The property MAY be protected by servers and SHOULD NOT
   be returned by PROPFIND DAV:allprop request.  The element format is
   defined by the RELAX NG Schema [5] [relaxng] given in Section 7.2.

      Note: With the aid of this property and the XCAP Server Capability
      Application Usage clients can then discover all XCAP resources of
      a user. user given that she has appropriate access rights.  An
      alternative is also to utilize <DAV:principal-match> REPORT query
      to list all resources of a user once the XCAP root directory is
      known.

5.  Error Handling

   XCAP defines an XML error response format for 409 (Conflict)
   responses.  The usage of WebDAV introduces some new error responses,
   most notably for example 423 (Locked) response.  However, this does
   not typically impose any problem as requests are typically
   orthogonal, i.e. error responses either follow XCAP or WebDAV
   conventions depending on the request type.  Some of the XCAP 409
   (Conflict) responses can easily be handled automatically without user
   intervention.

   If WebDAV methods (other than GET, PUT or DELETE) are used with
   request URIs which contain an otherwise valid XCAP node selector the
   server MAY respond with 403 (Forbidden).  The corresponding
   precondition error element is defined formally by the RELAX NG Schema
   [5]
   [relaxng] given in Section 7.1.

6.  XCAP Server Capabilities extension

   XCAP Server Capabilities application usage defines responses to XCAP
   clients about the XCAP server capabilities.  The format includes the
   possibility to describe extensions of the server.  If Class 1, 2 or 3
   WebDAV compatibility is supported, the text node content of the
   <extension> element MUST contain "DAV1", "DAV2" or "DAV3".  If the
   server supports several of them, each property MUST be reported with
   separate <extension> elements.  If WebDAV ACL is supported the
   <extension> element contains "DAV ACL".

7.  RELAX NG Schemas

7.1.  Precondition error element

   RELAX NG schema in compact format for a precondition error response.

   default namespace = "urn:ietf:params:xml:ns:xcap-error"

   # error return
   webdav-request-to-node-selector =
     element webdav-request-to-node-selector { anything* }
   # wildcard for any content
   anything =
     element * {
       mixed {
         (attribute * { text }
          | anything)*
       }
     }

7.2.  XCAP root directory property

   RELAX NG schema in compact format for the "XCAP-root-directory"
   property.

   default namespace = "DAV:"
   namespace ns1 = "urn:ietf:params:xml:ns:xcap"

   # xcap home directory
   xcap-root-directories =
     element ns1:xcap-root-directories {
       element href { xsd:anyURI }*
     }

8.  IANA Considerations

8.1.  URN sub-namespace XML namespace registration for 'urn:ietf:params:xml:ns:xcap'

      URI: urn:ietf:params:xml:ns:xcap

      Description: This is the XML namespace for XCAP root directory
      property.

      Registrant Contact: IETF, SIMPLE working group, <simple@ietf.org>
      Jari Urpalainen, <jari.urpalainen@nokia.com>

   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 xmlns="http://www.w3.org/1999/xhtml"
         <head>
              <meta http-equiv="content-type"
              content="text/html;charset=iso-8859-1"/>
              <title>XCAP root directory</title>
         </head>
         <body>
             <h1>Namespace for XCAP root directory property</h1>
             <h2>urn:ietf:params:xml:ns:xcap</h2>
             <p>See <a href="[[[URL of published RFC]]]">
             RFCXXXX</a>.</p>
          </body>
          </html>
     END

8.2.  RELAX NG Schema for XCAP Precondition Error

   This section registers a new XML schema per the procedures in
   [RFC3688].

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

      Registrant Contact: IETF, SIMPLE working group, <simple@ietf.org>
      Jari Urpalainen, <jari.urpalainen@nokia.com>

      The content for this schema can be found in Section 7.1.

8.3.  RELAX NG Schema for XCAP Home Property

   This section registers a new XML schema per the procedures in
   [RFC3688].

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

      Registrant Contact: IETF, SIMPLE working group, <simple@ietf.org>
      Jari Urpalainen, <jari.urpalainen@nokia.com>

      The content for this schema can be found in Section 7.2.

9.  Security Considerations

   Security considerations described in XCAP [3], [RFC4825], WebDAV [4] [RFC4918]
   and WebDAV ACL [7] [RFC3744] are naturally applicable to this
   specification.  Especially using "distributed" authorization rules
   may be problematic, for example how to build trust over different
   domains.  Also with distributed groups loops might be generated.
   However, implementations may disallow "distributed" authorization
   rules altogether by responding with appropriate precondition errors.

10.  Acknowledgments

   The author would like to thank Lisa Dusseault, Eva Leppanen and
   Julian Reschke for their valuable comments.

11.  Normative References

   [1]

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

   [2]

   [W3C.REC-xml-20060816]
              Maler, E., Paoli, J., Bray, T., Yergeau, F., and C.
              Sperberg-McQueen, "Extensible Markup Language (XML) 1.0
              (Fourth Edition)", W3C World Wide Web Consortium
              Recommendation REC-xml-20060816 , REC-xml-20060816, August 2006.

   [3] 2006,
              <http://www.w3.org/TR/2006/REC-xml-20060816>.

   [RFC4825]  Rosenberg, J., "The Extensible Markup Language (XML)
              Configuration Access Protocol (XCAP)", RFC 4825, May 2007.

   [4]

   [RFC4918]  Dusseault, L., Ed., "HTTP Extensions for Web Distributed
              Authoring and Versioning (WebDAV)", RFC 4918, June 2007.

   [5]

   [relaxng]  "RELAX NG Specification", Committee Specification 3 ,
              December 2001.

   [6]

   [RFC2616]  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]

   [RFC3744]  Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
              Distributed Authoring and Versioning (WebDAV)
              Access Control Protocol", RFC 3744, May 2004.

   [8]

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

   [W3C.REC-xml-names-20060816]
              Hollander, D., Bray, T., Layman, A., and R. Tobin,
              "Namespaces in XML 1.0 (Second Edition)", W3C World Wide Web
              Consortium Recommendation REC-
        xml-names-20060816 , REC-xml-names-20060816,
              August 2006.

   [9] 2006,
              <http://www.w3.org/TR/2006/REC-xml-names-20060816>.

   [W3C.REC-xmlschema-2-20041028]
              Malhotra, A. and P. Biron, "XML Schema Part 1: Structures 2: Datatypes
              Second Edition", W3C World Wide Web Consortium
              Recommendation REC-xmlschema-1-20041028 , REC-xmlschema-2-20041028, October 2004. 2004,
              <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

Author's Address

   Jari Urpalainen
   Nokia
   Itamerenkatu 11-13
   Helsinki  00180
   Finland

   Phone: +358 7180 37686
   Email: jari.urpalainen@nokia.com

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.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).