WEBDAV Working Group                                     J. Slein, Xerox
INTERNET DRAFT                             E.J. Whitehead Jr., UC Irvine
                                                     J. Davis, CourseNet
                                                      G. Clemm, Rational
                                                         C. Fay, FileNet
                                                        J. Crawford, IBM
                                                 T. Chihaya, DataChannel
                                                           June 18, 1999
Expires December 18, 1999

			WebDAV Advanced Collections Protocol
               draft-ietf-webdav-collection-protocol-04.txt

Status of this Memo

This document is an Internet-Draft and is in full conformance with all 
provisions of Section 10 of RFC2026. 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.

Distribution of this document is unlimited. Please send comments to the 
Distributed Authoring and Versioning (WebDAV) working group at <w3c-
dist-auth@w3.org>, which may be joined by sending a message with subject 
"subscribe" to <w3c-dist-auth-request@w3.org>.

Discussions of the WEBDAV working group are archived at URL: 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/>.

Abstract

The WebDAV Distributed Authoring Protocol provides basic support for 
collections, offering the ability to create and list unordered 
collections.  Many applications, however, need more powerful 
collections, especially for resource sharing and collection ordering.

This specification defines HTTP methods, headers, and XML elements that 
supplement the WebDAV Distributed Authoring Protocol to support resource 
sharing and collection orderings.  Resource sharing is provided by 
bindings and redirect references.  Bindings create new mappings of URIs 
to resources, while redirect references respond to most requests with an 
HTTP Redirection (i.e., a 302 status code).  An ordered collection 
always returns a listing of its members in a specific order.  Together, 
these capabilities are referred to as WebDAV Advanced Collections.

Table of Contents

1	Notational Conventions......................................3
2	Terminology.................................................4
3	Introduction................................................5

Slein et al.                                                    Page 1

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

4	Shared Resources............................................6
4.1	Overview....................................................6
4.2	Bindings....................................................7
4.2.1	BIND Method.................................................8
4.2.2	Bindings to Collections.....................................9
4.2.3	URI Mappings Created by BIND...............................10
4.2.4	Example: Generating the Set of URI Mappings................10
4.2.5	Status Codes...............................................11
4.2.6	Example: BIND..............................................11
4.2.7	Example: BIND Conflict.....................................12
4.2.8	DELETE and Bindings........................................12
4.2.9	COPY and Bindings..........................................13
4.2.10	MOVE and Bindings..........................................13
4.2.11	LOCK and UNLOCK............................................15
4.2.12	Bindings and Other Methods.................................16
4.2.13	Discovering the Bindings to a Resource.....................16
4.3	Redirect References........................................17
4.3.1	MKREF Method...............................................17
4.3.2	Listing the Redirect References in a Collection............19
4.3.3	Copying Redirect References................................22
4.3.4	Deleting and Moving Redirect References....................24
4.3.5	Locking Redirect References................................24
4.3.6	LOCK on Redirect References................................25
4.3.7	Other Operations on Redirect References....................28
4.3.8	Operations on Targets of Redirect References...............30
4.3.9	Relative URIs in Ref-Target and DAV:reftarget..............31
4.3.10	Redirect References to Collections.........................32
5	Ordered Collections........................................33
5.1	Overview...................................................33
5.2	Creating an Ordered Collection.............................34
5.2.1	Overview...................................................34
5.2.2	Example: Creating an Ordered Collection....................34
5.3	Setting the Position of a Collection Member................35
5.3.1	Overview...................................................35
5.3.2	Status Codes...............................................35
5.3.3	Examples: Setting the Position of a Collection Member......35
5.4	Changing the Semantics of a Collection Ordering............36
5.5	Changing the Position of a Collection Member...............36
5.5.1	ORDERPATCH Method..........................................36
5.5.2	Status Codes...............................................36
5.5.3	Example: Changing Positions in an Ordered Collection.......37
5.5.4	Example: Failure of an ORDERPATCH Request..................38
6	Headers....................................................39
6.1	All-Bindings Request Header................................39
6.2	Ref-Target Entity Header...................................39
6.3	Resource-Type Entity Header................................40
6.4	Passthrough Request Header.................................40
6.5	Ordered Entity Header......................................40
6.6	Position Request Header....................................40
7	Status Codes...............................................41

Slein et al.                                                    Page 2

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

7.1	506 Loop Detected..........................................41
7.2	425 Unordered Collection...................................41
8	Properties.................................................41
8.1	reftarget Property.........................................41
8.2	location Property..........................................42
8.3	bindings Property..........................................42
8.4	orderingtype Property......................................42
9	XML Elements...............................................43
9.1	redirectref XML Element....................................43
9.2	segment XML Element........................................43
9.3	unordered XML Element......................................43
9.4	custom XML Element.........................................43
9.5	order XML Element..........................................44
9.6	ordermember XML Element....................................44
9.7	position XML Element.......................................44
9.8	first XML Element..........................................44
9.9	last XML Element...........................................44
9.10	before XML Element.........................................45
9.11	after XML Element..........................................45
9.12	options XML Element........................................45
9.13	orderingoptions XML Element................................45
10	Extensions to the DAV:response XML Element for Multi-Status 
        Responses..................................................45
11	Capability Discovery.......................................46
11.1	Compliance Classes.........................................46
11.2	Example: Discovery of Compliance Classes...................46
11.3	Additional Advanced Collections Capabilities...............47
11.4	Example: Discovery of Ordering Options.....................47
12	Security Considerations....................................48
12.1	Privacy Concerns...........................................48
12.2	Redirect Loops.............................................48
12.3	Redirect References, Bindings, and Denial of Service.......48
12.4	Private Locations May Be Revealed..........................49
12.5	DAV:bindings and Denial of Service.........................49
12.6	Denial of Service and DAV:orderingtype.....................49
13	Internationalization Considerations........................49
14	IANA Considerations........................................50
15	Copyright..................................................50
16	Intellectual Property......................................50
17	Acknowledgements...........................................50
18	References.................................................50
18.1	Normative References.......................................50
18.2	Informational References...................................51
19	Authors' Addresses.........................................51
20	Appendices.................................................52
20.1	Appendix 1: Extensions to the WebDAV Document Type 
        Definition.................................................52

1 Notational Conventions

Since this document describes a set of extensions to the HTTP/1.1 
protocol, the augmented BNF used here to describe protocol elements is 
exactly the same as described in Section 2.1 of [HTTP].  Since this 
augmented BNF uses the basic production rules provided in Section 2.2 of 
[HTTP], these rules apply to this document as well.


Slein et al.                                                    Page 3

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

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 [RFC2119].

2 Terminology

The terminology used here follows and extends that in the WebDAV 
Distributed Authoring Protocol specification [WebDAV]. Definitions of 
the terms resource, Uniform Resource Identifier (URI), and Uniform 
Resource Locator (URL) are provided in [URI].

Association
     A direct or indirect connection between a resource and a namespace 
     element that supports resource sharing. The bindings, URI 
     mappings, and redirect references defined in this specification 
     are types of associations.

URI Mapping
     An association between an absolute URL or URI and a resource. 
     Since a resource can represent items that are not network 
     retrievable, as well as those that are, it is possible for a 
     resource to have zero, one, or many URI mappings to URLs or URIs. 
     Mapping a resource to an "http" scheme URL makes it possible to 
     submit HTTP protocol requests to the resource using the URL.

Path Segment
     Informally, the characters found between slashes ("/") in a URL or 
     URI.  Formally, as defined in section 3.3 of [URI].

Binding
     An association between a single path segment (in a collection) and 
     a resource. A binding creates one or more URI mappings, and hence 
     is a mechanism for resource sharing, allowing a single resource to 
     be accessed from multiple locations in a URI namespace.
 
Collection
     A resource that contains, as part of its state, a set of bindings 
     which identify member resources.

Internal Member URI
     The URI mapping, created by a binding that is contained in a 
     collection.  While, in general, bindings can create multiple URI 
     mappings to a resource, for a given request, only one of these URI 
     mappings is referred to as the internal member. The URI of the 
     parent collection used in a given request determines the base URI 
     for internal member URI calculation.

     In [WebDAV], a collection is defined as containing a list of 
     internal member URIs, where an internal member URI is the URI of 
     the collection, plus a single path segment.  This definition 
     combines the two concepts of binding and mapping that are 
     separated in this specification.  As a result, this specification 
     redefines a collection's state to be a set of bindings, and 
     redefines an internal member URI to be a mapping derived from a 
     binding. After this redefinition, an internal member URI can be 

Slein et al.                                                    Page 4

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

     used when reading [WebDAV] without loss of meaning. For purposes 
     of interpretation, when [WebDAV] discusses a collection 
     "containing" an internal member URI, this should be read as the 
     collection containing a binding whose mapping to a URI creates an 
     internal member URI, in this sense "containing" the internal 
     member URI.  The authors of this specification anticipate and 
     recommend that future revisions of [WebDAV] perform a full 
     reconciliation of terms between these two specifications.

Reference
     A resource whose purpose is to provide access to another resource.

Redirect Reference
     A resource whose purpose is to provide access to another resource, 
     and that requires client action before it can be resolved.  The 
     client is aware that this type of reference is mediating between 
     it and the target resource.

Ordinary Resource
     A resource that is not a reference to another resource.

Target Resource
     The resource referenced by a referential resource.

Referential Integrity
     The integrity of a reference is preserved as long as it points to 
     the same resource it pointed to when it was created.  Its 
     integrity may be destroyed if the target resource is moved without 
     updating the reference to reflect its new location, or if the 
     target resource is deleted while a reference to it still exists.

3 Introduction

The simple collections that the WebDAV Distributed Authoring Protocol 
specification supports are powerful enough to be widely useful.  They 
provide for the hierarchical organization of resources, with mechanisms 
for creating and deleting collections, copying and moving them, locking 
them, adding members to them and removing members from them, and getting 
listings of their members.  Delete, copy, move, list, and lock 
operations can be applied recursively, so that a client can operate on 
whole hierarchies with a single request.

Many applications, however, need more powerful collections.  There are 
two areas in particular where more powerful functionality is often 
needed: shared resources and ordering.  This specification defines  
extensions to [WebDAV] in both these areas.

Organizing resources into hierarchies places them into smaller 
groupings, known as collections, which are more easily browsed and 
manipulated than a flat namespace.  However, hierarchies require 
categorization decisions that locate resources at a single location in 
the hierarchy, a drawback when a resource has multiple valid categories. 
For example, in a hierarchy of vehicle descriptions containing 
collections for cars and boats, a description of a combination car/boat 
vehicle could belong in either collection. Ideally, the description 

Slein et al.                                                    Page 5

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

should be accessible from both.

Hierarchies also make resource sharing more difficult, since resources 
that have utility across many collections are still forced into a single 
collection. For example, the mathematics department at one university 
might create a collection of information on fractals that contains 
bindings to some local resources, but also provides access to some 
resources at other universities.  For many reasons, it may be 
undesirable to make physical copies of the shared resources on the local 
server - to conserve disk space, to respect copyright constraints, or to 
make any changes in the shared resources visible automatically.  

This protocol provides two mechanisms for allowing resources to appear 
in multiple places in an http URL hierarchy, and for sharing resources: 
bindings and redirect references.

The WebDAV Distributed Authoring Protocol added to the Web the ability 
to navigate Web resources hierarchically, complementing existing 
hypertext navigation facilities. In hypertext navigation, links appear 
in a specific order in a document. By contrast, hierarchical navigation 
has fewer mechanisms for expressing the ordering of a set of resources.

There are many scenarios where it is useful to impose an ordering on a 
collection, such as expressing a recommended access order, or a revision 
history order. Orderings may be based on property values, but they may 
be completely independent of any properties on the resources identified 
by the collection's internal member URIs.  Orderings based on properties 
can be obtained using a search protocol [DASL], but orderings not based 
on properties need some other mechanism.  These orderings generally need 
to be maintained by a human user.  The ordering protocol defined here 
focuses on support for such human-maintained orderings, but also allows 
for server-maintained orderings.

4 Shared Resources

4.1 Overview

Shared resources make the same resource accessible from multiple 
locations in http URL namespaces.  This protocol provides two mechanisms 
for sharing resources: bindings and redirect references.

The binding mechanism defined in this specification provides a way for 
clients to add new URI mappings to existing resources.  A URI mapping is 
an association between an absolute URI and a resource, which makes it 
possible to submit requests to the resource using that URI as the 
Request-URI. Bindings, and the URI mappings based on them, are appealing 
mechanisms for resource sharing because: 

o Once URI mappings are created with a BIND request, clients need do 
  nothing special to use them.  They behave just like any other URI 
  mappings, transparently applying operations to the target resource.  
o HTTP and WebDAV servers already provide URI mappings, so there is 
  little extra work involved in allowing clients to create them.
o The integrity of bindings is guaranteed.  MOVE and DELETE operations 
  cannot leave bindings in an inconsistent state.  

Slein et al.                                                    Page 6

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999


A limitation of bindings is that a server would need proxy capabilities 
in order to support bindings to resources on another server.  In light 
of this complexity, support for cross-server bindings is OPTIONAL.

A redirect reference is a resource whose purpose is to provide access to 
another resource.  It redirects most requests on the reference to 
another resource, thereby providing a form of mediated access to the 
other resource.  Since the HTTP 302 (Moved Temporarily) status code is 
used to redirect client requests on a redirect reference, from the 
clientĘs point of view redirect references are less convenient to use 
than bindings.  Redirect references require action by the client before 
they can be resolved.  Moreover, the server is not required to enforce 
the integrity of redirect references.  However, redirect references have 
a number of advantages: 

o They are simple for servers to implement.  Servers already provide 
  redirect resources in the form of 301 / 302 redirection control, and 
  the same mechanism can be used for redirect references.
o The same simple implementation works equally well for target 
  resources that reside on the same server and for target resources 
  that reside on a different server.  
o Redirect references have only limited security implications.  
o Since redirect references are resources, they can carry properties of 
  their own.

Ideally, non-referencing clients should be able to use both bindings and 
redirect references.  This goal is more difficult to meet for redirect 
references, since client action is required to resolve them.  The 
strategy of having redirect references respond to most requests with a 
302 (Moved Temporarily), accompanied by the URI of the target resource 
in the Location header, fulfills this goal in most cases.

4.2 Bindings

Bindings are part of the state of a collection. In general, there is a 
one-to-one correspondence between a collection's bindings and its 
internal member URIs.  The URI segment associated with a resource by one 
of a collection's bindings is also the final segment of one of the 
collection's internal member URIs.  The final segment of each internal 
member URI identifies one of the bindings that is part of the 
collection's state, unless the internal member URI is not bound to a 
resource.

Even though a binding is just an association between a path segment and 
a resource, a binding creates one or more URI mappings of a URI to a 
resource.  For example, if the segment "index.html" is being bound to a 
resource in a collection with URL "http://www.foo.net/A/", the binding 
creates a URI mapping of URL "http://www.foo.net/A/index.html" to the 
HTML resource. If the parent collection is then bound to the segment 
"B", this creates two URI mappings, "http://www.foo.net/B/" to the 
collection resource, and "http://www.foo.net/B/index.html" to the HTML 
resource.  Both the collection and the HTML resource are now accessible 
via two URLs apiece.


Slein et al.                                                    Page 7

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

For a resource implemented by a computer, the relationship between a URI 
mapping and a resource is highlighted in the following diagram:

           URI 1   URI 2 ... URI N  
             |       |        |
             |       |        |      <------- URI Mappings
             |       |        |
          +---------------------+
          |     Resource R      |
          +---------------------+

As discussed in [URI], a resource is an abstraction that maps a URI to 
an entity or set of entities.  This resource can have multiple URIs/URLs 
mapped to it.

The identity of a binding is determined by the URI segment (in its
collection) and the resource that the binding associates.  If the 
resource is destroyed, the binding also goes out of existence.  If the 
URI segment comes to be associated with a different resource, the 
original binding ceases to exist and another binding is created.

Bindings are not unique to advanced collections, although the BIND 
method for explicitly creating bindings is introduced here.  Existing 
methods that create resources, such as PUT, MOVE, COPY, and MKCOL, 
implicitly create bindings.  There is no difference between implicitly 
created bindings and bindings created with BIND.

Since a binding is an association between a path segment and a resource, 
it would be very undesirable if one binding could be destroyed as a side 
effect of operating on the resource through a different binding.  It is 
not acceptable for a DELETE or MOVE through a different binding to 
destroy the resource or fail to update one binding, turning that binding 
into a dangling path segment.  As a result, implementations MUST act to 
ensure the integrity of bindings.

It is especially difficult to maintain the integrity of cross-server 
bindings.  Unless the server where the resource resides knows about all 
bindings on all servers to that resource, it may unwittingly destroy the 
resource or move it without notifying a server where a binding resides.  
For example, if server A permits creation of a binding to a resource on 
server B, server A must notify server B about its binding and must have 
an agreement with B that B will not destroy the resource while A's 
binding exists.  Otherwise server B may receive a DELETE request that it 
thinks removes the last binding to the resource and destroy the resource 
while A's binding still exists. 

Consequently, support for cross-server bindings is OPTIONAL.

4.2.1 BIND Method

The BIND method creates a new binding from the final segment of the 
Request-URI (minus any trailing slash) to the resource identified
by the Destination header.  This binding is added to the collection 
identified by the Request-URI minus its trailing slash (if present) and 
final segment.  The Destination header is defined in Section 9.3 of 

Slein et al.                                                    Page 8

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

[WebDAV].

If a server cannot guarantee the binding behavior specified for GET 
(Section 4.2.12), DELETE (Section 4.2.8), and MOVE (Section 4.2.10), the 
BIND request MUST fail with a 501 (Not Implemented) status code.

If the Request-URI ends in a slash ("/") (i.e., the Request-URI 
identifies a collection), the resource identified by the Destination 
header MUST be a collection resource, or the request fails with a 409 
(Conflict) status code. This ensures that URIs ending in a slash are 
always bound to collections.  If the Request-URI does not contain a path 
segment (i.e., it consists simply of a slash "/"), the BIND operation 
MUST fail and report a 409 (Conflict) status code.

After successful processing of a BIND request, it MUST be possible for 
clients to use the Request-URI to submit requests to the resource 
identified by the Destination header.

By default, if the Request-URI identifies an existing binding, the new 
binding replaces the existing binding. This default binding replacement 
behavior can be overridden using the Overwrite header defined in Section 
9.6 of [WebDAV]. 

The Position request header (defined in Section 6.6) MAY be used in BIND 
requests.

A server MAY allow the BIND method to be used to create bindings to 
resources that support content negotiation or to resources that 
dynamically generate response entities.

4.2.2 Bindings to Collections

BIND can create a binding to a collection resource.  A collection 
accessed through such a binding behaves exactly as would a collection 
accessed through any other binding.  Bindings to collections can result 
in loops, which servers MUST detect when processing "Depth: infinity" 
requests.  When a loop is detected, the server MUST respond with a 506 
(Loop Detected) status code (defined in Section 7.1).

Creating a new binding to a collection makes each resource associated 
with a binding in that collection accessible via a new URI, but does not 
result in the creation of a new binding for each of these resources.

For example, suppose a new binding COLLX is created for collection C1 in 
the figure below.  It immediately becomes possible to access resource R1 
using the URI /COLLX/x.gif and to access resource R2 using the URI 
/COLLX/y.jpg, but no new bindings for these child resources were 
created.  This is because bindings are part of the state of a 
collection, and associate a URI that is *relative to that collection* 
with its target resource.  No change to the bindings in Collection C1 is 
needed to make its children accessible using /COLLX/x.gif and 
/COLLX/y.jpg.

+-------------------------+
| Root Collection         |

Slein et al.                                                    Page 9

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

| (properties)            |
|  bindings:              |
|  coll1          COLLX   |
+-------------------------+
    |            /           
    |           / 
    |          / 
+------------------+   
| Collection C1    |   
| (properties)     |   
| bindings:        |
| x.gif     y.jpg  |   
+------------------+   
    |          \                
    |           \                
    |            \               
+-------------+   +-------------+
| Resource R1 |   | Resource R2 |
+-------------+   +-------------+ 

4.2.3 URI Mappings Created by BIND

The set of URI mappings created by a successful BIND operation MUST be 
determined as follows:

1. Start with an empty set of URLs, called U.
2. Take the Request-URI and remove path segments (and associated "/" 
characters) from the right until either (a) a non-WebDAV collection, or 
a non-WebDAV advanced collection is found, or (b) the root, "/" is 
reached (i.e., no characters after the scheme and authority parts of the 
URL).  This is the base URL B.
3. Add B, and all possible domain name variants of B (i.e., all other 
domain names which can be substituted for the domain name in B, and 
still retrieve the resource mapped to B), to URL set U.
4. Calculate the next path segment of the Request-URI, going from right 
to left, and call it S, which is bound to resource R. 
5. For each member of URL set U, called Um, remove Um, then for every 
possible binding to R, create a new URL by adding the binding's path 
segment to Um, then add this new URL to U.
6. If there is no further path segment, then U has the complete set of 
URI mappings. Otherwise, go back to step 4.

4.2.4 Example: Generating the Set of URI Mappings

Assume a server responds to two domain names, www.fuzz.com, and 
fuzz.com, and has a top level that is not WebDAV-aware, called A/.  
Below A/ is an advanced collection that is bound to both 1/ and one/. In 
collection one/ there is a resource called index.html.

>> Request:

BIND /A/1/info.html HTTP/1.1
Host: www.fuzz.com
Destination: http://www.fuzz.com/A/one/index.html


Slein et al.                                                    Page 10

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

>> Response:

HTTP/1.1 201 Created

The set of all possible URI mappings to the resource identified by 
http://www.fuzz.com/A/one/index.html is calculated as follows:

1. U is empty.
2. The base URL, B, is http://www.fuzz.com/A/, since A/ is not WebDAV-
aware.
3. Since there are two domain names for this server, the domain name 
variations of B are added to U, making U contain: http://www.fuzz.com/A/ 
and http://fuzz.com/A/.
4. (iteration 1) The next path segment of the Request-URI is 1/, which 
is bound to an advanced collection resource, R.
5. (iteration 1) Since the advanced collection resource R is bound to 1/ 
and one/, the value of U after the operation is: 
http://www.fuzz.com/A/1/, http://www.fuzz.com/A/one/, 
http://fuzz.com/A/1/, and http://fuzz.com/A/one/.
6. Go back to step 4, since there is one more path segment in the 
Request-URI.
4. (iteration 2) The next path segment of the Request-URI is info.html, 
which is bound to an HTML resource, R.
5. (iteration 2) Since the HTML resource is bound to info.html and 
index.html, the value of U after the operation is: 
http://www.fuzz.com/A/1/index.html, http://www.fuzz.com/A/1/info.html, 
http://www.fuzz.com/A/one/index.html, 
http://www.fuzz.com/A/one/info.html, http://fuzz.com/A/1/index.html, 
http://fuzz.com/A/1/info.html, http://fuzz.com/A/one/index.html, 
http://fuzz.com/A/one/info.html.
6. Since there are no further path segments in the Request-URI, U now 
has the complete set of URI mappings for the resource identified by the 
Destination header.

4.2.5 Status Codes

201 (Created): The binding was successfully created.

400 (Bad Request): The client set an invalid value for the Destination 
or Position header.

409 (Conflict): Several conditions may produce this response.  The URI 
in the Destination header is not mapped to a resource.  The request is 
attempting to create a binding in a collection that does not exist.  The 
request is attempting to position the binding in an unordered 
collection. The request is attempting to re-bind the top-level 
collection.

412 (Precondition Failed): The Overwrite header is "F", and a binding 
already exists for the request-URI.

4.2.6 Example: BIND 

>> Request:


Slein et al.                                                    Page 11

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

BIND /~whitehead/dav/spec08.txt HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/pub/i-d/draft-webdav-protocol-08.txt

>> Response:

HTTP/1.1 201 Created

The server created a new binding, associating "spec08.txt" with the 
resource identified by the URL "http://www.ics.uci.edu/pub/i-d/draft-
webdav-protocol-08.txt".  Clients can now use the Request-URI, 
"http://www.ics.uci.edu/~whitehead/dav/spec08.txt", to submit requests 
to that resource.  As part of this operation, the server added the 
binding "spec08.txt" to collection /~whitehead/dav/.

4.2.7 Example: BIND Conflict

>> Request:

BIND /press/prlogo.gif HTTP/1.1
Host: www.softcorp.com
Destination: http://www.softcorp.com/logos/

>> Response: 

HTTP/1.1 409 Conflict

The client requested the server to create a binding between "prlogo.gif" 
and the resource identified by the URL "http://www.softcorp.com/logos/".  
Since the Destination does end in a slash, while the Request-URI does 
not, the server failed the request, returning a 409 (Conflict) status 
code.

4.2.8 DELETE and Bindings

The DELETE method requests that the server remove the binding between 
the resource identified by the Request-URI and the binding name, the 
last path segment of the Request-URI. The binding MUST be removed from 
its parent collection, identified by the Request-URI minus its trailing 
slash (if present) and final segment. The All-Bindings header may be 
used with DELETE to request that the server remove all bindings to the 
resource identified by the Request-URI.  

Once all bindings to the resource are removed, the server MAY reclaim 
system resources associated with the resource. If DELETE removes a 
binding to a resource, but there remain other bindings to that resource, 
the server MUST NOT reclaim system resources associated with the 
resource.

Since DELETE as specified in [WebDAV] is not an atomic operation, it may 
happen that parts of the hierarchy under the request-URI cannot be 
deleted.  In this case, the response is as described in [WebDAV].

[HTTP] states that "the DELETE method requests that the origin server 
delete the resource identified by the Request-URI."  Because [HTTP] did 

Slein et al.                                                    Page 12

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

not distinguish between bindings and resources, the intent of its 
definition of DELETE is unclear.  We consider the definition presented 
here to be a clarification of the definition in [HTTP].

Section 8.6.1 of [WebDAV] states that during DELETE processing, a server 
"MUST remove any URI for the resource identified by the Request-URI from 
collections which contain it as a member."  Servers that support 
bindings SHOULD NOT follow this requirement.

4.2.9 COPY and Bindings

As defined in Section 8.8 of [WebDAV], COPY causes the resource 
identified by the Request-URI to be duplicated, and makes the new 
resource accessible using the URI specified in the Destination header.  
Upon successful completion of a COPY, a new binding is created between 
the last path segment of the Destination header (including trailing "/", 
if present), and the destination resource. The new binding is added to 
its parent collection, identified by the Destination header minus its 
trailing slash (if present) and final segment.

A COPY with "Depth: 0" MUST NOT duplicate the bindings contained by the 
collection.

As an example, suppose that a COPY is issued to URI 3 for resource R 
below (which is also mapped to URI 1 and URI 2), with the Destination 
header set to URIX.  After successful completion of the COPY operation, 
resource R is duplicated to create resource R', and a new binding has 
been created which creates at least the URI mapping between URIX and the 
new resource (although other URI mappings may also have been created).

 URI 1   URI 2    URI 3                             URIX
   |       |        |                                |
   |       |        |    <---- URI Mappings ---->    |
   |       |        |                                |
+---------------------+                   +------------------------+
|     Resource R      |                   |     Resource RĘ        |
+---------------------+                   +------------------------+

4.2.10 MOVE and Bindings

The MOVE method has the effect of creating a new binding to a resource 
(at the Destination), and removing an existing binding (at the Request-
URI). The name of the new binding is the last path segment of the 
Destination header, and the new binding is added to its parent 
collection, identified by the Destination header minus its trailing 
slash (if present) and final segment.  

As an example, suppose that a MOVE is issued to URI 3 for resource R 
below (which is also mapped to URI 1 and URI 2), with the Destination 
header set to URIX.  After successful completion of the MOVE operation, 
a new binding has been created which creates at least the URI mapping 
between URIX and resource R (although other URI mappings may also have 
been created).  The binding corresponding to the final segment of URI 3 
has been removed, which also causes the URI mapping between URI 3 and R 
to be removed.

Slein et al.                                                    Page 13

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999


>> Before Request:

 URI 1   URI 2    URI 3
   |       |        |                                
   |       |        |      <---- URI Mappings
   |       |        |
+---------------------+                   
|     Resource R      |
+---------------------+                   

>> After Request:

 URI 1   URI 2    URIX
   |       |        |                                
   |       |        |      <---- URI Mappings
   |       |        |
+---------------------+                   
|     Resource R      |
+---------------------+                   

Since MOVE as specified in [WebDAV] is not an atomic operation, it may 
happen that parts of the hierarchy under the request-URI can be moved.  
In this case, the response is as described in [WebDAV].

4.2.10.1 Implementation Note 

In some situations, particularly when the destination is on a different 
server from the original resource, the server may implement MOVE by 
performing a COPY, performing some consistency maintenance on bindings 
and properties, and then performing a DELETE. In the end, all of the 
original bindings except the one corresponding to the Request-URI will 
be associated with the new resource. The binding corresponding to the 
URI in the Destination header will be associated with the new resource. 
And the original resource together with the binding corresponding to the 
Request-URI will have been deleted. This implementation is in accord 
with the definition of MOVE in [WebDAV], and is logically equivalent to 
the definition given above.

The consistency maintenance processing that is required for this 
implementation is as follows:

The DAV:creationdate property of the new resource SHOULD have the same 
value as the DAV:creationdate property of the old resource.

The DAV:getlastmodified property of the new resource SHOULD have the 
same value as the DAV:getlastmodified property of the old resource.

All URIs that were bound to the original resource except for the 
Request-URI MUST be bound instead to the new resource.

Consider again the case where a MOVE is issued to URI 3 for resource R 
(which is also mapped to URI 1 and URI 2), with the Destination header 
set to URIX.  Unlike the previous example, in this implementation, after 
successful completion of the MOVE operation, resource R has been 

Slein et al.                                                    Page 14

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

duplicated as resource R'.  The original bindings corresponding to URI 1 
and URI2 are now associated with R'.  The binding corresponding to the 
Request-URI (URI 3) has been removed.  And a new binding has been 
created which creates at least the URI mapping between URIX and resource 
R'. Note that the server may reclaim the storage associated with 
resource R once the MOVE operation has finished.

>> Before Request:

 URI 1   URI 2    URI 3
   |       |        |                                
   |       |        |      <---- URI Mappings
   |       |        |
+---------------------+                   
|     Resource R      |
+---------------------+                   

>> After Request:

URI1     URI2 ---------------------------------    URIX
  |                                            |     |
   -----------------------------------------   |     |
                                            |  |     |
+---------------------+                   +------------------------+
|     Resource R      |                   |     Resource RĘ        |
+---------------------+                   +------------------------+

4.2.11 LOCK and UNLOCK

Bindings do not affect the semantics of locks, as specified in [WebDAV]. 
Specifically, the requirement in section 8.10.3 that "a LOCK request on 
a resource MUST NOT succeed if it can not be honored by all the URIs 
through which the resource is accessible" still holds.  The LOCK method 
locks the resource, and a lock is visible via all URIs mapped to that 
resource. Similarly, a successful UNLOCK issued via any URI mapping to a 
resource removes the lock from the resource, and this lock removal is 
visible via all URI mappings.

When a resource is locked, the lock owner expects to be able to access 
the resource -- using the same Request-URI that he used to lock the 
resource -- for as long as he holds the lock.  This would not be 
possible if another user could move or delete any of the collections 
corresponding to segments of the request-URI. 

Consequently, for the duration of a lock, it MUST NOT be possible for a 
principal other than the lock owner to make a locked resource 
inaccessible via the URI mapping used to lock the resource.  Only the 
lock owner can move or delete any of the collections corresponding to 
segments of the Request-URI. This restriction does not prevent others 
from modifying those collections, by adding members to them, removing 
members from them, or changing their property values.

For example, if a user locks /plants/herbs/rosemary.html, it is not 
possible for another user to move /plants/herbs/ to 
/plants/flowering/herbs/, or to completely delete /plants/herbs/, though 

Slein et al.                                                    Page 15

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

it is possible this delete operation may succeed in deleting everything 
except for /plants/herbs/rosemary.html and /plants/herbs/.

4.2.12 Bindings and Other Methods

This section describes the interaction of bindings with those HTTP 
methods not yet explicitly discussed.  The semantics of the methods GET, 
HEAD, PUT, POST and OPTIONS are specified in [HTTP].  The semantics of 
PROPFIND, PROPPATCH, and MKCOL are specified in [WebDAV].

For most of these methods, no new complexities are introduced by 
allowing explicit creation of multiple bindings to the same resource.  
For the access operations (GET, HEAD, OPTIONS, and PROPFIND), it is 
simply the case that no matter which URI mapping to a given resource is 
used as the Request-URI, the response is mediated by that same resource.  
The responses may, however, vary depending upon which Request-URI was 
used.  For example, the response to a GET request may contain the 
Request-URI in its entity.

The same is true for POST.  No matter which URI mapping to a given 
resource is used as the Request-URI, the response is mediated by that 
same resource.  The changes made on the server and the responses may, 
however, vary depending upon which Request-URI was used.

If the Request-URI of a PUT identifies an existing resource, then a PUT 
via one URI mapping to this resource MUST produce the same result as a 
PUT with the same headers and request entity body via any other URI 
mapping to the same resource. The change made by a PUT via one URI 
mapping MUST affect the resource that generates the GET response for all 
URI mappings to the same resource.

A PROPPATCH through one URI mapping to a resource MUST produce the same 
changes to its properties as the same PROPPATCH request through a 
different URI mapping to the same resource. 

As specified in [WebDAV], MKCOL cannot overwrite an existing resource. 
MKCOL through any URI mapping to an existing resource must fail. 

The semantics of MKREF are specified in Section 4.5.1 below.  A MKREF 
through one URI mapping to a resource MUST produce the same result as a 
MKREF with the same headers through any other URI mapping to the same 
resource.  By default, it overwrites the resource with a new redirect 
reference.

The semantics of ORDERPATCH are specified in 5.5.1 below.  An ORDERPATCH 
through one URI mapping to a collection MUST produce the same changes to 
its ordering as the same ORDERPATCH request through any other URI 
mapping to the same collection. 

4.2.13 Discovering the Bindings to a Resource

An OPTIONAL DAV:bindings property on a resource provides a list of the 
bindings that associate URI segments with that resource. By retrieving 
this property, a client can discover the bindings that point to the 
resource and the collections that contain bindings to the resource.  As 

Slein et al.                                                    Page 16

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

for all DAV: properties, this specification is silent as to how the 
DAV:bindings property is implemented on the server.

Rationale: A number of scenarios require clients to navigate from a 
resource to the bindings that point to it, and to the collections that 
contain those bindings.  This capability is particularly important for 
Document Management Systems.  Their clients may need to determine, for 
any object in the DMS, what collections contain bindings to that object.  
This information can be used for upward navigation through a hierarchy 
or to discover related documents in other collections.

Risks: When deciding whether to support the DAV:bindings property, 
server implementers / administrators should balance the benefits it 
provides against the cost of maintaining the property and the security 
risks enumerated in Sections 12.5 and 12.6.

4.3 Redirect References

For most operations submitted to a redirect reference, the response is a 
302 (Moved Temporarily), accompanied by the Resource-Type header 
(defined in Section 6.2 below) set to "DAV:redirectref" and the Location 
header set to the URI of the target resource.  With this information, 
the client can resubmit the request to the URI of the target resource.  
The methods COPY (for collections containing redirect references), 
DELETE, MOVE, and LOCK, for reasons that will be explained, are 
exceptions to this general behavior. These exceptional operations are 
applied to the reference itself and do not result in a 302 response.

If the client is aware that it is operating on a redirect reference, it 
can resolve the reference by retrieving the reference's DAV:reftarget 
property (defined in Section 7.1 below), whose value is the URI of the 
target resource.  It can then submit requests to the target resource. 

A redirect reference is a new type of resource. To distinguish redirect 
references from ordinary resources, a new value of the DAV:resourcetype 
property (defined in [WebDAV]), DAV:redirectref, is defined in Section 
8.1 below.

Since a redirect reference is a resource, it is possible to apply 
methods to the reference rather than to its target.  The Passthrough 
request header (defined in Section 6.4 below) is provided so that 
referencing-aware clients can control whether an operation is applied to 
the redirect reference or to its target resource.  The Passthrough 
header can be used with most requests to redirect references.  This 
header is particularly useful with PROPFIND, to retrieve the reference's 
own properties.

4.3.1 MKREF Method

The MKREF method creates a redirect reference resource identified by the 
Request-URI, whose target is identified by the REQUIRED Ref-Target 
header. MKREF sets the value of the REQUIRED DAV:reftarget property to 
the value of the Ref-Target header.

The MKREF method creates a new binding between the new redirect 

Slein et al.                                                    Page 17

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

reference resource and the last path segment of the Request-URI.  The 
new binding is added to its parent collection, identified by the 
Request-URI minus its trailing slash (if present) and final segment.

The Position request header (defined in Section 6.6) MAY be used in 
MKREF requests.

MKREF requests MAY include an entity body.  This specification does not 
define the action to be taken if a request entity body is present, but 
allows it for extensibility. 

By default, if the Request-URI of the MKREF request identifies an 
existing resource, the server MUST perform a delete operation on the 
existing resource before performing the MKREF. This default behavior can 
be overridden using the Overwrite header defined in Section 9.6 of 
[WebDAV].

4.3.1.1 Status Codes

201 (Created): The redirect reference resource was successfully created.

400 (Bad Request): The client set an invalid value for the Ref-Target or 
Position header.

409 (Conflict): Several conditions may produce this response.  There may 
be no resource at the location specified in Ref-Target, on a server that 
prohibits dangling references.  The request may be attempting to create 
the reference in a collection that does not exist.  The request may be 
attempting to position the reference before or after a resource that is 
not in the collection, or before or after itself.  The request may be 
attempting to position the reference in an unordered collection.

412 (Precondition Failed): The Overwrite header is "F", and a resource 
already exists at the request-URI.  

4.3.1.2 Example: MKREF

>> Request:

MKREF /~whitehead/dav/spec08.ref HTTP/1.1
Host: www.ics.uci.edu
Ref-Target: /i-d/draft-webdav-protocol-08.txt

>> Response:

HTTP/1.1 201 Created

This request resulted in the creation of a new redirect reference at 
www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the resource 
identified by the Ref-Target header. In this example, the target 
resource of the referential resource is identified by the URI 
http://www.ics.uci.edu/~whitehead/dav/i-d/draft-webdav-protocol-08.txt. 
The referential resource's DAV:resourcetype property is set to 
DAV:redirectref.  Its DAV:reftarget property is set to the value of the 
Ref-Target header, "/i-d/draft-webdav-protocol-08.txt".

Slein et al.                                                    Page 18

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999


4.3.2 Listing the Redirect References in a Collection

A URI of a redirect reference can be an internal member URI of a 
collection just as the URI of an ordinary resource can.  A listing of 
the internal member URIs of a collection shows all of the URIs that are 
internal members of the collection, whether they identify redirect 
references or ordinary resources.  That is, a WebDAV PROPFIND request on 
a collection resource with the Depth header set to 1 or infinity MUST 
return a response XML element for each member URI in the collection, 
whether it identifies an ordinary resource or a redirect reference.

For each redirect reference, the response element MUST contain a 302 
(Moved Temporarily) status code unless a Passthrough header with the 
value "F" is included with the PROPFIND request.  The DAV:location and 
DAV:resourcetype properties MUST be included with the 302 status code, 
extending the syntax of the DAV:response element that was defined in 
[WebDAV] as described in Section 9 below.  A referencing-aware client 
can tell from the DAV:resourcetype property that the collection contains 
a redirect reference.  The DAV:location property contains the absolute 
URI of the target resource.  A referencing-aware client can either use 
the URI value of the DAV:location property to retrieve the properties of 
the target resource, or it can submit a PROPFIND to the redirect 
reference with "Passthrough: F" to retrieve its properties.  It is 
recommended that future editors of [WebDAV] define the DAV:location 
property in [WebDAV], so that non-referencing clients will also be able 
to use the response to retrieve the properties of the target resource.

If the Depth header is set to infinity in the PROPFIND request, the 
server MUST NOT follow redirect references into any collections to which 
they may refer.

The Passthrough header (defined in Section 6.4) MAY be used with a 
PROPFIND request on a collection. 

4.3.2.1 Example: PROPFIND on a Collection with Redirect References

Suppose a PROPFIND request with Depth = infinity is submitted to the 
following collection, with the members shown here:

http://www.svr.com/MyCollection/
   (ordinary resource) diary.html
   (redirect reference) nunavut

>> Request:

PROPFIND /MyCollection/ HTTP/1.1
Host: www.svr.com
Depth: infinity
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" ?>
<D:propfind xmlns:D="DAV: ">
   <D:prop xmlns:J="http://www.svr.com/jsprops/">

Slein et al.                                                    Page 19

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

      <D:resourcetype/>
      <J:keywords/>
   </D:prop>
</D:propfind>

>> Response:

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

<?xml version="1.0" ?>
<D:multistatus xmlns:D="DAV:"
               xmlns:J="http://www.svr.com/jsprops/">
   <D:response>
      <D:href>http://www.svr.com/MyCollection/</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype><D:collection/></D:resourcetype>
            <J:keywords>diary, interests, hobbies</J:keywords>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
   </D:response>
   <D:response>
      <D:href>http://www.svr.com/MyCollection/diary.html</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype/>
            <J:keywords>diary, travel, family, history</J:keywords>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
   </D:response>
   <D:response>
      <D:href>http://www.svr.com/MyCollection/nunavut</D:href>
      <D:status>HTTP/1.1 302 Moved Temporarily</D:status>
      <D:prop>
         <D:location> 
            <D:href>http://www.inac.gc.ca/art/inuit/</D:href>
         </D:location>
         <D:resourcetype><D:redirectref/></D:resourcetype>
      </D:prop>
   </D:response>
</D:multistatus>

In this example the Depth header is set to infinity, and the Passthrough 
header is not used.  The collection contains one URI that identifies a 
redirect reference.  The response element for the redirect reference has 
a status of 302 (Moved Temporarily), and includes a DAV:prop element 
with the DAV:location and DAV:resourcetype properties to allow clients 
to retrieve the properties of its target resource.  (The response 
element for the redirect reference does not include the requested 
properties.  The client can submit another PROPFIND request to the URI 
in the DAV:location property to retrieve those properties.) 

Slein et al.                                                    Page 20

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999


4.3.2.2 Example: PROPFIND with Passthrough: F on a Collection with 
Redirect References

Suppose a PROPFIND request with Passthrough = F and Depth = infinity is 
submitted to the following collection, with the members shown here:

/MyCollection/
   (ordinary resource) diary.html
   (redirect reference) nunavut

>> Request:

PROPFIND /MyCollection/ HTTP/1.1
Host: www.svr.com
Depth: infinity
Passthrough: F
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:">
   <D:prop>
      <D:resourcetype/>
      <D:reftarget/>
   </D:prop>
</D:propfind>

>> Response:

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

<?xml version="1.0" ?>
<D:multistatus xmlns:D="DAV:">
   <D:response>
      <D:href>http://www.svr.com/MyCollection/</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype><D:collection/></D:resourcetype>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
      <D:propstat>
         <D:prop> <D:reftarget/> </D:prop>
         <D:status>HTTP/1.1 404 Not Found</D:status>
      </D:propstat>
   </D:response>
<D:response>
      <D:href>http://www.svr.com/MyCollection/diary.html</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype/>
         </D:prop>

Slein et al.                                                    Page 21

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
      <D:propstat>
         <D:prop> <D:reftarget/> </D:prop>
         <D:status>HTTP/1.1 404 Not Found</D:status>
      </D:propstat>
   </D:response>
   <D:response>
      <D:href>http://www.svr.com/MyCollection/nunavut</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype><D:redirectref/></D:resourcetype>
            <D:reftarget>
               <D:href>http://www.inac.gc.ca/art/inuit/</D:href>
            </D:reftarget>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
   </D:response>
</D:multistatus>

Since the Passthrough header has the value "F", the response shows the 
properties of the redirect reference in the collection rather than the 
properties of its target. The value of the Passthrough header also 
prevents a 302 response from being returned for the redirect reference.

4.3.3 Copying Redirect References

A client's intent in performing a COPY operation is to create a new 
resource that is similar to the original resource and behaves like the 
original resource, and that can be modified without affecting the 
original resource.  For a COPY request to a redirect reference, the 
expectation would be a 302 response that the client could use to copy 
the target resource.  This would yield an independent resource that 
could be modified without affecting the original resource.  For COPY 
requests to collections that contain redirect references, the situation 
is less clear.  There is tension between two expectations. On the one 
hand, the client may expect the new copy of the collection to behave 
like the old one (which implies having references where the old one had 
references).  On the other hand, the client may expect that it will be 
possible to modify the resources in the new collection without affecting 
the resources in the old collection (which implies having copies of the 
targets where the original collection had references).

For a COPY request on an individual reference, the response MUST be a 
302 (Moved Temporarily) status code, with the URI of the target resource 
in the Location header, and "Resource-Type: DAV:redirectref" to 
distinguish the response from an ordinary HTTP redirect.  This is the 
normal behavior for redirect references, allowing the client to resubmit 
the request to the target resource identified in the Location header.  
This also yields intuitively correct behavior for a COPY request to an 
individual reference.  Reference-aware clients can use the Passthrough 
header with the value "F" to copy the redirect reference itself.

For COPY on a collection containing redirect references, different 

Slein et al.                                                    Page 22

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

semantics may be desirable in different scenarios.  Consequently, this 
specification makes a fairly arbitrary choice to take the simplest path.  
When a COPY request is submitted to a collection containing redirect 
references, the server MUST copy the redirect references to the new 
collection rather than returning 302 status codes for them.  This will 
result in a new collection that behaves like the old one, and avoids 
responding with multiple 302 status codes, each of which the client 
would have to process separately.  Reference-aware clients can force the 
server to respond with 302 status codes rather than copying the 
references by using the Passthrough header with the value "T".

4.3.3.1 Example: COPY on a Redirect Reference

>> Request:

COPY /MyCollection/tuva HTTP/1.1
Host: www.svr.com
Destination: http://www.svr.com/OtherCollection/tuva.html

>> Response:

HTTP/1.1 302 Moved Temporarily
Location: http://www.svr.com/Asia/History/tuva.html
Resource-Type: DAV:redirectref

In this example, the request-URI identifies a redirect reference whose 
target resource is identified by 
http://www.svr.com/Asia/History/tuva.html.  In this case, the server 
responded with a 302, and provided the URL of the target resource in the 
Location header.  The Resource-Type header indicates to a reference-
aware client that this is not an HTTP 1.1 redirect, but a reference to 
the resource identified by the Location header.  The client can now 
resubmit the COPY request to the target resource, producing the desired 
result: a duplicate of the original target resource that can be modified 
independently of the original.

4.3.3.2 Example: COPY on a Collection That Contains a Redirect Reference

Suppose a COPY request is submitted to the following collection, with 
the members shown:

/MyCollection/
     (ordinary resource) diary.html
     (redirect reference) nunavut with target /Someplace/nunavut.map

>> Request:

COPY /MyCollection/ HTTP/1.1
Host: www.svr.com
Destination: http://www.svr.com/OtherCollection/

>> Response:

HTTP/1.1 201 Created


Slein et al.                                                    Page 23

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

In this case, since /MyCollection/nunavut is a redirect reference, the 
reference itself, and not its target, was copied into the new 
collection.  So the resulting collection is as follows:

/OtherCollection/
      (ordinary resource) diary.html
      (redirect reference) nunavut with target /Someplace/nunavut.map

4.3.4 Deleting and Moving Redirect References

The DELETE method is used to delete bindings to redirect references. 
DELETE MUST affect bindings to the reference itself, unless 
"Passthrough: T" is used, in which case it generates a 302 (Moved 
Temporarily) response.  Similarly, when a DELETE on a collection 
encounters a redirect reference in the subtree under that collection, it 
MUST delete bindings to the reference, unless "Passthrough: T" is used, 
in which case it generates a 302 (Moved Temporarily) response. Whether 
deleting an individual resource or a collection, DELETE on a redirect 
reference does not affect the target of the reference.

A MOVE operation on a redirect reference MUST move the reference to a 
different location, and MUST NOT change the location of its target, 
unless "Passthrough: T" is used, in which case a 302 (Moved Temporarily) 
response is generated. The DAV:reftarget property is unchanged after a 
MOVE.  Similarly, when a MOVE on a collection encounters a redirect 
reference in the subtree under that collection, it MUST move the 
reference, and not its target, unless "Passthrough: T" is used, in which 
case a 302 (Moved Temporarily) response is generated.

DELETE and MOVE differ from other methods in that they do not alter the 
resource that is being deleted or moved, but rather the collection that 
contains its binding.  They change the membership of that collection.

When a redirect reference is added to a collection, the aim is to make 
it look as if the target resource were a member of that collection.  
When the reference is removed from that collection, the aim is to change 
the membership of that collection.  Membership of the target in any 
other collections, either internally or by reference, should not be 
affected.  Consequently, DELETE and MOVE do not follow the normal rules 
of behavior for references.  Instead, they are applied by default to the 
reference itself, not to its target, and by default do not result in 302 
status codes.

4.3.5 Locking Redirect References

The semantics of LOCK described here resulted from balancing a set of 
incompatible considerations:

o Ideally, a LOCK on a redirect reference should lock both the 
  reference and its target resource.  The owner of an exclusive write 
  lock, for example, would be surprised if anyone else could modify the 
  content of the target resource while he held the lock.  He would also 
  be surprised if anyone else could delete the reference to it, or 
  replace the reference with one pointing to a different target.
o Non-referencing clients should be able to use redirect references 

Slein et al.                                                    Page 24

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

  without encountering surprising results.
o The basic characteristics of redirect references should be honored.  
  Redirect references should be simple for servers to implement. In 
  particular, a server should never have to resolve a redirect 
  reference.  A server should not have to provide proxy capabilities in 
  order to implement redirect references.
o There should be consistency between the behavior of LOCK on a single 
  redirect reference and the behavior of LOCK on a collection that 
  contains redirect references.
o The behavior of all requests to redirect references should be as 
  consistent as possible. In the absence of a Passthrough header, all 
  methods should return a 302 when sent to a redirect reference.
o LOCK semantics for redirect references should be consistent with the 
  LOCK semantics defined in [WebDAV].

We have compromised the intuitive locking behavior and support for non-
referencing clients in order to preserve various sorts of consistency. 

4.3.6 LOCK on Redirect References

The behavior of LOCK for redirect references was determined by what is 
possible for the case of locking collections that contain redirect 
references.  

The default behavior for any operation on a redirect reference is that a 
302 (Moved Temporarily) response will be returned, unless the 
Passthrough header with a value of "F" is used.  However, this policy 
has unacceptable consequences when locking a collection that contains 
redirect references.  Since [WebDAV] requires LOCK on a collection to be 
an atomic operation, if a 302 response is received for any member of the 
collection, the entire LOCK must fail.  This would make it impossible to 
lock any collection that contained a redirect reference. 

To avoid this result, a LOCK with Depth > 0 on a collection MUST lock 
any redirect references it encounters, and not return 302 responses for 
them, unless the Passthrough header with a value of "T" is used.  Use of 
the Passthrough header with a value of "T" in a LOCK request on a 
collection will cause the entire lock to fail if a redirect reference is 
encountered.

This gives part of the expected default lock behavior without forcing 
the server to resolve the redirect reference or become a proxy server in 
cases where the target resides on a different server. 

There will be no hint in any response code that there are redirect 
references whose targets need to be locked.  The client will most likely 
not lock any targets until it attempts an operation on the target and 
gets a 302 response.  It is possible that a non-referencing client may 
never realize that the reference's target has not been locked.  

Clearly, a LOCK with Depth = infinity on a collection MUST NOT follow 
any redirect references whose targets are collections into the target 
collections; it MUST NOT cause any resources in those target collections 
to be locked.


Slein et al.                                                    Page 25

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

The behavior of LOCK for individual redirect references is designed to 
be consistent with LOCK behavior for collections that contain redirect 
references.  By default a LOCK on a redirect reference MUST lock only 
the reference, not its target, and it MUST NOT return a 302 response.  A 
reference-aware client can use the Passthrough header with a value of 
"T" to get a 302 response with the URI of the target resource in the 
Location header.

UNLOCK behaves as specified in [WebDAV], unlocking all resources 
included in the lock identified by the Lock-Token header.

4.3.6.1 Example: LOCK on a Redirect Reference

>> Request:

LOCK /MyCollection/tuva HTTP/1.1
Host: www.svr.com
Content-Type: text/xml
Content-Length: nnnn
Authorizaton: Digest username="jas",
   realm=jas@webdav.sb.aol.com, nonce=". . . ",
   uri="/MyCollection/tuva",
   response=". . . ", opaque=". . . "

<?xml version="1.0" ?>
<D:lockinfo xmlns:D="DAV:">
   <D:lockscope><D:exclusive/></D:lockscope>
   <D:locktype><D:write/></D:locktype>
   <D:owner>
      <D:href>http://www.svr.com/~jas/contact.html</D:href>
   </D:owner>
</D:lockinfo>

>> Response:

HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: nnnn

<?xml version="1.0" ?>
<D:prop xmlns:D="DAV:">
   <D:lockdiscovery>
      <D:activelock>
         <D:lockscope><D:exclusive/></D:lockscope>
         <D:locktype><D:write/></D:locktype>
         <D:depth>0</D:depth>
         <D:owner>
            <D:href>http://www.svr.com/~jas/contact.html</D:href>
         </D:owner>
         <D:locktoken>
            opaquelocktoken:e71dfae-5dec-22d6-fea5-00a0c91e6be4
         </D:locktoken>
      </D:activelock>
   </D:lockdiscovery>
</D:prop>

Slein et al.                                                    Page 26

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999


The request and response look exactly as specified in [WebDAV].  In this 
example, the request-URI, http://www.svr.com/MyCollection/tuva,  
identifies a redirect reference, which was successfully locked.  The 
target resource of the redirect reference is not locked.

4.3.6.2 Example: LOCK on a Collection That Contains a Redirect 
Reference, with Passthrough: T

Suppose a LOCK request is submitted to the following collection, with 
the members shown:

/MyCollection/
     (ordinary resource) diary.html
     (redirect reference) nunavut

>> Request:

LOCK /MyCollection/ HTTP/1.1
Host: www.svr.com
Passthrough: T
Content-Type: text/xml
Content-Length: nnnn
Authorizaton: Digest username="jas",
   realm=jas@webdav.sb.aol.com, nonce=". . . ",
   uri="/MyCollection/tuva",
   response=". . . ", opaque=". . . "

<?xml version="1.0" ?>
<D:lockinfo xmlns:D="DAV:">
   <D:lockscope><D:exclusive/></D:lockscope>
   <D:locktype><D:write/></D:locktype>
   <D:owner>
      <D:href>http://www.svr.com/~jas/contact.html</D:href>
   </D:owner>
</D:lockinfo>

>> Response:

HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: nnnn

<?xml version="1.0" ?>
<D:multistatus xmlns:D="Dav:">
   <D:response>
      <D:href>http://www.svr.com/MyCollection/</D:href>
      <D:propstat>
         <D:prop><D:lockdiscovery/></D:prop>
         <D:status>HTTP/1.1 424 Failed Dependency</D:status>
      </D:propstat>
   </D:response>
   <D:response>
      <D:href>http://www.svr.com/MyCollection/diary.html</D:href>
      <D:status>HTTP/1.1 424 Failed Dependency</D:status>

Slein et al.                                                    Page 27

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

   </D:response>
   <D:response>
      <D:href>http://www.svr.com/MyCollection/nunavut</D:href>
      <D:status>HTTP/1.1 302 Moved Temporarily</D:status>
      <D:prop>
         <D:location>
            <D:href>http://www.inac.gc.ca/art/inuit/</D:href>
         </D:location>
         <D:resourcetype><D:redirectref/></D:resourcetype>
      </D:prop>
   </D:response>
</D:multistatus>

The "Passthrough: T" header caused the server to return a 302 response 
code for the redirect reference in the collection.  Consequently, 
neither the collection nor any of the resources identified by its 
internal member URIs were locked.  A referencing-aware client can submit 
a separate LOCK request to the URI in the DAV:location property returned 
for the redirect reference, and can resubmit the LOCK request with 
"Passthrough: F" to the collection.  At that point both the reference 
and its target will be locked (as well as the collection and all the 
resources identified by its other members).

4.3.7 Other Operations on Redirect References

Although non-referencing-aware clients cannot create referential 
resources, they should be able to use the references created by 
reference-aware WebDAV clients.  They should be able to follow any 
references to their targets.  To make this possible, a server that 
receives a GET, HEAD, PUT, POST, OPTIONS, PROPFIND, PROPPATCH, MKCOL, 
MKREF, BIND, or ORDERPATCH request made via a redirect reference MUST 
return a 302 (Moved Temporarily) status code. 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 absolute target URI of 
  the reference.  

o The response MUST include the Resource-Type header.  This header 
  allows reference-aware WebDAV clients to recognize the resource as a 
  reference and understand the reason for the redirection. 

A reference-aware WebDAV client can act on this response in one of two 
ways.  It can, like a non-referencing client, resubmit the request to 
the URI in the Location header in order to operate on the target 
resource.  Alternatively, it can resubmit the request to the URI of the 
redirect reference with the Passthrough header set to "F" in order to 
operate on the reference itself.  If the Passthrough header is present 
with a value of "F", the request MUST be applied to the reference 
itself, and a 302 response MUST NOT be returned.

If a reference-aware client knows before submitting its request that the 
request-URI identifies a redirect reference, and if the client wants to 
apply the method to the reference, it can save the round trip caused by 
the 302 response by using "Passthrough: F" in its initial request to the 

Slein et al.                                                    Page 28

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

URI.

"Passthrough: F" can be used with GET or HEAD to retrieve the entity 
headers of a redirect reference.  When "Passthrough: F" is used with GET 
or HEAD, the referencing entity headers (Ref-Type and Ref-Target) MUST 
be returned, along with all HTTP headers that make sense for references 
(at a minimum, Cache-Control, Age, ETag, Expires, and Last-Modified).  

"Passthrough: F" can be used with PUT to replace the redirect reference 
with an ordinary resource.  It can be used with OPTIONS to retrieve the 
capabilities of a redirect reference.  

Clients MUST NOT, however, use "Passthrough: F" with POST. Since a 
reference cannot accept another entity as its subordinate, an attempt to 
POST to a reference with "Passthrough: F" will also fail.  If a server 
receives a POST request with "Passthrough: F" on a redirect reference, 
it MUST fail the request with a 400 (Bad Request) status code.

Since MKCOL fails when applied to existing resources, if the client 
attempts to resubmit the request to the target resource, the request 
MUST fail (unless the reference is a dangling reference).  Similarly, if 
the client attempts to resubmit the request to the reference with 
"Passthrough: F", the request MUST fail.

Since ORDERPATCH applies only to collections, an ORDERPATCH request with 
a Passthrough header with the value "F" on a redirect reference MUST 
fail.

4.3.7.1 Example: GET on a Redirect Reference

>> Request:

GET /bar.html HTTP/1.1
Host: www.foo.com 

>> Response:

HTTP/1.1 302 Moved Temporarily
Location: http://www.svr.com/Internet/xxspec08.html
Resource-Type: DAV:redirectref

Since /bar.html is a redirect reference and the Passthrough header is 
not included in the request, the response is a 302 (Moved Temporarily).  
The Resource-Type header informs a reference-aware client that this is 
not an ordinary HTTP 1.1 redirect, but is a redirect reference.  The URI 
of the target resource is provided in the Location header so that the 
client can resubmit the request to the target resource.

4.3.7.2 Example: PUT on a Redirect Reference with "Passthrough: F"

>> Request:

PUT /bar.html HTTP/1.1 
Host: www.foo.com
Passthrough: F 

Slein et al.                                                    Page 29

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

Content-Type: text/xml; charset="utf-8" 
Content-Length: xxxx

. . . some content . . .

>> Response:

HTTP/1.1 200 OK 

Although /bar.html is a redirect reference, the presence of the 
"Passthrough: F" header prevents a 302 response, and instead causes the 
request to be applied to the reference.  The result in this case is that 
the reference is replaced by an ordinary resource having the content 
submitted with the request.

4.3.7.3 Example: PROPPATCH on a Redirect Reference

Request:

PROPPATCH /bar.html HTTP/1.1 
Host: www.foo.com 
Content-Type: text/xml; charset="utf-8" 
Content-Length: xxxx 

   <?xml version="1.0" encoding="utf-8" ?>
   <D:propertyupdate xmlns:D="DAV:"
   xmlns:Z="http://www.w3.com/standards/z39.50/">
     <D:set>
          <D:prop>
               <Z:authors>
                    <Z:Author>Jim Whitehead</Z:Author>
                    <Z:Author>Roy Fielding</Z:Author>
               </Z:authors>
          </D:prop>
     </D:set>
     <D:remove>
          <D:prop><Z:Copyright-Owner/></D:prop>
     </D:remove>
   </D:propertyupdate>

Response:

HTTP/1.1 302 Moved Temporarily
Location: http://www.svr.com/Internet/xxspec08.html
Resource-Type: DAV:redirectref

Since /bar.html is a redirect reference and the Passthrough header is 
not included in the request, the response is a 302 (Moved Temporarily).  
The Resource-Type header informs a reference-aware client that this is 
not an ordinary HTTP 1.1 redirect, but is a redirect reference.  The URI 
of the target resource is provided in the Location header so that the 
client can resubmit the request to the target resource.

4.3.8 Operations on Targets of Redirect References


Slein et al.                                                    Page 30

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

Operations on targets of redirect references have no effect on the 
reference. 

4.3.9 Relative URIs in Ref-Target and DAV:reftarget

The URI in a Ref-Target header MAY be a relative URI.  Similarly, the 
href in a DAV:reftarget property MAY be a relative URI.  In both cases, 
the base URI to be used for resolving the relative URI to absolute form 
is the URI used in the HTTP message to identify the redirect reference 
to which the Ref-Target entity header or DAV:reftarget property belongs.  

In the case of a Ref-Target header, the base URI is constructed as 
follows: Its scheme component is "http", its authority component is the 
value of the Host header in the request, and its path component is the 
request-URI in the request.  See Section 5 of [URI] for a discussion of 
relative URI references and how to resolve them.

The DAV:reftarget property appears in the protocol in the context of a 
Multi-Status response, in a DAV:response element that contains a single 
DAV:href element.  The value of this DAV:href element serves as the base 
URI for resolving a relative URI in DAV:reftarget.  The value of 
DAV:href may itself be relative, in which case it must be resolved first 
in order to serve as the base URI for the relative URI in DAV:reftarget.  
If the DAV:href element is relative, its base URI is constructed from 
the scheme component "http", the value of the Host header in the 
request, and the request-URI.

4.3.9.1 Example: Resolving a Relative URI in Ref-Target

>> Request:

MKREF /north/inuvik HTTP/1.1
Host: www.somehost.edu
Ref-Target: mapcollection/inuvik.gif

>> Response:

HTTP/1.1 201 Created

In this example, the base URI is http://www.somehost.edu/north/inuvik.  
Then, following the rules in [URI] Section 5, the relative URI in Ref-
Target resolves to the absolute URI 
http://www.somehost.edu/north/mapcollection/inuvik.gif. 

4.3.9.2 Example: Resolving a Relative URI in DAV:reftarget

>> Request:

PROPFIND /geog/ HTTP/1.1
Host: www.xxsvr.com
Passthrough: F
Depth: 1
Content-Type: text/xml
Content-Length: nnn


Slein et al.                                                    Page 31

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

<?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:">
   <D:prop>
      <D:resourcetype/>
      <D:reftarget/>
   </D:prop>
</D:propfind>

>> Response:

HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: nnn

<?xml version="1/0" ?>
<D:multistatus xmlns:D="DAV:">
   <D:response>
      <D:href>/geog/</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype><D:collection/></D:resourcetype>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
     </D:propstat>
     <D:propstat>
         <D:prop><D:reftarget/></D:prop>
         <D:status>HTTP/1.1 404 Not Found</D:status>
     </D:propstat>
   </D:response>
   <D:response>
      <D:href>/geog/stats.html</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype><D:redirectref/></D:resourcetype>
            <D:reftarget>statistics/population/1997.html</D:reftarget>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
   </D:response>
</D:multistatus>

In this example, the relative URI statistics/population/1997.html is 
returned as the value of reftarget for the reference identified by href 
/geog/stats.html.  The href is itself a relative URI, which resolves to 
http://www.xxsrv.com/geog/stats.html.  This is the base URI for 
resolving the relative URI in reftarget.  The absolute URI of reftarget 
is http://www.xxsrv.com/geog/statistics/population/1997.html.

4.3.10 Redirect References to Collections

In a Request-URI /segment1/segment2/segment3, any of the three segments 
may identify a redirect reference.  (See [URI], Section 3.3, for 
definitions of "path" and "segment".)  If any segment in a Request-URI 
identifies a redirect reference, the response is a 302.  The value of 
the Location header in the 302 response is as follows: 

Slein et al.                                                    Page 32

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999


The leftmost path segment of the request-URI that identifies a redirect 
reference, together with all path segments and separators to the left of 
it, is replaced by the value of the redirect reference's
DAV:reftarget property (resolved to an absolute URI).  The remainder of 
the request-URI is concatenated to this path.  

Note: If the DAV:reftarget property ends with a "/" and the remainder of 
the Request-URI is non-empty (and therefore must begin with a "/"), the 
final "/" in the DAV:reftarget property is dropped before the remainder 
of the Request-URI is appended.

Consider Request-URI /x/y/z.html.  Suppose that /x/ is a redirect 
reference whose target is collection /a/, which contains redirect 
reference y whose target is collection /b/, which contains redirect 
reference z.html whose target is /c/d.html.

/x/ -----> /a/
           /a/y/ -----> /b/
                        /b/z.html -----> /c/d.html

In this case the client must follow up three separate 302 responses 
before finally reaching the target resource.  The server responds to the 
initial request with a 302 with Location: /a/y/z.html, and the client 
resubmits the request to /a/y/z.html.  The server responds to this 
request with a 302 with Location: /b/z.html, and the client resubmits 
the request to /b/z.html.  The server responds to this request with a 
302 with Location: /c/d.html, and the client resubmits the request to 
/c/d.html.  This final request succeeds.

5 Ordered Collections

5.1 Overview

Collections on a compliant server may be ordered, but need not be.  It 
is up to the client to decide whether a given collection is ordered and, 
if so, to specify the semantics to be used for ordering its bindings.  
If a collection is ordered, each of its bindings, and hence internal 
member URIs, MUST be in the ordering exactly once, and the ordering MUST 
NOT include any binding that is not contained by the collection.  Only 
one ordering can be attached to any collection. An ordering is 
considered to be part of the state of a collection resource, and hence 
is the same across all URI mappings to the 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 binding (and its derived internal member URI) 
from the ordering when it is removed from the collection. The server 
MUST add a binding (and its derived internal member URI) 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. 

Slein et al.                                                    Page 33

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

If the collection is unordered, the client cannot depend on the 
repeatability of the ordering of results from a PROPFIND request.

Orderings may be client-maintained or server-maintained.  This protocol 
provides support for both types of orderings.

5.2 Creating an Ordered Collection

5.2.1 Overview 

When a collection is created, the client MAY request that it be ordered 
and specify the semantics of the ordering by using the new Ordered 
header (defined in Section 6.5) with a MKCOL request.   

For collections that are ordered, the client SHOULD identify the 
semantics of the ordering with a URI in the Ordered header.  This URI 
may identify a server-maintained ordering.  Clients can discover the 
available server-maintained orderings using the mechanism defined in 
Section 11.3.  The URI may identify a semantics for a client-maintained 
ordering, providing the information a human user or software package 
needs to insert new collection members into the ordering intelligently.  
Although the URI in the Ordered header MAY point to a resource that 
contains a definition of the semantics of the ordering, clients are 
discouraged from accessing that resource, in order to avoid 
overburdening its server.  The client MAY set the header value to 
DAV:custom to indicate that the collection is ordered, but the semantics 
of the ordering are not being advertised.  If the client does not want 
the collection to be ordered, it may omit the Ordered header, or use it 
with the value DAV:unordered.

If the server does not recognize the value of the Ordered header as one 
of its server-maintained orderings, it MUST assume that a client-
maintained ordering is intended.  If the value of the Ordered header is 
one of the server-maintained orderings that the server supports, it MUST 
maintain the collection's ordering according to that ordering semantics 
as new members are added.

Every collection MUST have a DAV:orderingtype property (defined in 
Section 7.5), which indicates whether the collection is ordered and, if 
so, identifies the semantics of the ordering.  The server sets the 
initial value of this property based on the value of the Ordering header 
in the MKCOL request. If the collection is unordered, the 
DAV:orderingtype property MUST have the value DAV:unordered. An 
ordering-aware client interacting with an ordering-unaware server (e.g., 
one that is implemented only according to [WebDAV]) SHOULD assume that 
if a collection does not have the DAV:orderingtype property, the 
collection is unordered.

5.2.2 Example: Creating an Ordered Collection

>>Request:

MKCOL /theNorth/ HTTP/1.1
Host: www.server.org
Ordered: http://www.server.org/orderings/compass.html

Slein et al.                                                    Page 34

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999


>>Response:

HTTP/1.1 201 Created

In this example a new, ordered collection was created.  Its 
DAV:orderingtype property has as its value the URI from the Ordered 
header, http://www.server.org/orderings/compass.html.  In this case, the 
URI identifies the semantics governing a client-maintained ordering.  As 
new members are added to the collection, clients or end users can use 
the semantics to determine where to position the new members in the 
ordering. 

5.3 Setting the Position of a Collection Member

5.3.1 Overview

When a new member is added to a collection with a client-maintained 
ordering (for example, with PUT, MKREF, or MKCOL), its position in the 
ordering can be set with the new Position header (defined in Section 
6.6).  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, immediately before some other binding in the collection's 
ordering, or immediately after some other binding in the collection's 
ordering.

5.3.2 Status Codes

409 (Conflict): The request specifies a position that is before or after 
a URI that is not an internal member URI of the collection, or before or 
after itself.

425 (Unordered Collection): The request specifies a collection position 
in an unordered collection or in a collection with a server-maintained 
ordering.

5.3.3 Examples: Setting the Position of a Collection Member

>>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 requirements.html.


Slein et al.                                                    Page 35

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

>>Request:

MOVE /i-d/draft-webdav-protocol-08.txt HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/~whitehead/dav/draft-webdav-
     protocol-08.txt
Position: First

>>Response:

HTTP/1.1 425 Unordered Collection

In this case, the server returned a 425 (Unordered Collection) status 
code because the /~whitehead/dav/ collection is an unordered collection.  
Consequently, the server was unable to satisfy the Position header.

5.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 (defined in Section 7.5).  If the new value 
identifies a client-maintained ordering, the client is then responsible 
for updating the collection's ordering according to the new semantics.  
If it identifies a server-maintained ordering, the server MUST reorder 
the collection according to the new semantics.  PROPPATCH is defined in 
[WebDAV], Section 7.2.

5.5 Changing the Position of a Collection Member

5.5.1 ORDERPATCH Method

The ORDERPATCH method alters the ordering of bindings in the collection 
identified by the Request-URI, based on instructions in the order XML 
element. The order XML element identifies the bindings whose positions 
are to be changed, and describes their new positions in the ordering.  
Each new position can be specified as first in the ordering, last in the 
ordering, immediately before some other binding, or immediately after 
some other binding.  

The server MUST apply the changes in the order they appear in the order 
XML element.  The server MUST either apply all the changes or apply none 
of them.  If any error occurs during processing, all executed changes 
MUST be undone and a proper error result returned.

5.5.2 Status Codes

Since multiple changes can be requested in a single ORDERPATCH request, 
the server MUST return a 207 (Multi-Status) response, as defined in 
[WebDAV].

The following are examples of response codes one would expect to be used 
in a 207 (Multi-Status) response for this method: 

200 (OK): The change in ordering was successfully made.

Slein et al.                                                    Page 36

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999


409 (Conflict): The request specifies a position that is before or after 
a URI that is not an internal member URI of the collection, or before or 
after itself.

425 (Unordered Collection): The request specifies a collection position 
in an unordered collection or in a collection with a server-maintained 
ordering.

A request to reposition a binding at the same place in the ordering is 
not an error. 

5.5.3 Example: Changing Positions in an Ordered Collection

Consider a collection /coll-1/ with bindings ordered as follows:

nunavut.map
nunavut.img
baffin.map
baffin.desc
baffin.img
iqaluit.map
nunavut.desc
iqaluit.img
iqaluit.desc

>> Request:

ORDERPATCH /coll-1/ HTTP/1.1
Host: www.nunanet.com
Content-Type: text/xml
Content-Length: xxx

<?xml version="1.0" ?>
<d:order xmlns:d="DAV:">
   <d:ordermember>
      <d:href>nunavut.desc</d:href>
      <d:position> 
         <d:after>
            <d:href>nunavut.map</d:href>
         </d:after>
      </d:position>
   </d:ordermember>
   <d:ordermember>
      <d:href>iqaluit.img</d:href>
      <d:position>
         <d:last/>
      </d:position>
   </d:ordermember>
</d:order>

>> Response:

HTTP/1.1 207 Multi-Status
Content-Type: text/xml

Slein et al.                                                    Page 37

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

Content-Length: xxx

<?xml version="1.0" ?>
<d:multistatus xmlns:d="DAV:">
   <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:response>
      <d:href>http://www.nunanet.com/coll-1/iqaluit.img</d:href>
      <d:status>HTTP/1.1 200 OK</d:status>
   </d:response>
</d:multistatus>

If the href elements are relative URIs, as in this example, they are 
interpreted relative to the collection that is being reordered.  In this 
example, after the request has been processed, the collection's ordering 
is as follows:

nunavut.map
nunavut.desc
nunavut.img
baffin.map
baffin.desc
baffin.img
iqaluit.map
iqaluit.desc
iqaluit.img

5.5.4 Example: Failure of an ORDERPATCH Request

Consider a collection /coll-1/ with bindings ordered as follows:

nunavut.map
nunavut.img
baffin.map
baffin.desc
baffin.img
iqaluit.map
nunavut.desc
iqaluit.img
iqaluit.desc

>> Request:

ORDERPATCH /coll-1/ HTTP/1.1
Host: www.nunanet.com
Content-Type: text/xml
Content-Length: xxx

<?xml version="1.0" ?>
<d:order xmlns:d="DAV:">
   <d:ordermember>
      <d:href>nunavut.desc</d:href>
      <d:position> 

Slein et al.                                                    Page 38

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

         <d:after>
            <d:href>nunavut.map</d:href>
         </d:after>
      </d:position>
   </d:ordermember>
   <d:ordermember>
      <d:href>iqaluit.map</d:href>
      <d:position>
         <d:after>
            <d:href>pangnirtung.img</d:href>
         </d:after>
      </d:position>
   </d:ordermember>
</d:order>

>> Response:

HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxx

<?xml version="1.0" ?>
<d:multistatus xmlns:d="DAV:">
   <d:response>
      <d:href>http://www.nunanet.com/coll-1/nunavut.desc</d:href>
      <d:status>HTTP/1.1 424 Failed Dependency</d:status>
   </d:response>
   <d:response>
      <d:href>http://www.nunanet.com/coll-1/iqaluit.map</d:href>
      <d:status>HTTP/1.1 409 Conflict</d:status>
      <d:responsedescription>pangnirtung.img is not a collection   
                member.</d:responsedescription>
   </d:response>
</d:multistatus>

In this example, the client attempted to position iqaluit.map after a 
binding that is not contained in the collection /coll-1/.  The server 
responded to this client error with a 409 (Conflict) status code.  
Because ORDERPATCH is an atomic method, the request to reposition 
nunavut.desc (which would otherwise have succeeded) failed with a 424 
(Failed Dependency) status code.

6 Headers

6.1 All-Bindings Request Header

All-Bindings = "All-Bindings" ":"

The All-Bindings request header may be used with DELETE requests to 
instruct the server to remove all bindings to the resource identified by 
the Request-URI.

6.2 Ref-Target Entity Header

Ref-Target = "Ref-Target" ":" (absoluteURI | relativeURI)

Slein et al.                                                    Page 39

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999


The Ref-Target header is defined primarily for use with MKREF requests 
to identify the target resource of the new redirect reference being 
created. 

6.3 Resource-Type Entity Header

Resource-Type = "Resource-Type" ":" ("DAV:redirectref" | 
                                      ext-resource-type)
ext-resource-type = coded-URL 

The Resource-Type header is defined primarily for use in 302 responses, 
to allow reference-aware clients to distinguish between HTTP 1.1 
redirects and 302 responses for redirect references (see Sections 4.1, 
and 4.3.7).  The possible values of this header are DAV:redirectref, and 
ext-resource-type. The ext-resource-type production is provided for 
extensibility.  

6.4 Passthrough Request Header

Passthrough = "Passthrough" ":" ("T" | "F")

The optional Passthrough header can be used on any request to a redirect 
reference.  If the Passthrough header has the value "F", the request 
MUST be applied to the reference itself, and a 302 response MUST NOT be 
returned.  If the Passthrough header has the value "T", a 302 response 
MUST be returned, with the URI of the target resource in the Location 
header and the Resource-Type header with a value "DAV:redirectref".  

If the Passthrough header is used on a request to any other sort of 
resource besides a reference, the server SHOULD ignore it.  If the 
Passthrough header with the value "F" appears in a POST or ORDERPATCH 
request to a reference, the server MUST respond with a 400 (Bad 
Request).

6.5 Ordered Entity Header

Ordered = "Ordered" ":" ("DAV:unordered" | "DAV:custom" | absoluteURI)

The Ordered header may be used with MKCOL to request that the new 
collection be ordered and to specify its ordering semantics.  A value of 
"DAV:unordered" indicates that the collection is not ordered. A value of 
"DAV:custom" indicates that the collection is to be ordered, but the 
semantics of the ordering is not being advertised.  Any other 
absoluteURI value indicates that the collection is ordered, and 
identifies the semantics of the ordering. 

6.6 Position Request Header

Position = "Position" ":" ("First" | "Last" | 
                           (("Before" | "After") Generic-Coded-url))
Generic-Coded-url = "<" (absoluteURI | relativeURI) ">"
absoluteURI and relativeURI are defined in [URI].

The Position header may be used with any method that adds a binding to a 

Slein et al.                                                    Page 40

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

collection with a client-maintained ordering, to tell the server where 
in the collection ordering to position the new binding being added to 
the collection. 

If the Generic-Coded-url is a relative URL, it is interpreted relative 
to the collection to which the new binding is being added. 

The server MUST insert the new binding into the ordering at the location 
specified in the Position header, if one is present (and if the 
collection has a client-maintained ordering). 

The "First" keyword indicates the new binding is put in the beginning 
position in the collection's ordering, while "Last" indicates the new 
binding is put in the final position in the collection's ordering.  The 
"Before" keyword indicates the new binding is added to the collection's 
ordering immediately prior to the position of the binding identified in 
the Generic-Coded-url. Likewise, the "After" keyword indicates the new 
binding is added to the collection's ordering immediately following the 
position of the binding identified in the Generic-Coded-url.

If the request is replacing an existing resource, and the Position 
header is present, the server MUST remove the binding from its previous 
position, and then insert it at the requested position.

If the Position request header is not used when adding a binding to a 
collection with a client-maintained ordering, then:

o If the request is replacing an existing resource, the server MUST 
  preserve the present ordering.

o If the request is adding a new binding to the collection, the server 
  MUST append the new binding to the end of the ordering.

If an attempt is made to use the Position header on a collection that is 
unordered or that has a server-maintained ordering, the server MUST fail 
the request with a 409 (Conflict) status code.

7 Status Codes

7.1 506 Loop Detected

The 506 (Loop Detected) status code indicates that the server detected 
an infinite loop while processing a request with "Depth: infinity". 

7.2 425 Unordered Collection

The 425 (Unordered Collection) status code indicates that the client 
attempted to set the position of an internal collection member in an 
unordered collection or in a collection with a server-maintained 
ordering.

8 Properties

8.1 reftarget Property


Slein et al.                                                    Page 41

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

Name:	    reftarget
Namespace:  DAV:
Purpose:    A property of redirect references that provides an efficient 
            way for clients to discover the URI of the target resource.  
            This is a read-only property, whose value can only be set by 
            using the Ref-Target header with a MKREF request.
Value: 	    URI of the target resource.  This value MAY be a relative 
            URI.  The reftarget property can occur in the entity bodies 
            of responses to PROPFIND requests.

<!ELEMENT reftarget (#PCDATA)>

8.2 location Property

Name:       location
Namespace:  DAV:
Purpose:    For use with 302 (Moved Temporarily) response codes in 
            Multi-Status responses.  It contains the absolute URI of the 
            temporary location of the resource.  In the context of 
            redirect references, this value is the absolute URI of the 
            target resource.  It is analogous to the Location header in 
            HTTP 302 responses defined in [HTTP] Section 10.3.3 "302 
            Moved Temporarily."  Including the location property in a 
            Multi-Status response requires an extension to the syntax of 
            the DAV:response element defined in [WebDAV], which is 
            defined in Section 9 below.  This property is not expected 
            to be stored on the reference. It is modeled as a property 
            only so that it can be returned inside a DAV:prop element in 
            a Multi-Status response.
Value:      href containing the absolute URI of the target resource.

<!ELEMENT location href >

8.3 bindings Property

Name:	    bindings
Namespace:  DAV:
Purpose:    Enables clients to discover, for any resource, what bindings 
            point to it and what collections contain those bindings.  
            This is an optional property.  If present, it is a read-only 
            property, maintained by the server.
Value:	    List of href / segment pairs for all of the bindings that 
            associate URI segments with the resource.  The href is an 
            absolute URI for one URI mapping of the collection 
            containing the binding.  The segment is the URI segment that 
            identifies the binding within that collection. If a binding 
            belongs to a collection that has multiple URI mappings, only 
            one URI mapping for that collection should be reported.

<!ELEMENT bindings ((href, segment)*)>

8.4 orderingtype Property

Name:	    orderingtype
Namespace:  DAV:

Slein et al.                                                    Page 42

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

Purpose:    Indicates whether the collection is ordered and, if so, 
            uniquely identifies the semantics of the ordering being 
            used.  May also point to an explanation of the semantics in 
            human and / or machine-readable form.  At a minimum, this 
            allows human users who add members to the collection to 
            understand where to position them in the ordering.
Value:	    unordered for an unordered collection, or a URI that 
            uniquely identifies the semantics of the collection's 
            ordering.  The value custom indicates that the collection is 
            ordered, but the semantics are not being advertised. 

<!ELEMENT orderingtype (unordered | custom | href) >

9 XML Elements

9.1 redirectref XML Element

Name: 	    redirectref
Namespace:  DAV:
Purpose:    Used as the value of the DAV:resourcetype property to   
            specify that the resource type is a redirect reference.  

<!ELEMENT redirectref EMPTY >

9.2 segment XML Element

Name:	    segment
Namespace:  DAV:
Purpose:    The segment that names a binding, used in the DAV:bindings 
            property.
Value:	    segment  ; as defined in section 3.3 of [URI].

<!ELEMENT segment (#PCDATA)>

9.3 unordered XML Element

Name:	    unordered
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.

<!ELEMENT unordered EMPTY >

9.4 custom XML Element

Name: 	    custom
Namespace:  DAV:
Purpose:    A value of the DAV:orderingtype property that indicates that 
            the collection is ordered, but the semantics of the ordering 
            are not being advertised. 

<!ELEMENT custom EMPTY >


Slein et al.                                                    Page 43

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

9.5 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 positions of the bindings a 
            collection contains in its ordering.

<!ELEMENT order (ordermember+) >

9.6 ordermember XML Element
 
Name: 	    ordermember
Namespace:  DAV:
Purpose:    Occurs in the order XML Element, and describes the new 
            position of a single binding in the collection's ordering.
Value: 	    An href containing a binding's path segment, and a 
            description of its new position in the ordering.  The href 
            XML element is defined in [WebDAV], Section 11.3.

<!ELEMENT ordermember (href, position) >

9.7 position XML Element

Name: 	    position
Namespace:  DAV:
Purpose:    Occurs in the ordermember XML element.  Describes the new 
            position in a collection's ordering of one of the bindings 
            it contains.
Value: 	    The new position can be described as first in the 
            collection's ordering, last in the collection's ordering, 
            immediately before some other binding, or immediately after 
            some other binding.

<!ELEMENT position (first | last | before | after)>

9.8 first XML Element

Name: 	    first
Namespace:  DAV:
Purpose:    Occurs in the position XML element.  Specifies that the 
            binding should be placed first in the collection's ordering.

<!ELEMENT first EMPTY >

9.9 last XML Element

Name: 	    last
Namespace:  DAV:
Purpose:    Occurs in the position XML element.  Specifies that the 
            binding should be placed last in the collection's ordering.

<!ELEMENT last EMPTY >


Slein et al.                                                    Page 44

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

9.10 before XML Element

Name: 	    before
Namespace:  DAV:
Purpose:    Occurs in the position XML element.  Specifies that the 
            binding should be placed immediately before the binding in 
            the enclosed href XML element in the collection's ordering.
Value: 	    href of the member it precedes in the ordering

<!ELEMENT before href >

9.11 after XML Element

Name: 	    after
Namespace:  DAV:
Purpose:    Occurs in the position XML element.  Specifies that the 
            binding should be placed immediately after the binding in 
            the enclosed href XML element in the collection's ordering.
Value:      href of the member it follows in the ordering

<!ELEMENT after href >

9.12 options XML Element

Name:       options
Namespace:  DAV:
Purpose:    Used in OPTIONS requests to ask for more detailed     
            information about capabilities than can be provided in the  
            DAV: response header.  Used in OPTIONS responses to provide
            that information.
Value:      List of elements identifying or providing the additional 
            information desired.

<!ELEMENT options (orderingoptions | ANY)+ >

9.13 orderingoptions XML Element

Name:       orderingoptions
Namespace:  DAV:
Purpose:    Used in OPTIONS requests to ask for the list of server-    
            maintained orderings that can be supported at the request-
            URI.  Used in OPTIONS responses to provide that information.  
            These values can be used in the Ordered header or the 
            DAV:orderingtype property to request that a particular  
            server-maintained ordering be applied to the collection.
Value:      EMPTY on requests.  On responses, it is the list of server-
            maintained orderings available for the request-URI.

<!ELEMENT orderingoptions ( (#PCDATA)+ | EMPTY) >

10 Extensions to the DAV:response XML Element for Multi-Status Responses

As described in Sections 4.6 and 4.9, the DAV:location property and the 
DAV:reftype property may be returned in the DAV:response element of a 
207 Multi-Status response, to allow clients to resubmit their requests 

Slein et al.                                                    Page 45

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

to the target resource of a redirect reference.  

Whenever these properties are included in a Multi-Status response, they 
are placed in a DAV:prop element associated with the href to which they 
apply.  This structure provides a framework for future extensions by 
other standards that may need to include additional properties in their 
responses.

Consequently, the definition of the DAV:response XML element changes to 
the following:

<!ELEMENT response (href, ((href*, status, prop?) | (propstat+)), 
responsedescription?) >

11 Capability Discovery

11.1 Compliance Classes

This specification defines OPTIONAL extensions to [WebDAV].  Since 
resource sharing and ordering are independent capabilities, a resource 
MAY support either, both, or neither of these capabilities.  A resource 
that provides resource sharing MUST support both bindings and redirect 
references.  A response to an OPTIONS request MUST indicate which of 
these capabilities the resource supports.

This specification defines three new methods: BIND and MKREF in support 
of shared resources, and ORDERPATCH in support of ordering.  The 
response MUST indicate which of these methods the resource allows.  In 
addition, the response MUST include the DAV header, as described in 
Sections 9.1 and 15 of [WebDAV].  Two new compliance classes are defined 
here for use with the DAV header: sharing and orderedcoll. 

When responding to an OPTIONS request, only a collection or a null 
resource can include orderedcoll in the value of the DAV header.  By 
including orderedcoll, the resource indicates that its bindings can be 
ordered.  It implies nothing about whether any collections identified by 
its internal member URIs can be ordered.

When responding to an OPTIONS request, any type of resource can include 
sharing in the value of the DAV header.  Including sharing indicates 
that the server permits a redirect reference or a binding at the request 
URI.

11.2 Example: Discovery of Compliance Classes

>> Request:

OPTIONS /somecollection/ HTTP/1.1
HOST: somehost.org

>> Response:

HTTP/1.1 200 OK
Date: Tue, 20 Jan 1998 20:52:29 GMT
Connection: close

Slein et al.                                                    Page 46

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

Accept-Ranges: none
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, 
PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, ORDERPATCH
Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, 
PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKREF, ORDERPATCH
DAV: 1, 2, sharing, orderedcoll

The DAV header in the response indicates that the resource 
/somecollection/ is level 1 and level 2 compliant, as defined in 
[WebDAV].  In addition, /somecollection/ supports ordering and resource 
sharing.  The Allow header indicates that BIND and ORDERPATCH requests 
can be submitted to /somecollection/.  Since a redirect reference is not 
a collection, a MKREF request with /somecollection/ as its Request-URI 
would fail, but the Public header shows that other Request-URIs on the 
server do support MKREF.

11.3 Additional Advanced Collections Capabilities

Clients may need detailed information about specific areas of advanced 
collections functionality.  This information can be requested by sending 
an OPTIONS request with an XML body that includes a DAV:options element.  
The DAV:options element contains a list of empty elements identifying 
the information the client needs.

As described in Section 5.2, servers may offer a set of server-
maintained orderings on collections.  Clients can discover the list of 
server-maintained orderings available for the request-URI by including 
an empty DAV:orderingoptions element in the DAV:options element.  The 
response will include a DAV:orderingoptions element with the list of 
supported server-maintained orderings.  Servers SHOULD advertise the 
server-maintained orderings available using this mechanism.

11.4 Example: Discovery of Ordering Options

>> Request:

OPTIONS /somecollection/ HTTP/1.1
HOST: somehost.org

<?xml version="1.0" ?>
<D:options xmlns:D="DAV:">
  <D:orderingoptions/>
</D:options>

>> Response:

HTTP/1.1 200 OK
Date: Tue, 20 Jan 1998 20:52:29 GMT
Connection: close
Accept-Ranges: none
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, 
PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, ORDERPATCH
Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, 
PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKREF, ORDERPATCH
DAV: 1, sharing, orderedcoll

Slein et al.                                                    Page 47

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999


<?xml version="1.0" ?>
<D:options xmlns:D="DAV:">
  <D:orderingoptions xmlns:X="Xerox:">
      <X:author-ascending/>
      <X:title-ascending/>
      <X:date-descending/>
  </D:orderingoptions>
</D:options>

This response indicates that the resource /somecollection/ is level 1 
compliant, as defined in [WebDAV].  In addition, /somecollection/ 
supports ordering and resource sharing.  The client also asked for a 
list of the server-maintained orderings that are supported for 
/somecollection/.  The response indicates that the orderings 
Xerox:author-ascending, Xerox:title-ascending, and Xerox:date-descending 
are supported.

12 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 WebDAV 
Distributed Authoring Protocol specification also apply to WebDAV 
collections.  In addition, resource sharing and ordered collections 
introduce several new security concerns and increase the risk of some 
existing threats.  These issues are detailed below.

12.1 Privacy Concerns

By creating redirect references on a trusted server, it is possible for 
a hostile agent to induce users to send private information to a target 
on a different server.   This risk is mitigated somewhat, since clients 
are required to notify the user of the redirection for any request other 
than GET or HEAD. (See [HTTP], Section 10.3.3 Moved Temporarily.)

The same risk exists for bindings, although it is less likely that 
servers will support cross-server bindings.

12.2 Redirect Loops

Although redirect loops were already possible in HTTP 1.1, the 
introduction of the BIND and MKREF methods creates a new avenue for 
clients to create loops accidentally or maliciously.  If the binding or 
reference and its target are on the same server, the server may be able 
to detect MKREF and BIND requests that would create loops. See also 
[HTTP], Section 10.3 "Redirection 3xx."  Servers are required to detect 
loops caused by bindings to collections during the processing of any 
requests with "Depth: infinity".

12.3 Redirect References, Bindings, and Denial of Service

Denial of service attacks were already possible by posting URLs that 
were intended for limited use at heavily used Web sites.  The 

Slein et al.                                                    Page 48

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

introduction of BIND and MKREF creates a new avenue for similar denial 
of service attacks.  Clients can now create bindings and redirect 
references at heavily used sites to target locations that were not 
designed for heavy usage.

12.4 Private Locations May Be Revealed

There are several ways that redirect references may reveal information 
about directory structures.  First, the DAV:reftarget property of every 
redirect reference contains the URI of the target resource.  Anyone who 
has access to the reference can discover the directory path that leads 
to the target resource.   The owner of the target resource may have 
wanted to limit knowledge of this directory structure.

Sufficiently powerful access control mechanisms can control this risk to 
some extent.  Property-level access control could prevent users from 
examining the DAV:reftarget property.  (The Ref-Target and Location 
headers, which are returned in some responses to requests on redirect 
references, reveal the same information, however.)  In some 
environments, the owner of a resource might be able to use access 
control to prevent others from creating references to that resource.

In addition, if backpointers are maintained on the target resource, the 
owners of bindings face these same risks.  The directory structures 
where bindings are located are revealed to anyone who has access to the 
DAV:bindings property on a target resource.  Moving a binding may reveal 
its new location to anyone with access to DAV:bindings on its target 
resource.

12.5 DAV:bindings and Denial of Service

If the server maintains the DAV:bindings property in response to 
bindings created in other administrative domains, it is exposed to 
hostile attempts to make it devote resources to adding bindings to the 
list.

12.6 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.  In addition, 
Section 5.2 discourages clients from looking up the semantics at that 
location.

13 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 

Slein et al.                                                    Page 49

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

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].

14 IANA Considerations

This document uses the namespaces defined by [WebDAV] for properties and 
XML elements.  All other IANA considerations mentioned in [WebDAV] also 
apply to this document.

15 Copyright

To be supplied by the RFC Editor.

16 Intellectual Property

To be supplied by the RFC Editor.

17 Acknowledgements

This draft has benefited from thoughtful discussion by Jim Amsden, Steve 
Carter, Ken Coar, Ellis Cohen, Bruce Cragun, Spencer Dawkins, Mark Day, 
Rajiv Dulepet, David Durand, Roy Fielding, Yaron Goland, Fred Hitt, Alex 
Hopmann, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, 
Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra 
Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John 
Stracke, John Tigue, John Turner, and others.

18 References

18.1 Normative References

[URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 
Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine, 
Xerox. August, 1998.

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

[XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup 

Slein et al.                                                    Page 50

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

Language (XML)."  World Wide Web Consortium Recommendation REC-xml-
19980210. http://www.w3.org/TR/1998/REC-xml-19980210.

[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.

[WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D. 
Jensen, "HTTP Extensions for Distributed Authoring - WebDAV." RFC 2518.  
Microsoft, U.C. Irvine, Netscape, Novell.  February, 1999.

18.2 Informational References

[DASL] Saveen Reddy, D. Jensen, Surendra Reddy, R. Henderson, J. Davis, 
A. Babich, "DAV Searching & Locating." Draft-reddy-dasl-protocol-03. 
Internet Draft, work in progress. Microsoft, Novell, Oracle, Netscape, 
Xerox, Filenet.  November, 1998.
 
[CollReq] J. Slein, J. Davis, "Requirements for Advanced Collection 
Functionality in WebDAV." Draft-ietf-webdav-collection-reqts-02. 
Internet Draft, work in progress.  Xerox.  February, 1999.

19 Authors' Addresses

J. Slein
Xerox Corporation
800 Phillips Road, 105-50C
Webster, NY 14580
Email: jslein@crt.xerox.com

E. J. Whitehead, Jr.
Dept. of Information and Computer Science
University of California, Irvine
Irvine, CA 92697-3425
Email: ejw@ics.uci.edu

J. Davis
CourseNet Systems
170 Capp Street
San Francisco, CA 94110
Email: jrd3@alum.mit.edu

G. Clemm
Rational Software Corporation
20 Maguire Road
Lexington, MA 02173-3104
Email: gclemm@rational.com

C. Fay
FileNet Corporation
3565 Harbor Boulevard
Costa Mesa, CA 92626-1420
Email: cfay@filenet.com

J. Crawford

Slein et al.                                                    Page 51

INTERNET-DRAFT            WebDAV Collections Protocol         June 1999

IBM
Email: ccjason@us.ibm.com

T. Chihaya
DataChannel, Inc.
155 108th Ave. N.E., Suite 400
Bellevue, WA 98004
Email: Tyson@DataChannel.com

20 Appendices

20.1 Appendix 1: Extensions to the WebDAV Document Type Definition

<!--============= XML Elements from Section 8 ================-->
<!ELEMENT redirectref EMPTY >
<!ELEMENT segment (#PCDATA)>
<!ELEMENT unordered EMPTY >
<!ELEMENT custom EMPTY >
<!ELEMENT order (ordermember+) >
<!ELEMENT ordermember (href, position) >
<!ELEMENT position (first | last | before | after)>
<!ELEMENT first EMPTY >
<!ELEMENT last EMPTY >
<!ELEMENT before href >
<!ELEMENT after href >
<!ELEMENT options (refintegrityoptions | orderingoptions)+ >
<!ELEMENT orderingoptions ( (#PCDATA)+ | EMPTY) >
<!--============= Property Elements from Section 7 ==================-->
<!ELEMENT reftarget (#PCDATA)>
<!ELEMENT location href>
<!ELEMENT bindings ((href, segment)*)>
<!ELEMENT orderingtype (arbitrary | custom | href) >
<!--====== Changes to the DAV:response Element from Section 9 ====-->
<!ELEMENT response (href, ((href*, status, prop?) | (propstat+)), 
responsedescription?) >

Expires December 18, 1999

Slein et al.                                                    Page 52