draft-ietf-webdav-collection-protocol-00.txt   draft-ietf-webdav-collection-protocol-01.txt 
WEBDAV Working Group J. Slein
INTERNET DRAFT Xerox Corporation WEBDAV Working Group J. Slein, Xerox
<draft-ietf-webdav-collection-protocol-00> June 5, 1998 INTERNET DRAFT J. Davis, Xerox
Expires December 5, 1998 <draft-ietf-webdav-collection-protocol-01> A. Babich, FileNet
E.J. Whitehead Jr., UC Irvine
July 31, 1998
Expires January 31, 1999
WebDAV Advanced Collections Protocol WebDAV Advanced Collections Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
skipping to change at line 39 skipping to change at line 42
to the Distributed Authoring and Versioning (WebDAV) working group to the Distributed Authoring and Versioning (WebDAV) working group
at <w3c-dist-auth@w3.org>, which may be joined by sending a at <w3c-dist-auth@w3.org>, which may be joined by sending a
message with subject "subscribe" to <w3c-dist-auth- message with subject "subscribe" to <w3c-dist-auth-
request@w3.org>. request@w3.org>.
Discussions of the WEBDAV working group are archived at URL: Discussions of the WEBDAV working group are archived at URL:
<http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth>. <http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth>.
Abstract Abstract
The base WebDAV protocol [Goland et al., 1998] provides basic The base WebDAV protocol [WebDAV] provides basic support for
support for collections. It defines a MKCOL method for creating collections. It defines a MKCOL method for creating collections
collections and specifies how other HTTP and WebDAV methods and specifies how other HTTP and WebDAV methods interact with
interact with collections. It supports only internal members of collections. It supports internal members of collections, which it
collections, which it defines as members whose URIs are defines as members whose URIs are immediately relative to the URI
immediately relative to the URI of the collection. of the collection.
Many applications, however, need more powerful collections. There Many applications, however, need more powerful collections. There
are two areas in particular where more powerful functionality is are two areas in particular where more powerful functionality is
often needed: referential members and ordering. often needed: referential resources and ordering.
This draft specifies extensions to the base WebDAV protocol to This draft specifies extensions to the base WebDAV protocol to
support these more powerful collections. support these more powerful collections.
Table of Contents
1 Terminology 3
2 Introduction 4
3 Referential Resources 4
3.1 Scope 4
3.2 Overview 6
3.3 Creating Referential Resources 6
3.3.1 The MKREF Method 6
3.3.2 Status Codes 7
3.3.3 Example 8
3.4 Deleting Referential Resources 8
3.4.1 The DELREF Method 8
3.4.2 Status Codes 8
3.4.3 Example 8
3.4.4 Design Rationale 8
3.5 Listing Referential Members of a Collection 9
3.6 Other WebDAV Operations on Indirect References 9
3.7 HTTP Operations on Indirect References 10
3.8 Operations on Targets of References 11
4 Ordered Collections 11
4.1 Overview 11
4.2 Creating an Ordered Collection 11
4.2.1 Overview 11
4.2.2 Status Codes 12
4.2.3 Example 12
4.3 Setting the Position of a Collection Member 12
4.3.1 Overview 12
4.3.2 Status Codes 13
4.3.3 Examples 13
4.4 Changing the Semantics of a Collection Ordering 14
4.5 Changing the Position of a Collection Member 14
4.5.1 The ORDERPATCH Method 14
4.5.2 Status Codes 14
4.5.3 Example 14
4.5.4 Design Rationale 15
5 New Headers 16
5.1 Ref-Target Request Header 16
5.2 Ref-Integrity Request Header 16
5.3 Pass-Through Request Header 17
5.4 Resource-Type Response Header 17
5.5 Ordered Request Header 17
5.6 Position Request Header 18
6 New Properties 18
6.1 reftarget Property 18
6.2 refintegrity Property 18
6.3 passthrough Property 19
6.4 orderingtype Property 19
7 New XML Elements 20
7.1 reference XML Element 20
7.2 weak XML Element 20
7.3 arbitrary XML Element 20
7.4 order XML Element 20
7.5 member XML Element 20
7.6 position XML Element 21
7.7 first XML Element 21
7.8 last XML Element 21
7.9 before XML Element 21
7.10 after XML Element 22
8 Compliance 22
8.1 Class 3 22
8.2 Class 4 22
9 Dependencies on Other Specifications 22
10 Security Considerations 22
10.1 Redirect Loops 23
10.2 References and Denial of Service 23
10.3 Malicious Modifications of Ordering 23
10.4 Denial of Service and DAV:orderingtype 23
11 Internationalization Considerations 23
12 IANA Considerations 24
13 Copyright 24
14 Intellectual Property 24
15 Acknowledgements 24
16 References 24
17 Authors' Addresses 25
1 Terminology 1 Terminology
The terminology used here differs from that in the base WebDAV The terminology used here follows and extends that in the base
protocol specification [Goland et al., 1998], particularly in its WebDAV protocol specification [WebDAV].
definition of internal member resource.
Collection Collection
A resource that contains member resources A resource that contains member resources
Member Resource Member Resource
A resource contained by a collection A resource contained by a collection
Referential Member Resource Referential Resource (or Reference)
A member resource that has no content of its own, but rather is A resource that has no content of its own, but rather is
a reference to another resource a reference to another resource
Ordinary Resource
A member resource that is not a reference to another resource
Target Resource
The resource referenced by a referential member of a collection
Direct Reference
A reference that has the property that operations on it are
passed through to its target
Indirect Reference
A reference that has the property that operations on it do
not affect its target
Strong Reference Strong Reference
A reference whose referential integrity is guaranteed by the A reference whose referential integrity is guaranteed by the
server server
Weak Reference Weak Reference
A reference whose referential integrity is not guaranteed by the A reference whose referential integrity is not guaranteed by the
server server
Referential Integrity
Internal Member Resource A server guarantees the integrity of a reference if it ensures
A member resource that either has content of its own or is that the reference will not be broken, or enables the
empty, but is not a reference to another resource reference's owner to ensure that the reference will not be
broken.
Target Resource
The resource referenced by a referential member of a collection
2 Introduction 2 Introduction
The simple collections that the base WebDAV specification supports The simple collections that the base WebDAV specification supports
are powerful enough to be widely useful. They provide for the are powerful enough to be widely useful. They provide for the
hierarchical organization of resources, with mechanisms for hierarchical organization of resources, with mechanisms for
creating and deleting collections, copying and moving them, creating and deleting collections, copying and moving them,
locking them, adding resources to them and deleting resources from locking them, adding resources to them and deleting resources from
them, and getting listings of their members. Delete, copy, move, them, and getting listings of their members. Delete, copy, move,
list, and lock operations can be applied recursively, so that a list, and lock operations can be applied recursively, so that a
client can operate on whole hierarchies with a single request. client can operate on whole hierarchies with a single request.
Many applications, however, need more powerful collections. There Many applications, however, need more powerful collections. There
are two areas in particular where more powerful functionality is are two areas in particular where more powerful functionality is
often needed: referential members and ordering. often needed: referential resources and ordering.
Referential members make it possible for many collections, on the Referential resources make it possible for many collections, on the
same or different servers, to share the same resource. Because same or different servers, to share the same resource. Because
the collections share the resource by referencing it, only one the collections share the resource by referencing it, only one
physical copy of the resource need exist, and any changes made in physical copy of the resource need exist, and any changes made in
the resource are visible from all the collections that reference the resource are visible from all the collections that reference
it. it.
It is useful for many applications to be able to impose an It is useful for many applications to be able to impose an
ordering on a collection. Orderings may be based on property ordering on a collection. Orderings may be based on property
values, but they may be completely independent of any properties values, but they may be completely independent of any properties
on the collection's member resources. Orderings based on on the collection's member resources. Orderings based on
properties can be obtained using a search protocol [DASL], but properties can be obtained using a search protocol [DASL], but
orderings not based on properties need some other mechanism. orderings not based on properties need some other mechanism.
Since these two areas are independent of each other, servers may Since these two areas are independent of each other, servers may
elect to comply with the Referential Members section of this elect to comply with the Referential Resources section of this
specification or with the Ordered Collections section or both. specification or with the Ordered Collections section or both.
A server MUST advertise its compliance through its response to A server MUST advertise its compliance through its response to
an OPTIONS request, as specified in [Goland et al., 1998]. New an OPTIONS request, as specified in [WebDAV]. New values for the
values for the DAV header are defined in Section 8 below to DAV header are defined in Section 8 below to support this
support this requirement. requirement.
3 Referential Members 3 Referential Resources
3.1 Overview 3.1 Scope
A referential member of a collection is a resource that has no [WebDAVReq] distinguishes between "weak" references and "strong"
content of its own, but instead references another resource. The references, and also between "indirect" references and "direct"
resource it references may be in the same collection or anywhere references. This specification supports only weak references and
else. This target resource may be a collection or a simple indirect references, but is designed so that it can be extended
resource or another referential member of a collection, or any to support strong references and direct references in the future.
other sort of resource that may be defined in the future. A
resource may be referenced by any number of referential members of
collections. (Req 3.1.1 - 3.1.3, 3.1.6, 3.1.15)
Since a referential member of a collection is a resource, it can Strong references are references whose integrity is guaranteed by
have properties just like any other resource. These properties are the server; weak references are those whose integrity is not
completely independent of the properties on its target resource guaranteed. Strong references and weak references are both useful
(Req 3.1.9). A new DAV:reftarget property has as its value the in different contexts. Some applications cannot tolerate broken
URI of the target resource (3.1.6). links. A software development application, for example, must be
able to rely on the integrity of references to component modules.
Such applications must be able to request strong references. Other
applications may want to reference target resources on multiple
servers, where referential integrity cannot be guaranteed, and may
be less concerned about possible broken references.
3.2 Creating Referential Members of a Collection (Req 3.1.7) Several considerations led to the decision not to support strong
references in the current specification. First, there are many
possible policies that applications and services might use to
enforce referential integrity.
(Add justification for using the extension mechanisms specified in o Delete strong references when their targets are deleted.
[Nielsen et al., 1998] "Mandatory Extensions in HTTP".)
Clients MUST use the M-PUT method to create a referential member o Decline to delete targets of strong references.
of a collection. (Clients MUST NOT use a plain PUT to create a
referential member of a collection. A PUT request with a o Notify strong references when their targets have been
request-URI of an existing collection will fail.) The deleted.
request-URI of the M-PUT request identifies the collection to which
the new member is to be added. The server recognizes a request to o Let owners of resources decide whether strong references to
create a referential member, rather than an internal member, by the them are allowed.
presence of the Referential-Member header. This header identifies
the referential member being added. The Ref-Target header contains There appears to be no common practice in this area. Moreover,
some of the policies have significant security risks.
o Moving a target of strong references could be a security
risk to the owner of the target by revealing secret
locations on the target's server.
o A strong reference could be a security risk to the owner of
the reference by revealing secret locations on his server.
o The presence of strong references to resources on a server
could make it impossible to reclaim space on that server
by moving or deleting those target resources.
These considerations together led to the decision not to support
strong references in the short term.
Operations on indirect references do not affect their target
resources, whereas operations on direct references are passed
through to their targets. Both indirect and direct references may
be useful. Each of these types of references is implemented in
existing systems. Existing HTTP servers are capable of supporting
both types of references. In effect, indirect references give
clients access to the reference itself, and allow the reference to
bear properties. Direct references, once created, simplify access
to the target resource by hiding from clients the fact that there
is a reference mediating between the client and the target
resource. They also make access to the target more efficient,
eliminating a round trip required by indirect references to get the
URI of the target resource.
Again, it was believed that supporting direct references would be
too difficult in the short term. Although convenient, they add no
functionality beyond what is available through indirect references.
Existing systems often implement hybrids of direct and indirect
references, for which some operations are passed through to the
target while others are not. This fact muddies the issue of what
exactly WebDAV should support. It also suggests that the
definition of direct references as those for which operations are
passed through to their targets may not really capture a class of
references that are useful. [what else?]
Consequently, it was decided not to support direct references in
the short term.
3.2 Overview
A referential resource is a resource that has no content of its
own, but instead references another resource. The resource it
references may be in the same collection or anywhere else. This
target resource may be a collection or a simple resource or another
reference, or any other sort of resource that may be defined in the
future. A resource may be the target of any number of referential
resources.
Since a referential resource is a resource, it can have properties
just like any other resource. These properties are completely
independent of the properties on its target resource. A new
DAV:reftarget property of referential resources has as its value
the URI of the target resource. the URI of the target resource.
An optional Ref-Integrity request header can be used to tell the To make it possible to distinguish referential resources from
server not to create the referential member unless it can guarantee ordinary resources, a new value of the DAV:resourcetype property
referential integrity (Req 3.1.11). is defined here. The DAV:resourcetype property of all referential
resources MUST have the value reference.
An optional Position request header supports ordering by allowing Although only weak, indirect references are currently supported,
the client to specify where the new referential member is to be two new DAV properties are defined in anticipation of future
placed in the collection's ordering. (This header can also be used support for strong references and direct references. These
with M-PUT to create an internal collection member at a specific properties, DAV:refintegrity and DAV:passthrough, will allow
position in the ordering.) clients to distinguish between weak and strong references, and
between indirect and direct references. All referential resources
MUST have these properties. Although the only value currently
defined for DAV:refintegrity is weak, other values may be defined
in the future. Although the only value currently defined for
DAV:passthrough is none, other values may be defined in the future.
When a server processes an M-PUT request with the 3.3 Creating Referential Resources
Referential-Member header, it MUST set the DAV:resourcetype
property [defined in Goland et al, 1998] of the new resource to be
refmember (Req 3.1.12).
When a server processes an M-PUT request with the 3.3.1 The MKREF Method
Referential-Member header, it MUST set the DAV:reftarget property
to the URI of the target resource (Req 3.1.6).
When a server processes an M-PUT request with the Referential resources are created using the MKREF method. The
Referential-Member header, it MUST set the DAV:refintegrity request-URI of the MKREF request identifies the resource to be
property (Req 3.1.13). created. The required Ref-Target header contains the URI of the
target resource.
If DAV:refintegrity is T, the server MUST insure that the target An optional Ref-Integrity request header is defined below,
resource's DAV:refsource property reflects the new, strong primarily for future support for strong references. The only value
reference to that resource (Req 3.1.14). currently defined for this header is "DAV:weak",although other
values may be used by private agreement. "DAV:weak" is the default
value if the header is not present.
The server SHOULD ignore any content submitted with a request to An optional Pass-Through request header is defined below, primarily
create a referential member in a collection. for future support for direct references. Currently, its value is
always empty, although other values may be used by private
agreement. The default value is empty if the header is not
present.
If an M-PUT request is submitted for an existing collection An optional Position request header supports ordered collections by
member, the existing member's content and properties will be allowing the client to specify where the new referential member is
overwritten. This behavior is analogous to the behavior of a plain to be placed in the collection's ordering. (This header can also
HTTP PUT method. If the Position header is absent in this case, be used with PUT to create an ordinary collection member at a
the server MUST leave the member at its previous position in the specific position in the ordering.)
collection ordering. If the Position header is present, the server
MUST remove it from its previous position, and then insert it at
the requested position. (Req 3.2.4) If the updated referential
member changes from weak to strong or from strong to weak, the
server MUST update the target's DAV:refsource property to reflect
the change.
Example: When a server processes a MKREF request, it MUST set the
DAV:resourcetype property (defined in [WebDAV]) of the new resource
to be DAV:reference.
When a server processes a MKREF request, it MUST set the
DAV:reftarget property to the URI of the target resource.
When a server processes a MKREF request, it MUST set the
DAV:refintegrity property and the DAV:passthrough property.
The client MUST NOT send any content with the MKREF request, and so
MUST NOT use the Content-Length or Transfer-Encoding headers. (See
[HTTP].)
If a MKREF request is submitted for an existing resource, the
existing resource's content and headers will be overwritten. This
behavior is analogous to the behavior of the HTTP PUT method. Live
properties may get new values at the server's discretion; dead
properties will retain their existing values. If the Position
header is absent in this case and the collection is ordered, the
server MUST leave the member at its previous position in the
collection ordering. If the Position header is present and the
collection is ordered, the server MUST remove it from its previous
position, and then insert it at the requested position.
3.3.2 Status Codes
201 Created
200 OK: modified an existing resource
409 Conflict: no resource at Ref-Target
unrecognized / unsupported value for Ref-Integrity
unrecognized / unsupported value for Pass-Through
400 Bad Request: content not allowed
409 Conflict: Position Before / After a URI that is not in this
collection
400 Bad Request: Position Before / After self
409 Conflict: Position header, but not an ordered collection
425 Insufficient Space on Resource
409 Conflict: Parent collection does not exist
3.3.3 Example
Request: Request:
M-PUT /~whitehead/dav/ HTTP/1.1 MKREF /~whitehead/dav/spec08.ref HTTP/1.1
HOST: www.ics.uci.edu HOST: www.ics.uci.edu
Man: "DAV:Coll-headers" Ref-Target: <http://www.ics.uci.edu/i-d/draft-webdav-protocol- 08.txt>
Referential-Member: spec08.ref
Ref-Target: http://www.ics.uci.edu/i-d/draft-webdav-protocol-08.txt
Ref-Integrity: T
Position: After requirements.html
Content-Length: 0
Response: Response:
HTTP/1.1 200 OK HTTP/1.1 201 Created
3.3 Deleting Referential Members of a Collection (Req 3.1.8) This request resulted in the creation of a new referential resource
at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the
resource identified by the Ref-Target header. Its DAV:resourcetype
property is set to DAV:reference. Its DAV:reftarget property is
set to the URI of its target resource. Its DAV:refintegrity
property is set to the default value of DAV:weak. Its
DAV:passthrough property is set to the default value of EMPTY.
DELETE is the appropriate method to use to remove a referential 3.4 Deleting Referential Resources
member from a collection. DELETE on a referential member has no
affect on its target resource unless the referential member is a
strong reference. In this case, the server MUST insure that the
DAV:refsource property of its target resource reflects this change.
Example: 3.4.1 The DELREF Method
The new DELREF method is used to delete referential resources.
DELREF on a referential resource has no effect on its target
resource.
3.4.2 Status Codes
200 OK
405 Method Not Allowed: Request-URI is not a reference
404 Not Found: No resource at Request-URI
3.4.3 Example
Request: Request:
DELETE /~whitehead/dav/spec08.ref HTTP/1.1 DELREF /~whitehead/dav/spec08.ref HTTP/1.1
HOST: www.ics.uci.edu HOST: www.ics.uci.edu
Response: Response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
The referential member spec08.ref of collection /~whitehead/dav/ The referential resource /~whitehead/dav/spec08.ref has been
has been deleted, but its target resource on www.ietf.org still deleted, but its target resource still exists.
exists. The DAV:refsource property of http://www.ics.uci.edu/
i-d/draft-webdav-protocol-08.txt has been updated
so that it no longer shows a reference from spec08.ref.
3.4 Listing Referential Members of a Collection (Req 3.1.10) 3.4.4 Design Rationale
The HTTP DELETE method can be used to delete indirect references,
since by definition these references do not pass operations through
to their targets.
If direct references are supported in the future, however, a method
distinct from the HTTP DELETE method will be needed for deleting
the reference itself. Since direct references do pass operations
through to their targets, DELETE would delete the target resource
rather than the reference itself.
DELREF is being introduced now in anticipation of future needs,
and can be used in all cases where a reference is to be deleted.
3.5 Listing Referential Members of a Collection
Since a referential member of a collection is just a resource in Since a referential member of a collection is just a resource in
the collection, a listing of members of the collection shows the collection, a listing of members of the collection shows
referential members along with internal members. That is, a referential members along with ordinary members. That is, a WebDAV
PROPFIND on a collection resource with Depth = 1 or infinity MUST PROPFIND request on a collection resource with Depth = 1 or
return a response XML element for each internal member and for each infinity MUST return a response XML element for each ordinary
referential member. member and for each referential member.
If Depth = infinity in the PROPFIND request, the server SHOULD NOT If Depth = infinity in the PROPFIND request, the server MUST NOT
follow references into any collections to which they may refer. follow indirect references into any collections to which they may
refer.
3.5 Other Operations on Referential Members of a Collection 3.6 Other WebDAV Operations on Indirect Referential Resources
In general, operations that modify resources, when applied to a By definition, operations on an indirect reference affect only the
referential member of a collection, affect the referential member, reference, and not its target resource. Since only indirect
not its target resource (Req 3.1.4). There is only one exception references are supported by this specification, WebDAV operations
to this general rule: For strong references, operations on the that are applied to them affect only the referential resource, not
referential member may cause changes to the refsource property its target resource.
of its target resource.
A LOCK operation on a referential member of a collection locks the A LOCK operation on an indirect reference locks the referential
referential member, not its target. A LOCK on the collection with resource, not its target. A LOCK on the collection with
Depth = 1 or infinity locks the referential members along with all Depth = 1 or infinity locks the referential members along with all
the other members of the collection, but not the targets of the the other members of the collection, but not the targets of the
referential members. indirect referential members.
A PROPPATCH on a referential member of a collection modifies the A PROPPATCH on an indirect referential resource modifies the
properties of the referential member, not the properties of its properties of the referential resource, not the properties of its
target resource. target resource.
A MOVE operation on a referential member of a collection moves the A PROPFIND on an indirect referential resource returns the
referential member to a different collection, but has no effect on properties of the referential resource, not the properties of its
the location of its target. If the referential member was a strong target resource.
reference at its old location, the server MUST remove its old URI
from the list in the target's refsource property. If the client
wants the referential member at its new location to be a strong
reference, it must use the M-MOVE method with the Ref-Integrity
header to perform the move. If the server is able to comply with
the request, it MUST add the referential member's new URI to the
list in the refsource property of its target.
A COPY operation on a referential member copies the referential A MOVE operation on an indirect referential resource moves the
member, not its target resource, to another collection. If the referential resource to a different location, but has no effect on
client wants the referential member in the new location to be a the location of its target. The DAV:reftarget property is unchanged
strong reference, it must use the M-COPY method with the after a MOVE unless the Ref-Target header is used to change it.
Ref-Integrity header to perform the copy. If the server is able
to comply with the request, it MUST add the URI of the new copy to
the list in the refsource property of its target.
A PUT operation (or an M-PUT without a Referential-Member header) A COPY operation on an indirect referential resource copies the
creates an internal collection member, not a referential member. referential resource, not its target resource, to another location.
If a strong reference is replaced by an internal member as a result The DAV:reftarget property of the destination resource is the same
of a PUT or M-PUT, the server MUST remove the URI of the as the DAV:reftarget of the source resource, unless the Ref-Target
referential member from the DAV:refsource property of its target. header is used to change it.
Similarly, operations that retrieve information, when applied to a 3.7 HTTP Operations on Indirect Referential Resources
referential member of a collection, retrieve information relating
to the referential member, not its target resource. A PROPFIND on
a referential member returns the properties of the referential
member, not the properties of its target resource. A GET on a
referential member of a collection returns its own content, which
is the URI of its target resource, not the content of its target
resource.
3.6 Operations on Targets of Referential Collection Members Although existing HTTP clients cannot create referential resources,
they should be able to read collections created by Class 3 WebDAV
clients. They should be able to follow any references in those
collections to their targets. To make this possible, a server that
receives a GET or HEAD on an indirect reference MUST return a 302
(Moved Temporarily) status code. The server MUST follow [HTTP]
Section 10.3.3 "302 Moved Temporarily," but with these additional
rules:
Operations on targets of referential collection members have no o The Location header MUST contain the target URI of the
effect on the referential member unless the referential member is reference.
a strong reference. When the target of a strong reference is
MOVEd, the server MUST update the DAV:reftarget property of the
referential member to reflect its new location. When a client
attempts to delete a target of a strong reference, the server
MUST maintain referential integrity, either by deleting the
strong reference at the same time, or by failing the request to
delete the target.
(Provide an error code and response type to tell the client the value of o The response MUST include a Resource-Type header with the
the refsource property) value "Reference". This header allows Class 3 WebDAV clients
to recognize the resource as a reference and understand the
reason for the redirection.
o The response MUST also include those HTTP headers that make
sense for referential resources, at a minimum: Cache-Control,
Age, ETag, Expires, and Last-Modified.
POST cannot be applied to an indirect reference. A reference
cannot accept another entity as its subordinate. Depending upon
the nature of the target resource, however, it might make sense to
apply POST to the target. A server that receives a POST request
on an indirect reference MUST return a 302 (Moved Temporarily).
The rules for constructing and using the response are the same as
for GET and HEAD, except that there is no requirement to return
Cache-Control, Age, ETag, Expires, or Last-Modified.
PUT cannot be applied to an indirect reference. To replace one
indirect reference with another, MKREF MUST be used. To replace an
indirect reference with an ordinary resource, the reference MUST
first be deleted with DELREF, after which a PUT MUST be used to
create the ordinary resource.
Existing HTTP clients that do not understand referential resources
need to be accommodated, however. To enable these clients to
operate reasonably on indirect references, a server that receives a
PUT request on an indirect reference MUST return a 302 (Moved
Temporarily). The client and server MUST follow [HTTP] Section
10.3.3 "302 Moved Temporarily," but with these additional rules:
o The Location response header MUST contain the target URI of
the reference.
o The response MUST include a Resource-Type header, defined in
Section 5.n below, with the value "Reference". This header
allows Class 3 WebDAV clients to recognize the resource as a
reference and understand the reason for the redirection.
o The response MUST include an entity body for display to users.
The entity body explains that the requested resource is a
reference to another resource, and allows the user to choose
whether to replace the target resource or to replace the
reference.
This last rule is needed for PUT, but not for GET, HEAD, or
POST. Only for PUT does it make sense for the user to confirm
that the operation is to be performed at the request-URI. GET or
HEAD will already have returned all useful information about the
request-URI. POST makes no sense for the indirect reference at the
request-URI. But the user might really want to replace the
indirect reference with the entity in the PUT request.
Although the new DELREF method has been defined for deleting
references, DELETE can be used to delete an indirect reference.
Since by definition operations on an indirect reference affect the
reference, and not its target, DELETE will delete the indirect
reference and leave its target untouched.
3.8 Operations on Targets of Referential Resources
Operations on targets of weak, indirect referential resources have
no effect on the referential resource.
4 Ordered Collections 4 Ordered Collections
A new optional property DAV:ordering is defined to support ordered 4.1 Overview
collections. (Req 3.2.1) It is a property only of collections,
and is not required to be present on a collection. That is, even
compliant servers may have a mix of ordered and unordered
collections. The client decides whether a particular collection
is ordered or not. (Req 3.2.2) The value DAV:ordering is an
ordering-type (Req 3.2.3) followed by a list of the URIs of the
collection's members. Each collection member, whether internal or
referential, must be in the list exactly once (Req 3.2.4, 3.2.8),
and the list must not include any resource that is not a member of
the collection (Req 3.2.5). Only one ordering can be attached to
any collection (Req 3.2.5a). Multiple orderings of the same
resources can be achieved by creating multiple collections
referencing those resources, and attaching a different ordering to
each collection.
The ordering-type, represented by the new DAV:orderingtype XML Collections on a compliant server may be ordered, but need not be.
element,is an href identifying the semantics of the ordering. The It is up to the client to decide whether a given collection is
href SHOULD point to a resource that contains a definition of the ordered and, if so, to specify the semantics to be used for
semantics of the ordering, allowing a human user or software ordering its members. If a collection is ordered, each of its
members must be in the ordering exactly once, and the ordering must
not include any resource that is not a member of the collection.
Only one ordering can be attached to any collection. Multiple
orderings of the same resources can be achieved by creating
multiple collections referencing those resources, and attaching a
different ordering to each collection.
The server is responsible for enforcing these constraints on
orderings. The server MUST remove a resource from the ordering
when it is removed from the collection. The server MUST add a
resource to the ordering when it is added to the collection.
When responding to a PROPFIND on a collection, the server MUST
order the response elements according to the ordering defined
on the collection.
4.2 Creating an Ordered Collection
4.2.1 Overview
When a collection is created, the client can request that it be
ordered and specify the semantics of the ordering by using the
new Ordered header in the MKCOL request, setting its value to the
URI of the semantics to be used. If the client does not want the
collection to be ordered, it may omit the Ordered header, or use
it with the value "DAV:arbitrary".
Every collection MUST have the new DAV:orderingtype property,
which indicates whether the collection is ordered and, if so,
identifies the semantics of the ordering. A value of DAV:arbitrary
indicates that that collection is not ordered. That is, the client
cannot depend on the repeatability of the ordering of results from
a PROPFIND request. Otherwise the value of DAV:orderingtype is an
href that SHOULD point to a resource that contains a definition of
the semantics of the ordering, allowing a human user or software
package to insert new collection members into the ordering package to insert new collection members into the ordering
intelligently. (Req 3.2.3) intelligently.
A client may order the members of a collection with the If the Ordered header is present on a MKCOL request, the server
DAV:ordering property of the collection. The client may use MUST set the collection's DAV:orderingtype property to the value of
PROPFIND to discover the current ordering of the collection, and the Ordered header. If the Ordered header is not present, the
PROPPATCH on the ordering property to modify the ordering. It is server MUST treat the request as if it had an Ordered header with
also possible to insert an internal or referential collection the value "DAV:arbitrary", meaning that the collection is not
member into the ordering at the time the member is is added to the ordered. If the collection is ordered, the server MUST respond to
collection, by using the Position header with the M-PUT, M-COPY, PROPFIND requests on the collection using the specified ordering.
or M-MOVE request. (Req 3.2.9)
The DAV:ordering property is live only to the extent that the 4.2.2 Status Codes
server MUST remove an href from the ordering when a member is
removed from the collection, and the server MUST add the href to
the ordering whenever a member is added to the collection. It MUST
insert the new member at the location specified in the Position
header, if present in the M-PUT request; otherwise, it MUST append
the new member to the end of the ordering. If a PUT or M-Put causes
an existing resource to be replaced, and if the Position header
is absent, the server MUST leave the member at its previous
position in the collection ordering. If the Position header is
present, the server MUST remove the member from its previous
position, and then insert it at the requested position. Whenever
the server receives a PROPPATCH request on the DAV:ordering
property, it MUST verify that each member of the collection appears
in the ordering exactly once. (Reqs 3.2.4, 3.2.5)
When responding to a PROPFIND on a collection, the server MUST No new error conditions are introduced.
order the response elements according to the DAV:ordering property
on the collection. (Req 3.2.6)
5 New Headers 4.2.3 Example
5.1 Referential-Member Request Header Request:
Referential-Member = "Referential-Member" ":" relative URI MKCOL /theNorth/ HTTP/1.1
Host: www.server.org
Ordered: <http://www.server.org/orderings/compass.html>
The Referential-Member request header is used with the M-PUT method Response:
to identify the new referential member to be added to the
collection. The URI is relative to the collection identified by
the request-URI. It is a required header in requests to add a
referential member to a collection.
5.2 Ref-Target Request Header HTTP/1.1 201 Created
Ref-Target = "Ref-Target" ":" URI In this example, a new, ordered collection was created. Its
DAV:orderingtype property has as its value the URI from the
Ordered header. In this case, the URI points to a description of
the semantics governing the ordering. As new members are added to
the collection, clients or end users can consult the semantics to
determine how to position the new members in the ordering.
The Ref-Target request header is used with the M-PUT method to 4.3 Setting the Position of a Collection Member
identify the target resource of the new referential member being
added to a collection. It is a required header in requests to add 4.3.1 Overview
a referential member to a collection.
When a new member is added to a collection with MKREF, PUT, COPY,
or MOVE, its position in the ordering can be set with the new
Position header. The Position header allows the client to specify
that the member should be first in the collection's ordering, last
in the collection's ordering, before some other collection member
in the collection's ordering, or after some other collection member
in the collection's ordering.
The server MUST insert the new member into the ordering at the
location specified in the Position header, if one is present (and
if the collection is ordered); otherwise, it MUST append the new
member to the end of the ordering (if the collection is ordered).
If a PUT or MKREF causes an existing resource to be replaced, and
if the Position header is absent, the server MUST leave the member
at its previous position in the collection ordering. If the
Position header is present, the server MUST remove the member from
its previous position, and then insert it at the requested
position.
4.3.2 Status Codes
201 Created
409 Conflict: Before / After a URI that is not in this collection
400 Bad Request: Before / After self
405 Method Not Allowed: Not an ordered collection
4.3.3 Examples
Request:
MKREF /~whitehead/dav/spec08.ref HTTP/1.1
HOST: www.ics.uci.edu
Ref-Target: <http://www.ics.uci.edu/i-d/draft-webdav-protocol-08.txt>
Position: After <requirements.html>
Response:
HTTP/1.1 201 Created
This request resulted in the creation of a new referential resource
at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the
resource identified by the Ref-Target header. The Position header
in this example caused the server to set its position in the
ordering of the /~whitehead/dav/ collection immediately after the
requirements.html resource.
Request:
MOVE /i-d/draft-webdav-protocol-08.txt HTTP/1.1
Host: www.ics.uci.edu
Destination: </~whitehead/dav/draft-webdav-protocol-08.txt>
Position: First
Response:
HTTP/1.1 409 Conflict
In this case, the server returned a 409 Conflict status code
because the /~whitehead/dav/ collection is an unordered collection.
Consequently, the server was unable to satisfy the Position
header.
4.4 Changing the Semantics of a Collection Ordering
After a collection has been created, a client can change its
ordering semantics, or change an ordered collection to an unordered
collection or vice versa, by using PROPPATCH to change the value of
its DAV:orderingtype property. The client is then responsible for
updating the ordering of the collection members according to the
new semantics. PROPPATCH is defined in [WebDAV], Section 7.2.
4.5 Changing the Position of a Collection Member
4.5.1 The ORDERPATCH Method
To change the position of a collection member in the collection's
ordering, the client MUST use an ORDERPATCH request with a request
body containing an order XML element. The request-URI of an
ORDERPATCH request is the URI of the collection whose ordering is
to be updated. The order XML element identifies the member
resource whose position is to be changed, and describes its new
position in the ordering. The new position can be specified as
first in the ordering, last in the ordering, before some other
collection member in the ordering, or after some other collection
member in the ordering.
4.5.2 Status Codes
Although the protocol currently allows only a single change to be
requested with ORDERPATCH, it is anticipated that this may change
in the future. Consequently, the server MUST return a 207
Multi-Status response, as defined in [WebDAV].
Within the 207 Multi-Status response, the following status codes
are possible:
200 OK
409 Conflict: Before / After a URI that is not in this collection
409 Conflict: href doesn't point to a member of this collection
400 Bad Request: only one change allowed
400 Bad Request: Before / After self
405 Method Not Allowed: Not an ordered collection
405 Method Not Allowed: Not a collection
(It's ok to reposition to the same position)
4.5.3 Example
Consider a collection /coll-1/ with members ordered as follows:
nunavut.map
nunavut.img
baffin.map
baffin.desc
baffin.img
iqaluit.map
nunavut.desc
iqaluit.desc
iqaluit.img
Request:
ORDERPATCH /coll-1/ HTTP/1.1
Host: www.nunanet.com
Content-Type: text/xml
Content-Length: xxx
<?xml version="1.0" ?>
<?xml:namespace ns="DAV:" prefix="d" ?>
<d:order>
<d:member>
<d:href>nunavut.desc</d:href>
<d:position>
<d:after>
<d:href>nunavut.map</d:href>
</d:after>
</d:position>
</d:member>
</d:order>
Response:
HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxx
<?xml version="1.0" ?>
<?xml:namespace ns="DAV:" prefix="d" ?>
<d:multistatus>
<d:response>
<d:href>http://www.nunanet.com/coll-1/nunavut.desc</d:href>
<d:status>HTTP/1.1 200 OK</d:status>
</d:response>
</d:multistatus>
In this example, after the request has been processed, the
map of nunavut is the first member in the collection's ordering:
nunavut.map
nunavut.desc
nunavut.img
baffin.map
baffin.desc
baffin.img
iqaluit.map
iqaluit.desc
iqaluit.img
4.5.4 Design Rationale
The decision to introduce the new ORDERPATCH method was made after
investigating the possibility of using the existing MOVE method
with a Position header. The use of MOVE initially looked
appealingly simple:
MOVE /root/coll-1/foo HTTP/1.1
Host: www.somehost.com
Destination: </root/coll-1/foo>
Position: First
Unfortunately, several features of the semantics of MOVE make it
unsuitable for changing the position of a collection member in the
collection's ordering. First, [WebDAV] defines MOVE as logically
equivalent to a copy followed by a delete of the source resource.
This definition makes it impossible to MOVE a resource to a
destination URL that is the same as the source URL. The resource
would be deleted rather than moved. Second, [WebDAV] states that
when moving a resource to a destination where a resource already
exists, the Overwrite header must be "T", and in this case the
server must DELETE the resource at the destination before
performing the MOVE. Again, this makes it impossible to MOVE
a resource to the same location. Finally, [WebDAV] states that
locks are lost on a MOVE, an outcome that seems undesirable in this
case.
The decision to allow only a single change to be described in a
PROPPATCH request was made in order to accommodate many existing
systems that do not allow multiple changes to be requested at once.
However, the protocol design is extensible to support multiple
requests in the future.
In particular, the decision to define a new order XML element for
ORDERPATCH was made for the sake of extensibility. Although the
current definition of the order XML element allows only a single
change in the ordering per ORDERPATCH request, using an XML element
keeps open the option of later allowing multiple changes to be
described in a single ORDERPATCH request. Similarly, a
Multi-Status response is used in order to keep open the option of
multiple changes in a single request in the future.
5 New Headers
5.1 Ref-Target Request Header
Ref-Target = "Ref-Target" ":" Coded-url
Coded-url is defined in [WebDAV], Section 8.4.
The Ref-Target request header is used with the MKREF method to
identify the target resource of the new referential resource being
created. It is a required header in MKREF requests. This header
may also be used with COPY and MOVE requests to change the target
of the destination reference.
5.2 Ref-Integrity Request Header 5.2 Ref-Integrity Request Header
Ref-Integrity = "Ref-Integrity" ":" ("DAV:weak")
Ref-Integrity = "Ref-Integrity" ":" ("T" | "F") The Ref-Integrity header is defined to allow future support for
strong references. It specifies whether the server should
enforce referential integrity for a referential resource being
created with MKREF. The only value currently defined for the
Ref-Integrity header is "DAV:weak", which means that the server
need not [should not? must not?] enforce referential integrity for
the newly created reference. Other values may be used by private
agreement between the client and server. If the header is not
present on a MKREF request, the server MUST treat the request as
if it has a Ref-Integrity header set to "DAV:weak". This header
may also be used with COPY and MOVE requests. If this header is
not present on a COPY or MOVE request, the DAV:refintegrity
property MUST be treated like any other live property, as
specified in [WebDAV] sections 7.8.2 and 7.9.1.
The Ref-Integrity header specifies whether the server should 5.3 Pass-Through Request Header
enforce referential integrity for a referential member of a
collection being created with M-PUT. If the value of the header is
"T", the server MUST fail the request unless it can guarantee
referential integrity. If the header is not used, the server MUST
treat the request as if it has a Ref-Integrity header set to "F".
5.3 Position Request Header Pass-Through = "Pass-Through" ":" ""
Position = "Position" ":" ("First" | "Last" | ("At" index) | The Pass-Through header is defined to allow future support for
(("Before" | "After") URI)) direct references. Indirect references do not pass operations
index = integer through to their target resources, so for them the value of
the Pass-Through header is empty. Direct references pass all
operations through to their target resources. Other types of
references may pass certain operations through, while others may
affect the reference itself. Since only indirect references are
supported today, the only value currently defined for Pass-Through
is empty. Other values may be used by private agreement between
the client and server. If the header is not present on a MKREF
request, the server MUST treat the request as if it has a
Pass-Through header with the value empty. This header may also be
used with a COPY or MOVE request on a reference. If this header is
not present on a COPY or MOVE request, the DAV:passthrough
property MUST be treated like any other live property, as
specified in [WebDAV] sections 7.8.2 and 7.9.1.
The Position header may be used with M-PUT to tell the server 5.4 Resource-Type Response Header
where in the collection ordering to position the collection member
being added. It may be used for both internal and referential Resource-Type = "Resource-Type" ":" ["DAV:collection" |
members. "DAV:reference" | ""]
The Resource-Type response header contains the value of the
DAV:resourcetype property. It is used with 302 responses to PUT,
POST, GET, or HEAD requests on referential resources to indicate to
the client that the reason for the redirection is that the
request-URI pointed to a referential resource.
5.5 Ordered Request Header
Ordered = "Ordered" ":" ("DAV:arbitrary" | Coded-url)
The Ordered request header may be used with MKCOL to request that
the new collection be ordered and to specify its ordering
semantics. A value of "DAV:arbitrary" indicates that the
collection is not ordered. That is, the client cannot depend on
the repeatability of the ordering of results from a PROPFIND
request. A Coded-url value indicates that the collection is
ordered, and identifies the semantics of the ordering. The
Coded-url SHOULD point to a resource that contains a definition of
the semantics of the ordering, allowing a human user or software
package to insert new collection members into the ordering
intelligently.
If the Ordered header is not present on a MKCOL request, the
server MUST treat the request as if it had an Ordered header with
the value "DAV:arbitrary".
5.6 Position Request Header
Position = "Position" ":" ("First" | "Last" |
(("Before" | "After") Coded-url))
The Position header may be used with MKREF, PUT, COPY, or MOVE to
tell the server where in the collection ordering to position the
resource being added to the collection. It may be used for both
ordinary and referential members.
If the Coded-url is a relative URL, it is interpreted relative to
the collection in which the resource is being created.
If the Position request header is not used, then: If the Position request header is not used, then:
If the request is replacing an existing resource, the server If the request is replacing an existing resource, the server
MUST preserve the present ordering. MUST preserve the present ordering.
If the request is adding a new member to the collection, the If the request is adding a new member to the collection, the
server MUST append the new member to the end of the list in the server MUST append the new member to the end of the ordering
DAV:ordering property (if the collection is ordered). (if the collection is ordered).
6 New Properties 6 New Properties
6.1 reftarget Property 6.1 reftarget Property
Name: reftarget Name: reftarget
Namespace: DAV: Namespace: DAV:
Purpose: A property of referential collection members that Purpose: A required property of referential resources that
provides an efficient way for clients to discover provides an efficient way for clients to discover
the URI of the target resource. the URI of the target resource. This is a readonly
property, whose value can only be set by using the
Ref-Target header with a MKREF, COPY, or MOVE
request.
Value: URI of the target resource. Value: URI of the target resource.
<!ELEMENT reftarget href> <!ELEMENT reftarget href>
6.2 refsource Property 6.2 refintegrity Property
Name: refsource Name: refintegrity
Namespace: DAV: Namespace: DAV:
Purpose: A property of targets of strong referential Purpose: A required property of a referential resource that
collection members that provides a list of all indicates whether the server guarantees referential
strong referential collection members that integrity for that reference. The refintegrity
reference the resource. Aids the server in property is defined to allow future support for
maintaining referential integrity, and allows strong references. The only value currently
clients to discover which strong referential defined for refintegrity is weak, which means that
members reference the target resource. the server need not [does not?] enforce referential
Value: List of URIs of strong referential collection integrity for the reference. Other values may be
members that reference the resource. used by private agreement between the client and
server. This is a readonly property, whose value
can only be set by using the Ref-Integrity header
with a MKREF, COPY, or MOVE request.
Value: weak
<!ELEMENT refsource href+> <!ELEMENT refintegrity (weak)>
6.3 refintegrity Property 6.3 passthrough Property
Name: refintegrity Name: passthrough
Namespace: DAV: Namespace: DAV
Purpose: A property of referential collection members that Purpose: A required property of a referential resource that
indicates whether the server guarantees referential indicates what operations are passed through to its
integrity for that reference. target resource. The passthrough property is
Value: "T" for strong references, "F" for weak references. defined to allow future support for direct
references, which pass all operations through to
their targets. This specification currently
supports only indirect references, which do not
pass any operations through to their targets. The
only value currently defined for passthrough is
EMPTY. Other values may be used by private
agreement between the client and server. This is
a read-only property, whose value can only be set
by using the Pass-Through header with a MKREF,
COPY, or MOVE request.
Value: EMPTY
<!ELEMENT refintegrity ("T" | "F")> <!ELEMENT passthrough EMPTY>
6.4 ordering Property 6.4 orderingtype Property
Name: ordering Name: orderingtype
Namespace: DAV: Namespace: DAV:
Purpose: A property of a collection, specifying the order Purpose: Indicates whether the collection is ordered and, if
of the members of the collection. so, uniquely identifies the semantics of the
Value: A typed list of URIs of the members of the ordering being used. SHOULD also provide an
collection. Each member of the collection, whether explanation of the semantics in human and / or
internal or referential, must be in the list machine-readable form. At a minimum, this allows
exactly once. human users who add members to the collection to
understand where to position them in the ordering.
Value: arbitrary for an unordered collection, or a URI
that uniquely identifies the semantics of the
collection's ordering. The URI SHOULD point to
a definition of the ordering semantics.
<!ELEMENT ordering (orderingtype, href*) > <!ELEMENT orderingtype (arbitrary | href) >
7 New XML Elements 7 New XML Elements
7.1 orderingtype XML Element 7.1 reference XML Element
Name: orderingtype Name: reference
Namespace: DAV: Namespace: DAV:
Purpose: Uniquely identifies the semantics of the ordering Purpose: A new value of the DAV:resourcetype property that
being used. SHOULD also provide an explanation of identifies its resource as a referential resource.
the semantics in human and / or machine-readable The DAV:resourcetype property of a referential
form. At a minimum, this allows human users who resource MUST have this value.
add members to the collection to understand where Value: EMPTY
to position them in the ordering.
Value: URI that uniquely identifies the semantics of the
ordering and that SHOULD point to an definition of
the ordering semantics.
<!ELEMENT orderingtype href > <!ELEMENT reference EMPTY >
7.2 refmember XML Element
Name: refmember 7.2 weak XML Element
Name: weak
Namespace: DAV: Namespace: DAV:
Purpose: A new value of the DAV:resourcetype property that Purpose: The only value currently defined for the
identifies its resource as a referential member of DAV:refintegrity property. It means that the
a collection. The DAV:resourcetype property of a server need not [does not?] enforce referential
referential member of a collection MUST have this integrity for the reference to which the property
value. belongs.
Value: EMPTY Value: EMPTY
<!ELEMENT refmember EMPTY > <!ELEMENT weak EMPTY >
7.3 arbitrary XML Element
Name: arbitrary
Namespace: DAV:
Purpose: A value of the DAV:orderingtype property that
indicates that the collection is not ordered. That
is, the client cannot depend on the repeatability
of the ordering of results from a PROPFIND request.
Value: EMPTY
<!ELEMENT arbitrary EMPTY >
7.4 order XML Element
Name: order
Namespace: DAV
Purpose: For use with the new ORDERPATCH method. Describes
a change to be made in a collection ordering.
Value: A description of the new position of a collection
member in the collection's ordering.
<!ELEMENT order member >
7.5 member XML Element
Name: member
Namespace: DAV
Purpose: Occurs in the order XML Element, and describes the
new position of a single collection member in the
collection's ordering.
Value: An href containing the relative URI of the
collection member, and a description of its new
position in the ordering. The href XML element is
defined in [WebDAV], Section 11.3.
<!ELEMENT member (href, position) >
7.6 position XML Element
Name: position
Namespace: DAV
Purpose: Occurs in the member XML element. Describes the
new position in a collection's ordering of one of
the collection's members.
Value: The new position can be described as first in the
collection's ordering, last in the collection's
ordering, before some other member of the
collection, or after some other member of the
collection.
<!ELEMENT position (first | last | before | after)>
7.7 first XML Element
Name: first
Namespace: DAV
Purpose: Occurs in the position XML element. Describes the
collection member's position as first in the
collection's ordering.
Value: EMPTY
<!ELEMENT first EMPTY >
7.8 last XML Element
Name: last
Namespace: DAV
Purpose: Occurs in the position XML element. Describes the
collection member's position as last in the
collection's ordering.
Value: EMPTY
<!ELEMENT last EMPTY >
7.9 before XML Element
Name: before
Namespace: DAV
Purpose: Occurs in the position XML element. Describes the
collection member's position as coming before some
other collection member in the collection's
ordering.
Value: href of the member it precedes in the ordering
<!ELEMENT before href >
7.10 after XML Element
Name: after
Namespace: DAV
Purpose: Occurs in the position XML element. Describes the
collection member's position as coming after some
other collection member in the collection's
ordering.
Value: href of the member it follows in the ordering
<!ELEMENT after href >
8 Compliance 8 Compliance
Section 14 of [Goland et al, 1998] defined a DAV header for use Section 14 of [Goland et al, 1998] defined a DAV header for use
when responding to OPTIONS requests. This header provides a way when responding to OPTIONS requests. This header provides a way
for clients to discover which parts of WebDAV a resource supports. for clients to discover which parts of WebDAV a resource supports.
The WebDAV specifications define numbered compliance classes The WebDAV specifications define numbered compliance classes
corresponding to collections of related functions that resources corresponding to collections of related functions that resources
may support. When the server receives an OPTIONS request, it lists may support. When the server receives an OPTIONS request, it lists
the classes that the request-URI supports in the DAV response the classes that the request-URI supports in the DAV response
header. header.
Since this specification defines two independent sets of Since this specification defines two independent sets of
functionality, it defines two new compliance classes. A WebDAV functionality, it defines two new compliance classes. A WebDAV
server may support neither, one or the other, or both for any server may support neither, one or the other, or both for any
resource. resource.
8.1 Class 3 8.1 Class 3
This new compliance class indicates compliance with Section 3 This new compliance class indicates compliance with Section 3
"Referential Members" of this specification. Servers that comply "Referential Resources" of this specification. Servers that comply
with Section 3 MUST list this class in the DAV response header with Section 3 MUST list this class in the DAV response header
when they respond to an OPTIONS request. when they respond to an OPTIONS request.
8.2 Class 4 8.2 Class 4
This new compliance class indicates compliance with Section 4 This new compliance class indicates compliance with Section 4
"Ordered Collections" of this specification. Servers that comply "Ordered Collections" of this specification. Servers that comply
with Section 4 MUST list this class in the DAV response header with Section 4 MUST list this class in the DAV response header
when they respond to an OPTIONS request. when they respond to an OPTIONS request.
9 Dependencies on Other Specifications 9 Dependencies on Other Specifications
[Nielsen et al., 1998] "Mandatory Extensions in HTTP." TBD
10 Security Considerations 10 Security Considerations
This section is provided to detail issues concerning security
implications of which WebDAV applications need to be aware.
All of the security considerations of HTTP/1.1 and the base WebDAV
protocol also apply to WebDAV collections. In addition,
referential resources and ordered collections introduce several
new security concerns and increase the risk of some existing
threats. These issues are detailed below.
10.1 Redirect Loops
Although redirect loops were already possible in HTTP 1.1, the
introduction of referential resources creates a new avenue for
clients to create loops accidentally or maliciously. If the
referential resource and its target are on the same server, the
server may be able to detect MKREF requests that would create
loops. See also [HTTP], Section 10.3 "Redirection 3xx."
10.2 References and Denial of Service
The introduction of referential resources creates a new avenue
for denial of service attacks. Clients can create heavily used
references to target locations that were not designed for heavy
usage.
10.3 Malicious Modifications of Ordering
Particularly in large collections, moving a collection member to
a different position in the ordering can make it very difficult
for users to find.
10.4 Denial of Service and DAV:orderingtype
There may be some risk of denial of service at sites that are
advertised in the DAV:orderingtype property of collections.
However, it is anticipated that widely-deployed applications will
use hard-coded values for frequently-used ordering semantics
rather than looking up the semantics at the location specified by
DAV:orderingtype.
11 Internationalization Considerations 11 Internationalization Considerations
This specification follows the practices of [WebDAV] in encoding
all human-readable content using XML [XML] and in the treatment
of names. Consequently, this specification complies with the
IETF Character Set Policy [Alvestrand].
WebDAV applications MUST support the character set tagging,
character set encoding, and the language tagging functionality of
the XML specification. This constraint ensures that the human-
readable content of this specification complies with [Alvestrand].
As in [WebDAV}, names in this specification fall into three
categories: names of protocol elements such as methods and
headers, names of XML elements, and names of properties. Naming
of protocol elements follows the precedent of HTTP, using English
names encoded in USASCII for methods and headers. The names of
XML elements used in this specification are English names encoded
in UTF-8.
For error reporting, [WebDAV] follows the convention of HTTP/1.1
status codes, including with each status code a short, English
description of the code (e.g., 423 Locked). Internationalized
applications will ignore this message, and display an appropriate
message in the user's language and character set.
For rationales for these decisions and advice for application
implementors, see [WebDAV].
12 IANA Considerations 12 IANA Considerations
TBD
13 Copyright 13 Copyright
14 Intellectual Property 14 Intellectual Property
15 Acknowledgements 15 Acknowledgements
This draft has benefited from thoughtful discussion by
Steve Carter, Ellis Cohen, Spencer Dawkins, Rajiv Dulepet,
Chuck Fay, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann,
Marcus Jager, Rohit Khare, Daniel LaLiberte, Steve Martin,
Surendra Koduru Reddy, Sam Ruby, Bradley Sergeant, Nick Shelness,
John Stracke, John Tigue, John Turner, and others.
16 References 16 References
[Goland et al., 1998] Y. Y. Goland, E. J. Whitehead, Jr., A. [WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A.
Faizi, S. R. Carter, D. Jensen, "Extensions for Distributed Faizi, S. R. Carter, D. Jensen, "Extensions for Distributed
Authoring on the World Wide Web - WebDAV." Draft-ietf-webdav- Authoring on the World Wide Web - WebDAV." Draft-ietf-webdav-
protocol-08. Internet Draft, work in progress. Microsoft, protocol-08. Internet Draft, work in progress. Microsoft,
U.C. Irvine, Netscape, Novell. April, 1998. U.C. Irvine, Netscape, Novell. April, 1998.
[Slein, 1998] J. Slein, "Requirements for Advanced Collection [DASL] Saveen Reddy, D. Jensen, Surendra Reddy,
Functionality in WebDAV." Draft-ietf-webdav-collection-reqts-01. R. Henderson, J. Davis, A. Babich, "DAV Searching & Locating."
Internet Draft, work in progress. Xerox, 1998. Draft-reddy-dasl-protocol-02. Internet Draft, work in progress.
Microsoft, Novell, Oracle, Netscape, Xerox, Filenet. June, 1998.
[Nielsen et al., 1998] H. F. Nielsen, P. Leach, S. Lawrence, [WebDAVReq] J. Slein, J. Davis, "Requirements for Advanced
"Mandatory Extensions in HTTP." Draft-ietf-http-ext-mandatory-00. Collection Functionality in WebDAV." Draft-ietf-webdav-collection-
Internet Draft, work in progress. W3C, Microsoft, Agranat, 1998. reqts-02. Internet Draft, work in progress. Xerox, 1998.
[HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk,
T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1."
RFC 2068. UC Irvine, DEC, MIT/LCS. January, 1997.
[XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup
Language (XML)." World Wide Web Consortium Recommendation
REC-xml-19980210. http://www.w3.org/TR/1998/REC-xml-19980210.
17 Authors' Addresses 17 Authors' Addresses
J. Slein J. Slein
Xerox Corporation Xerox Corporation
800 Phillips Road, 105-50C 800 Phillips Road, 105-50C
Webster, NY 14580 Webster, NY 14580
Email: slein@wrc.xerox.com Email: slein@wrc.xerox.com
Expires December 5, 1998 J. Davis
Xerox Corporation
3333 Coyote Hill Road
Palo Alto, CA 94304
Email: jdavis@parc.xerox.com
A. Babich
FileNet Corporation
3565 Harbor Boulevard
Costa Mesa, CA 92626-1420
Email: ababich@filenet.com
E.J. Whitehead Jr.
Dept. of Information and Computer Science
University of California, Irvine
Irvine, CA 92697-3425
Email: ejw@ics.uci.edu
Expires January 31, 1999
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/