Internet DRAFT - draft-urpalainen-simple-xcap-webdav
draft-urpalainen-simple-xcap-webdav
SIMPLE WG J. Urpalainen
Internet-Draft Nokia
Intended status: Standards Track November 16, 2007
Expires: 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-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 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.
Urpalainen Expires May 19, 2008 [Page 1]
Internet-Draft XCAP with WebDAV November 2007
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 . . . . . . . . . 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 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 . . . . . . . . . . 17
Urpalainen Expires May 19, 2008 [Page 2]
Internet-Draft XCAP with WebDAV November 2007
1. Introduction
The Extensible Markup Language (XML) [W3C.REC-xml-20060816]
Configuration Access Protocol (XCAP) [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) [RFC4918] provides
many useful HTTP [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
[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
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
[RFC2119] and indicate requirement levels for compliant
implementations.
3. Definitions
This document uses terms defined in WebDAV [RFC4918], XCAP [RFC4825]
and WebDAV access control protocol (ACL) [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
Urpalainen Expires May 19, 2008 [Page 3]
Internet-Draft XCAP with WebDAV November 2007
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 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 [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.
Urpalainen Expires May 19, 2008 [Page 4]
Internet-Draft XCAP with WebDAV November 2007
4.3. Conditional requests with the If-header
The If request header defined by [RFC4918] is intended to have
similar functionality to the If-Match header defined in Section 14.24
of [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 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 [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 <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" 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" property allowing thus nested groups. For new created groups of
a 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
Urpalainen Expires May 19, 2008 [Page 5]
Internet-Draft XCAP with WebDAV November 2007
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 [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 a resource. Similarly servers
MUST set the authenticated user the owner of 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 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/>
Urpalainen Expires May 19, 2008 [Page 6]
Internet-Draft XCAP with WebDAV November 2007
<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>
Urpalainen Expires May 19, 2008 [Page 7]
Internet-Draft XCAP with WebDAV November 2007
</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:
Urpalainen Expires May 19, 2008 [Page 8]
Internet-Draft XCAP with WebDAV November 2007
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>
Urpalainen Expires May 19, 2008 [Page 9]
Internet-Draft XCAP with WebDAV November 2007
<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 [RFC3744] specification lists normative
privileges for different methods. Note that a <DAV:all> or a <DAV:
write> privilege on a resource does not allow a successful DELETE
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 [RFC3744] specification defines some
allowed and disallowed aggregation rules for <DAV:read> and <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.
Urpalainen Expires May 19, 2008 [Page 10]
Internet-Draft XCAP with WebDAV November 2007
4.5. Properties
This document does not introduce any constraints to WebDAV [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
synchronisation of remote XCAP documents.
The PROPPATCH method sets properties of resources based on
qualified names (QName) [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 [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 [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 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
Urpalainen Expires May 19, 2008 [Page 11]
Internet-Draft XCAP with WebDAV November 2007
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
[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.
Urpalainen Expires May 19, 2008 [Page 12]
Internet-Draft XCAP with WebDAV November 2007
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 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"
<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
Urpalainen Expires May 19, 2008 [Page 13]
Internet-Draft XCAP with WebDAV November 2007
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 [RFC4825], WebDAV [RFC4918]
and WebDAV ACL [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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[W3C.REC-xml-20060816]
Urpalainen Expires May 19, 2008 [Page 14]
Internet-Draft XCAP with WebDAV November 2007
Maler, E., Paoli, J., Bray, T., Yergeau, F., and C.
Sperberg-McQueen, "Extensible Markup Language (XML) 1.0
(Fourth Edition)", World Wide Web Consortium
Recommendation REC-xml-20060816, August 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.
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[relaxng] "RELAX NG Specification", Committee Specification 3 ,
December 2001.
[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.
[RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
Distributed Authoring and Versioning (WebDAV)
Access Control Protocol", RFC 3744, May 2004.
[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)", World Wide Web
Consortium Recommendation REC-xml-names-20060816,
August 2006,
<http://www.w3.org/TR/2006/REC-xml-names-20060816>.
[W3C.REC-xmlschema-2-20041028]
Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
Urpalainen Expires May 19, 2008 [Page 15]
Internet-Draft XCAP with WebDAV November 2007
Author's Address
Jari Urpalainen
Nokia
Itamerenkatu 11-13
Helsinki 00180
Finland
Phone: +358 7180 37686
Email: jari.urpalainen@nokia.com
Urpalainen Expires May 19, 2008 [Page 16]
Internet-Draft XCAP with WebDAV November 2007
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).
Urpalainen Expires May 19, 2008 [Page 17]
