WEBDAV Working Group                                     J. Slein, Xerox
INTERNET DRAFT                                           J. Davis, Xerox
<draft-ietf-webdav-collection-protocol-02>            A. Babich,
<draft-ietf-webdav-collection-protocol-03>       T. Chihaya, DataChannel
                                                      G. Clemm, Rational
                                                         C. Fay, FileNet
                                           E.J. Whitehead Jr., UC Irvine
                                                       November 10, 1998
                                                      A. Babich, FileNet
                                                       February 26, 1999
Expires May 10, August 26, 1999

			WebDAV Advanced Collections Protocol

Status of this Memo

This document is an Internet-Draft. 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 made obsolete 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".

To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Internet-Draft Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe),munnari.oz.au (Pacific Rim),
ftp.ietf.org (US EastCoast), or ftp.isi.edu (US West Coast). Directories, see
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://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth>.

Abstract

The base WebDAV protocol [WebDAV] provides basic support for
collections.  It defines a MKCOL method for creating collections and
specifies how other HTTP and WebDAV methods interact with collections.
It supports internal members of collections, which it defines as members
whose URIs
that are immediately relative to the URI of the collection.

Many applications, however, need more powerful collections.  There are
two areas in particular where more powerful functionality is often
needed: referential resources and ordering.

This draft specifies extensions to the base WebDAV protocol to support
these more powerful collections.

Table of Contents

1	Terminology ............................................... 3       Notational Conventions........................................4
2	Introduction .............................................. 4	Terminology...................................................4
3	Referential Resources ..................................... 4
3.1	Scope .....................................................	Introduction..................................................5
4
3.2	Overview .................................................. 5

3.3	Referential Resources.........................................5

4.1	Scope.........................................................5
4.2	Overview......................................................6
4.3	Creating Referential Resources ............................ 7
3.3.1 Resources................................8
4.3.1	The MKREF Method .......................................... 7
3.3.2 Method..............................................8
4.3.2	Status Codes .............................................. 8
3.3.3	Example	................................................... 8
3.4	Deleting, Copying, and Moving Referential Resources ....... 9
3.5 Codes..................................................9
4.3.3	Example: MKREF................................................9
4.4	Listing Referential Members of a Collection...................9
4.4.1	Example: PROPFIND on a Collection ............... 9
3.6 with References............10
4.4.2	Example: PROPFIND with No-Passthrough on a Collection with
        References...................................................12
4.5	Copying Referential Resources................................15
4.5.1	COPY for Direct References...................................15
4.5.2	COPY for Redirect References.................................16
4.5.3	Example: COPY on a Direct Reference..........................16
4.5.4	Example: COPY on a Redirect Reference........................16
4.5.5	Example: COPY on a Collection That Contains a Direct
        Reference and a Redirect Reference...........................17
4.6	Deleting and Moving Referential Resources....................18
4.7	Locking Referential Resources................................19
4.7.1	LOCK on Direct References....................................19
4.7.2	LOCK on Redirect References..................................20
4.7.3	Example: LOCK on a Direct Reference..........................21
4.7.4	Example: LOCK on a Redirect Reference........................22
4.7.5	Example: LOCK on a Collection That Contains a Direct
        Reference and a Redirect Reference...........................22
4.8	Other WebDAV Operations on Redirect Referential Resources . 9
3.7 Resources....24
4.8.1	Example: PROPPATCH on a Redirect Reference...................24
4.9	Other WebDAV Operations on Direct Referential Resources .. 10
3.8 Resources......24
4.9.1	Example: PROPPATCH on a Direct Reference.....................25
4.10	HTTP Operations on Redirect Referential Resources ........ 10
3.9 Resources............25
4.10.1	Example: GET on a Redirect Reference.........................26
4.10.2	Example: GET on a Redirect Reference with No-Passthrough.....26
4.11	HTTP Operations on Direct Referential Resources	.......... 11
3.10 Resources..............26
4.11.1	Example: GET on a Direct Reference...........................26
4.11.2	Example: GET on a Direct Reference with No-Passthrough.......26
4.12	Operations on Targets of Referential Resources ........... 12
3.11 Resources...............26
4.13	Discovering a Targetís References ........................ 12
3.12 References............................26
4.14	Behavior of Dangling Direct References ................... 13
3.13	Summary References.......................27
4.14.1	Example: PROPFIND on a Collection with a Dangling Direct
        Reference....................................................28
4.15	Chains of Referencing Headers Required in Responses ..... 16
4 Direct References..................................29
4.16	URIs and References..........................................29
5	Ordered Collections ...................................... 16
4.1	Overview ................................................. 16
4.2 Collections..........................................30
5.1	Overview.....................................................30
5.2	Creating an Ordered Collection ........................... 16
4.2.1	Overview ................................................. 16
4.2.2 Collection...............................31
5.2.1	Overview.....................................................31
5.2.2	Status Codes ............................................. 17
4.2.3	Example	.................................................. 17
4.3 Codes.................................................31
5.2.3	Example: Creating an Ordered Collection......................31
5.3	Setting the Position of a Collection Member .............. 17
4.3.1	Overview ................................................. 18
4.3.2 Member..................32
5.3.1	Overview.....................................................32
5.3.2	Status Codes ............................................. 18
4.3.3	Examples ................................................. 18
4.4 Codes.................................................32
5.3.3	Examples: Setting the Position of a Collection Member........32
5.4	Changing the Semantics of a Collection Ordering	.......... 19
4.5 Ordering..............33
5.5	Changing the Position of a Collection Member ............. 19
4.5.1 Member.................33
5.5.1	The ORDERPATCH Method .................................... 19
4.5.2 Method........................................33

5.5.2	Status Codes ............................................. 19
4.5.3	Example	.................................................. 19
4.5.4	Design Rationale ......................................... 21
5	New Headers .............................................. 21
5.1 Codes.................................................33
5.5.3	Example: Changing the Positions of Collection Members in
        the Ordering.................................................34
5.5.4	Design Rationale.............................................35
6	Headers......................................................35
6.1	Ref-Target Entity Header ................................. 21
5.2 Header.....................................35
6.1.1	Example: Resolving a Relative URI in Ref-Target..............36
6.2	Ref-Type Entity Header ................................... 22
5.3 Header.......................................37
6.3	Ref-Integrity Entity Header .............................. 22
5.4	Re-Direct Request Header ................................. 23
5.5	Hide-Target Entity Header ................................ 23
5.6	Resource-Type Entity Header .............................. 23
5.7 Header.................................37
6.4	No-Passthrough Request Header................................37
6.5	Ordered Entity Header .................................... 23
5.8 Header........................................38
6.6	Position Request Header	.................................. 24
5.9	DAV-Collections Entity Header ............................ 24
6	New Properties ........................................... 24
6.1 Header......................................38
7	Properties...................................................39
7.1	reftarget Property ....................................... 25
6.2 Property...........................................39
7.1.1	Example: Resolving a Relative URI in the DAV:reftarget.......39
7.2	refintegrity Property .................................... 25
6.3 Property........................................40
7.3	reftype Property ......................................... 25
6.4 Property.............................................41
7.4	location Property............................................41
7.5	references Property ...................................... 25
6.5 Property..........................................41
7.6	orderingtype Property .................................... 26
7	New Property........................................42
8	XML Elements ......................................... 26
7.1 Elements.................................................42
8.1	reference XML Element .................................... 26
7.2 Element........................................42
8.2	direct XML Element ....................................... 26
7.3 Element...........................................42
8.3	redirect XML Element ..................................... 26
7.4 Element.........................................42
8.4	weak XML Element ......................................... 26
7.5 Element.............................................43
8.5	unordered XML Element .................................... 27
7.6 Element........................................43
8.6	custom XML Element ....................................... 27
7.7 Element...........................................43
8.7	order XML Element ........................................ 27
7.8 Element............................................43
8.8	ordermember XML Element	.................................. 27

7.9 Element......................................43
8.9	position XML Element ..................................... 28
7.10 Element.........................................44
8.10	first XML Element ........................................ 28
7.11 Element............................................44
8.11	last XML Element ......................................... 28
7.12 Element.............................................44
8.12	before XML Element ....................................... 28
7.13 Element...........................................44
8.13	after XML Element ........................................ 28
8 Element............................................44
9	Extensions to the DAV:multistatus DAV:response XML Element ............ 29
9 for Multi-Status
        Responses....................................................45
10	Capability Discovery ..................................... 29
9.1 Discovery.........................................45
10.1	Using OPTIONS ............................................ 29
9.2	Example	.................................................. 29
10 OPTIONS................................................45
10.2	Example: Capability Discovery................................46
11	Dependencies on Other Specifications ..................... 30
11 Specifications.........................46
12	Security Considerations	.................................. 30
11.1 Considerations......................................46
12.1	Privacy Concerns.............................................46
12.2	Redirect Loops ........................................... 30
11.2 Loops...............................................47
12.3	References and Denial of Service ......................... 30
11.3	Maintaining Referential Integrity Service.............................47
12.4	References May Reveal Private Locations30
11.4 Locations......................47
12.5	DAV:references and Denial of Service ..................... 30
11.5 Service.........................48
12.6	DAV:references and Malicious Deletion of Resources ....... 31
11.6	Malicious Modifications of Ordering ...................... 31
11.7 Resources...........48
12.7	Denial of Service and DAV:orderingtype ................... 31
12	Internationalization Considerations ...................... 31 DAV:orderingtype.......................48
13	IANA Considerations ...................................... 31	Internationalization Considerations..........................48
14	Copyright ................................................ 32	IANA Considerations..........................................48
15	Intellectual Property .................................... 32	Copyright....................................................49
16	Acknowledgements ......................................... 32	Intellectual Property........................................49
17	References ............................................... 32	Acknowledgements.............................................49
18	Authors' Addresses ....................................... 32	References...................................................49
18.1	Normative References.........................................49

18.2	Informational References.....................................49
19	Appendices ............................................... 33
19.1	Authors' Addresses...........................................50
20	Appendices...................................................50
20.1	Appendix 1 - 1: Extensions to the WebDAV Document Type Definition33
        Definition...................................................50
20.2	Appendix 2: Summary of Referencing Headers Required in
        Responses....................................................51
20.3	Appendix 3: Summary of Method Semantics for References.......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.

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 base WebDAV
protocol specification [WebDAV].

Collection
     A resource that contains a set of URIs, termed member URIs, which
     identify member resources

Member Resource URI
     A resource URI which is a member of the set of URIs contained by a
     collection

Referential Resource (or Reference)
     A resource that has no content body of its own, own (though it does have
     properties), but rather is a reference to another resource

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

Target Resource
     The resource referenced by a referential resource

Direct Reference
     A reference that is resolved by the server, server without any client
     action, giving the client the illusion that it is operating
     directly on the target resource

Redirect Reference
     A reference that must requires client action before it can be resolved by resolved,
     so that the client is aware that a reference is mediating between
     it and the target resource

Strong Reference
     A reference whose referential integrity is guaranteed enforced by the server

Weak Reference
     A reference whose referential integrity is not guaranteed enforced by the
     server

Referential Integrity
     A server guarantees the
     The integrity of a reference if is preserved as long as it ensures
     that points to
     the reference will not same resource it pointed to when it was created.  Its
     integrity may be broken, or enables destroyed if the reference's
     owner to ensure that target resource is moved without
     updating the reference will not be broken.

2 to reflect its new location, or if the
     target resource is deleted.

3 Introduction

The simple collections that the base WebDAV 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 resources members to
them and deleting resources 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: references and ordering.

References make it possible for many collections, on the same or
different servers, to share the same resource.  Because the collections
share the resource by referencing it, only one physical copy of the
resource need exist, and any changes made in the resource are visible
from all the collections that reference it.

It is useful for many applications to be able to impose an ordering on a
collection. Orderings may be based on property values, but they may be
completely independent of any properties on the resources identified by
the collectionís member
resources. URIs.  Orderings based on properties can be
obtained using a search protocol [DASL], but orderings not based on
properties need some other mechanism.

Since these two areas are independent of each other, servers may elect
to comply with the Referential Resources section of this specification
or with the Ordered Collections section or both.  A server that supports
referencing MUST support redirect references, and MAY support direct
references.  A server MUST advertise its compliance with particular
parts of this specification through its response to an OPTIONS request,
as specified in Section 9 10 below.

3

4 Referential Resources

3.1

4.1 Scope

[WebDAVReq]

[CollReq] distinguishes between "weak" references and "strong"
references, and also between "redirect" references and "direct"

references.  This specification supports weak references, direct
references, and redirect references, and is designed so that it can be
extended to support strong references in the future.

Strong references are references whose integrity is guaranteed enforced by the
server; weak references are those whose integrity is not guaranteed. enforced by the
server.  Strong references and weak references are both useful in
different contexts.  Some applications cannot tolerate broken links.  A
software development application, for example, must be able to rely on
the integrity of references to component modules. Such applications must
be able to request strong references.  Other applications may want to
reference target resources on multiple servers, where referential
integrity cannot be guaranteed, enforced, and may be less concerned about possible
broken references.

Several considerations led to the decision not to support strong
references in the current specification.  First, there are many possible
policies that applications and services might use to enforce in enforcing
referential integrity.  Some examples are:

o Delete strong references when their targets are deleted.
o Decline to delete targets of strong references.
o Notify strong references when their targets have been deleted.
o Let owners of resources decide whether Replace strong references to them are
  allowed. with copies of their targets before
  deleting the targets.

There appears to be no common practice in this area.  Moreover, some of
the policies have significant security risks.

o Moving a target of strong references could be a security risk to the
  owner of the target by revealing secret locations on the target's
  server.
o A strong reference could be a security risk to the owner of the
  reference by revealing secret locations on his server.
o The presence of strong references to resources on a server could make
  it impossible to reclaim space on that server by moving or deleting
  those target resources.

These considerations together led to the decision not to support strong
references in the short term.

3.2

4.2 Overview

A referential resource is a resource that has no content body of its own, but
instead references another resource.  The resource it references may be
have a URI in the same collection as the reference, or in any other
collection.  This target resource may be a collection or a simple
resource or another reference, or any other sort of resource that may be
defined in the future.  A resource may be the target of any number of
referential resources.  To make it possible to distinguish references
from ordinary resources, a new value of the DAV:resourcetype property is
defined here.  The DAV:resourcetype property of all references MUST have
the value DAV:reference.

Redirect references are references that must be resolved require action by the client. client

before they can be resolved.  They are simple for servers to implement,
straightforward for clients to use, and have only limited security
implications.  Any server that complies with WebDAV referencing MUST
provide redirect references.

To resolve

If the client is aware that it is operating on a redirect reference, it
can resolve the client retrieves reference by retrieving the referenceís DAV:reftarget
property, whose value is the URI of the target resource.  Every
reference, direct or redirect, MUST have the DAV:reftarget property.  If
a client wishes  It can then
submit requests to operate on the target resource of resource.

Otherwise, the client submits a request to the redirect
reference, it resolves reference.  For
most operations, the reference, response is a 302 (Moved Temporarily), accompanied
by the Ref-Type header with the value "DAV:redirect" and then invokes the operation on Location
header with the URI of the target resource.  The redirect reference appears to the client as an independent resource
with its own properties.  Operations with can then
resubmit the request to the URI of the redirect
reference as their request-URI affect the reference, not its target resource.  A few
operations, 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.

Direct references, in contrast, are resolved automatically by the
server.  They give the client the illusion that it is operating directly
on the target resource.  These references are more complex for the
server to implement, and raise additional security issues.
Consequently, servers are not required to provide direct references in
order to be compliant with WebDAV referencing.

The default behavior of a direct reference is to apply most operations
directly to its target, so that the client is not aware that a reference
is mediating between it and the target resource.  The exceptions are
operations that affect membership in a collection rather than the state
of the target resource.  At present, the operations that fall into this
category are DELETE, MOVE, DELETE and COPY. MOVE.  These operations are applied to the
reference itself rather than to its target, so that only the collection
containing the reference is affected.

The Re-Direct No-Passthrough request header is also provided, to force an
operation to be applied to the direct reference itself rather than its target.  In
effect, it makes the reference behave like a redirect reference for that
request.
It can be used with most requests to direct or redirect references.
This header is particularly useful with PROPFIND, to allow clients to
view the referenceís own properties.

Ideally, non-referencing clients should be able to use both direct 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.

To distinguish between direct and redirect references, a new DAV:reftype
property is defined, with the values DAV:direct and DAV:redirect.  Every
reference MUST have the DAV:reftype property.  The DAV:reftype property
of a direct reference MUST have the value DAV:direct.  The DAV:reftype
property of a redirect reference MUST have the value DAV:redirect.

Every reference MUST have the DAV:reftarget property, whose value is the

URI of the referenceís target resource.

Although strong references are not currently supported, a new
DAV:refintegrity property is defined in anticipation of future support
for strong references.  DAV:refintegrity will allow clients to
distinguish between weak and strong references.  All references MUST
have this property.  Although the only value currently defined for
DAV:refintegrity is DAV:weak, other values may be defined in the future.

***** If a server wants future,
and servers MAY use extension values to enforce identify their policy for
enforcing referential integrity outside this
protocol, a value of DAV:weak is misleading.

3.3 for that resource.

4.3 Creating Referential Resources

3.3.1

4.3.1 The MKREF Method

Referential resources are created using the MKREF method.  The request-
URI of the MKREF request identifies the resource to be created.  The
required
REQUIRED Ref-Target header contains the URI of the target resource.

An optional OPTIONAL Ref-Integrity general request header is defined below, primarily for
future support for strong references.  The only value values currently defined
for this header is "DAV:weak", are "do-not-enforce" and "enforce", although other
values may be used by private agreement.  "DAV:weak" is  If a server receives the default value if the header is not
present.

***** Does Ref-Integrity = DAV:weak mean that the server need not
enforce referential integrity, or that
"do-not-enforce", it must not MUST NOT enforce referential integrity for the new resource?  We have
reference being created.  If a requirement that there be
some way to request the server not to receives the value "enforce", it
MUST enforce referential integrity for
a particular reference.  You might also want to change from donít-
enforce to enforce at different times in the life of the reference.

An optional Ref-Type general header is defined below, with values
"DAV:direct" and "DAV:redirect". The default value is "DAV:redirect" if the header is not present.

The optional Hide-Target request header is defined below, to enable the
creator of a direct reference being created, but
is free to specify that the DAV:reftarget property
be hidden from clients. follow any policy it chooses for enforcing referential
integrity.  If the Hide-Target Ref-Integrity header is not present, used with a MKREF
request, the server MUST assume that the DAV:reftarget property MAY enforce referential integrity, but is not
required to be hidden.
If the Hide-Target header is used with Ref-Type header set do so, and if it does enforce referential integrity, it may
do so according to
DAV:redirect, the any policy it likes.  Clients and servers MAY use
other values of Ref-Integrity by private agreement, but if a server
receives a value it does not understand, it MUST ignore fail the Hide-Target header.  The Ref-
Target request.

An OPTIONAL Ref-Type general header MUST never be returned in response to any request for a
direct reference created is defined below, with the Hide-Target header.

***** How useful values
"DAV:direct" and "DAV:redirect". The default value is this really? Isnít it the owner of the target (not
of the reference) who wants to control whether the location of "DAV:redirect" if
the
target header is hidden?  True, we have a scenario where the person creating
the reference wants to hide the location of the target, but thatís
because the owner of the reference and the owner of the target are the
same person in that example. not present.

An optional OPTIONAL Position request header supports ordered collections by
allowing the client creating a reference to specify where the new member
is to be placed in the collection's ordering.  (This header can also be
used with PUT any other method that adds a member to create an ordinary resource at a specific collection, to
specify its position in the collection ordering.)

When a server processes a MKREF request, it MUST set the
DAV:resourcetype property (defined in [WebDAV]) of the new resource to
be DAV:reference.

When a server processes a MKREF request, it MUST set the DAV:reftarget
property to the URI of the target resource.

When a server processes a MKREF request, it MUST set the
DAV:refintegrity property and the DAV:reftype
property based on the
values value of the Ref-Integrity and Ref-Type headers. header.

When a server processes a MKREF request, it MUST set the

DAV:refintegrity property to "DAV:weak" if it is not enforcing
referential integrity for the newly-created reference.  If it is
enforcing referential integrity for the new reference, it MAY set the
value of DAV:refintegrity to an extension value identifying its
enforcement policy.

The client MUST NOT send any content with the MKREF request, and so MUST
NOT use the Content-Length or Transfer-Encoding headers.  (See [HTTP].) [HTTP]
Section 4.3.)

If a MKREF request is submitted for has a request-URI that identifies an existing
resource, the existing
resource's content and headers will be overwritten. request MUST fail.  This behavior is analogous to the
behavior of the HTTP PUT method.  Live properties may
get new values at the server's discretion; dead properties will retain
their existing values.  If the Position header is absent in this case
and the collection is ordered, the server MUST leave the member at its
previous position in the collection ordering.  If the Position header is
present and the collection is ordered, the server MUST remove the member
from its previous position, and then insert it at the requested
position.

3.3.2 MKCOL method [WebDAV].

4.3.2 Status Codes

201 (Created): The reference was successfully created.

200 (OK): The reference was successfully created, replacing an existing
resource at

Servers MUST use the same location. HTTP/1.1 status codes as defined in [HTTP].  Some
likely client errors for MKREF include:

400 (Bad Request): The client attempted to send content with the
request, or set an invalid value for the Ref-Target, Ref-Integrity, Ref-
Type, or Position header.

405 (Method Not Allowed): A resource already exists at the request-URI.

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.

***** These are not conflicts with the state of the resource at the
request-URI, but conflicts with the state of the parent collection or
the target resource.  Is it still appropriate to use 409?

507 (Insufficient Storage): There is not enough space on the server to
complete the request.

3.3.3 Example

4.3.3 Example: MKREF

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> </i-d/draft-webdav-protocol-08.txt>

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.  Its DAV:resourcetype property is
set to DAV:reference.  Its DAV:reftarget property is set to the URI of
its target resource.  Its DAV:refintegrity property is set to the
default value
of DAV:weak. DAV:weak, indicating that the server will not enforce referential
integrity for the new reference.  Its DAV:reftype property is set to the
default value of DAV:redirect.

3.4 Deleting, Copying, and Moving

4.4 Listing Referential Resources

The DELETE method should be used to delete referential resources.  For
both direct and redirect references, DELETE affects the reference
itself, and not its target. Members of a Collection

A MOVE operation on URI of a referential resource moves the referential
resource to reference can be a different location, but has no effect on the location member of
its target. The DAV:reftarget property is unchanged after a MOVE unless collection just as the Ref-Target header is used to change it. URI of
an ordinary resource can.  A COPY operation on listing of members of a referential resource copies collection shows
all of the referential
resource, not its target resource, to another location. The
DAV:reftarget property of the destination resource is the same as the
DAV:reftarget of the source resource, unless the Ref-Target header is
used to change it.

3.5 Listing Referential Members of a Collection

Since a referential member of a collection is just a resource URIs in the collection, a listing of members of the collection shows referential
members along with whether they identify references or
ordinary members. resources.  That is, a WebDAV PROPFIND request on a collection
resource with Depth = 1 or infinity MUST return a response XML element
for each URI in the collection, whether it identifies an ordinary member and for each
resource or a referential
member. resource.

For a redirect each direct reference, the properties returned by the PROPFIND are MUST
be the properties of the reference itself.  If Depth = infinity in target resource unless the No-Passthrough
header is included with the PROPFIND request, request.

For each redirect reference, the server response element MUST NOT follow contain a 302
(Moved Temporarily) status code unless the No-Passthrough header is
included with the PROPFIND request.  The DAV:location and DAV:reftype
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 client can tell from the
DAV:reftype property that the collection contains a redirect references into
any collections reference.
The DAV:location property contains the absolute URI of the target
resource.  A referencing client can either use the DAV:location property
to which they may refer.

For a direct reference, retrieve the properties returned by of the target resource or can submit a
PROPFIND are to the redirect reference with the No-Passthrough header to
retrieve its properties.  The DAV:location property is expected to be
defined in a future revision of [WebDAV], at which time non-referencing
clients will also be able to use the response to retrieve the properties
of its the target resource.

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

If Depth = infinity in the PROPFIND request, the server MUST follow
direct references into any collections to which they may refer unless
the No-Passthrough header is used with the request.  That is, if the
target resource is a collection, the server MUST list the members of
that collection.  If the
Re-Direct

The No-Passthrough header is MAY be used with PROPFIND, the server MUST treat any direct
references like redirect references, as described in the previous
paragraph.

3.6 Other WebDAV Operations on Redirect Referential Resources

Operations on a redirect reference affect only the reference, and not
its target resource.

A LOCK operation PROPFIND request on a redirect reference locks the reference, not its

target.  A LOCK on the collection with Depth = 1 or infinity locks any
redirect references that are members of the
collection.  It does not
lock  If the targets of those redirect references.

A PROPPATCH on a redirect reference modifies No-Passthrough header is present, then the
properties of the
reference, not references in the properties of its target resource.

A PROPFIND on a collection MUST be returned, 302
(Moved Temporarily) status codes MUST NOT be returned for redirect reference returns the properties of the
reference, not the properties of its target resource.

3.7 Other WebDAV Operations on Direct Referential Resources

With the exception of DELETE, MOVE, and COPY, which were discussed
above, operations on
references, direct references affect MUST NOT pass the request through to their
target resource, not
the reference, unless the Re-Direct header is used.

Unless the Re-Direct header is used, a LOCK operation on a direct
reference locks resources, and the target.  A lock on a server MUST NOT follow direct reference references to a
collection locks the
collections into their target collection.  A lock collections.

4.4.1 Example: PROPFIND on a collection Collection with
Depth = 1 or infinity locks the targets of the direct references in the
collection.

Unless References

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

The target of http://www.svr.com/MyCollection/tuva is a collection:
http://www.feynman.com/tuva/
   (ordinary resource) history.html
   (ordinary resource) music.html

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/">
      <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>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></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/tuva</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype>collection</D:resourcetype>
            <J:keywords>history, music, throat-singing</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/tuva/history.html</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype></D:resourcetype>
            <J:keywords>history, language, culture</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/tuva/music.html</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype></D:resourcetype>
            <J:keywords>music, throat-singing</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:reftype>redirect</D:reftype>
      </D:prop>
   </D:response>
</D:multistatus>

In this example, Depth = infinity and the Re-Direct No-Passthrough header is used, a PROPPATCH on not
used.  The collection contains one URI that identifies a direct redirect
reference.  The response element for the redirect reference
modifies has a status
of 302 (Moved Temporarily), and includes a DAV:prop element with the
DAV:location and DAV:reftype properties of its target resource, not to allow clients to retrieve the
properties of
the reference itself.

Unless the Re-Direct header is used, a PROPFIND on its target resource.  The collection also contains one URI
that identifies a direct reference.  The response element for the direct
reference
returns contains the properties of its target resource, not the properties collection.  There are
also response elements for each member of the
reference itself.

If the Re-Direct header is used with a LOCK, PROPPATCH, or its target collection.

4.4.2 Example: PROPFIND
request on a direct reference, it behaves as if it were being applied to
a redirect reference, as specified in Section 3.6.

3.8 HTTP Operations with No-Passthrough on Redirect Referential Resources

Although existing HTTP clients cannot create referential resources, they
should be able to read collections created by reference-aware WebDAV
clients.  They should be able to follow any references in those
collections to their targets.  To make this possible, a server that
receives a GET or HEAD on a redirect reference MUST return a 302(Moved
Temporarily) status code.  The server MUST follow [HTTP] Section 10.3.3
"302 Moved Temporarily," but Collection with these additional rules:

o The Location
References

/MyCollection/
   (collection) photos/
      (ordinary resource) family.gif
      (ordinary resource) trip.gif
   (ordinary resource) diary.html
   (direct reference) tuva
   (redirect reference) nunavut

Request:

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

<?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:">
   <D:prop>
      <D:resourcetype/>
      <D:reftype/>
      <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>collection</D:resourcetype>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
      <D:propstat>
         <D:prop> <D:reftype/> <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/photos/</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype>collection</D:resourcetype>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
      <D:propstat>
         <D:prop> <D:reftype/> <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/photos/family.gif</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype></D:resourcetype>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
      <D:propstat>
         <D:prop> <D:reftype/> <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/photos/trip.gif</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype></D:resourcetype>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
      <D:propstat>
         <D:prop> <D:reftype/> <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:resourcetype>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
      <D:propstat>
         <D:prop> <D:reftype/> <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/tuva</D:href>
      <D:propstat>
         <D:prop>
            <D:resourcetype>reference</D:resourcetype>
            <D:reftype>direct</D:reftype>
            <D:reftarget>
               <D:href>http://www.feynman.com/tuva/</D:href>
            </D:reftarget>
         </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:propstat>
         <D:prop>
            <D:resourcetype>reference</D:resourcetype>
            <D:reftype>redirect</D:reftype>
            <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 No-Passthrough header MUST contain is present, the response shows the
properties of the references in the collection rather than the
properties of their targets.  Even though Depth = infinity, the No-
Passthrough header prevents the server from listing the members of the
collection that is the target URI of the direct reference.

o The response MUST include all referencing entity headers that make
  sense for redirect references: Ref-Type, Ref-Target, and Ref-
  Integrity.

o The response MUST  No-Passthrough
also include those HTTP headers that make sense for
  referential resources, at prevents a minimum: Cache-Control, Age, ETag,
  Expires, and Last-Modified.

The second and third of these rules preserve normal GET and HEAD

behavior 302 response from being returned for reference-aware WebDAV clients.

POST cannot be applied to a the redirect
reference.  A reference cannot
accept another entity as its subordinate.  Depending upon

4.5 Copying Referential Resources

In determining the nature semantics of COPY, the target resource, however, it might make sense desire to apply POST to the
target. provide intuitively
correct behavior was weighed against consistency considerations.

A server that receives a POST request on clientís intent in performing a redirect reference
MUST return COPY operation is to create a 302 (Moved Temporarily).  The rules for constructing and
using new
resource that is similar to the response are original resource and behaves like the same as for GET
original resource, and HEAD, except that there can be modified without affecting the
original resource.  For references to ordinary resources, the
expectation would be that the target resource be copied.  This would
yield an independent resource that could be modified without affecting
the original resource.  For collections the situation is no requirement less clear.
There is tension between two expectations. On the one hand, the client
may expect the new copy of the collection to return any headers behave like the old one
(which implies having references where the old one had references).  On
the other than Ref-Type. This header
allows reference-aware WebDAV clients hand, the client may expect that it will be possible to recognize modify
the resource as a
reference and understand members of the reason new collection without affecting the members of the
old collection (which implies having copies of the targets where the
original collection had references).

4.5.1 COPY for Direct References

COPY follows the redirection.

PUT cannot be general principle that operations on direct references
are applied to the target resource unless the No-Passthrough header is
used.  A COPY on a redirect reference.  To replace one redirect direct reference with another, MKREF MUST be applied to its target
resource unless the No-Passthrough header is used.  To replace a redirect
reference with an ordinary resource,  If the reference MUST first be deleted
with DELREF, after which a PUT No-
Passthrough header is used, then the COPY MUST be used applied to create the ordinary
resource.

Existing HTTP clients that do not understand referential resources need
to be accommodated, however.  To enable these clients direct
reference rather than to operate
reasonably on redirect references, a server that receives its target.

For consistency, the same is true when a PUT COPY request
on a redirect reference MUST return is sent to a 302 (Moved Temporarily).  The
client
collection, and server MUST follow [HTTP] Section 10.3.3 "302 Moved
Temporarily," but with these additional rules:

o The Location response direct references are encountered inside the collection.
Unless the No-Passthrough header MUST contain is present on the target URI request, the targets
of the
  reference.

o The response direct references MUST include be copied into the Ref-Type header.  This new collection.  If the
No-Passthrough header allows
  reference-aware WebDAV clients to recognize is used, then the resource as a
  reference direct references, and understand the reason for the redirection.

o The response not their
targets, MUST include be copied into the new collection.

These semantics yield intuitively correct results when a COPY request is

sent to an entity body for display individual reference.  It is less clear that the results are
intuitive when a COPY request is sent to users.  The
  entity body explains a collection containing direct
references, but consistency dictates that we follow the requested resource same semantics
for this case.  A design principle that is followed throughout this
specification is that a method behaves the same when it is sent to the
URI of a reference as it does when it is sent to
  another resource, a the URI of a
collection and allows encounters a reference inside that collection.

4.5.2 COPY for Redirect References

For redirect references, the user normal behavior would be to choose whether respond to a
request with a 302 (Moved Temporarily) status code, allowing the client
to resubmit the request to replace the target resource or to replace identified in the reference.
Location header.  This last rule is needed for PUT, but not for GET, HEAD, or POST.  Only would also yield intuitively correct behavior for PUT does
COPY.  However, it make sense for the user to confirm that the operation is
to be performed at the request-URI.  GET or HEAD will already have
returned all useful information about the request-URI.  POST makes no
sense for the redirect reference at the request-URI.  But the user might
really want seems undesirable to replace the redirect reference with the entity in the PUT
request.

To enable existing HTTP clients respond to retrieve the capabilities of the
target resource, a server that receives an OPTIONS COPY request on a redirect
reference MUST return
collection with a Multi-Status including a 302 (Moved Temporarily).  At the same time,
reference-aware WebDAV clients may need to retrieve the capabilities response for each
redirect reference.  To avoid this sort of response, the following rules
apply when COPY is sent to redirect references:

A COPY on a redirect reference itself.  Consequently, the server MUST provide a choice as
to whether the method should be applied to the reference itself,
whether or its target.
Consequently, not the No-Passthrough header is present.

The same rules apply for OPTIONS as for PUT above.

3.9 HTTP Operations on Direct Referential Resources

GET, HEAD, PUT, POST, is true when a COPY request is sent to a collection, and OPTIONS on direct
redirect references are passed
through to their target resources.  GET returns encountered inside the content and headers
of collection.  Whether or
not the target resource, HEAD returns No-Passthrough header is present on the headers of request, the target resource,
PUT replaces redirect
references themselves are copied into the content of new collection, and 302 status
codes are not returned for them.

4.5.3 Example: COPY on a Direct Reference

Request:

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

Response:

HTTP/1.1 204 No Content
Ref-Type: direct
Ref-Target: /Asia/History/tuva.html

In this example, the request-URI identifies a direct reference whose
target resource, POST performs the
expected function at the resource is identified by
http://www.svr.com/Asia/History/tuva.html.  This target resource, and OPTIONS reports resource was
copied to the
communication options available at destination location in the target resource. Destination header,
http://www.svr.com/OtherCollection/tuva.html.  The Re-Direct request header may be used headers included with GET, HEAD, or OPTIONS to
view
the headers or capabilities of response insure that the client knows that it was operating on a
direct reference, rather than its
target.  If the Re-Direct header is used, and that the methodís behavior is as
described in Section 3.8.

The Re-Direct request header must not be used with PUT or POST, client knows which
cannot be applied to references.  If a server receives a PUT or POST
request resource was copied.

4.5.4 Example: COPY on a direct reference with 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 204 No Content
Ref-Type: redirect
Ref-Target: /Asia/History/tuva.html

In this example, the Re-Direct header, it MUST respond
with request-URI identifies a 400 (Bad Request).

***** Confirm behavior for PUT / POST with Re-Direct.

3.10 Operations on Targets of Referential Resources redirect reference whose
target resource is identified by
http://www.svr.com/Asia/History/tuva.html.  In general, operations on targets of weak referential resources have no
effect on the referential resource.  However, servers that choose to
maintain this case, the integrity of references are free to make changes reference
was copied to the
state of references when moving or deleting their targets.

When moving a target resource, a server MAY insert an optional step into
the semantics of MOVE as defined destination location in [WebDAV] for the purpose of
maintaining referential integrity.  Between Destination header,
http://www.svr.com/OtherCollection/tuva.html.  The Ref-Type header
included with the copy step and response informs the delete
step of client that it was operating on a MOVE,
redirect reference.  The Ref-Target header provides the server MAY perform an update step, which changes information the
DAV:reftarget property of any references
client needs to copy the target resource, should it wish to reflect its
new location.

When deleting a target resource, a server MAY perform any internal
operations necessary to implement its policy on preserving referential
integrity.  For example, it might delete any references to do so.

The result would have been exactly the deleted
target, or it might flag them as having a deleted target, or it might
replace references with copies of same, and the target.

3.11 Discovering a Targetís References

An optional DAV:references property on response would have
been exactly the target resource provides a
list of referential resources whose DAV:reftarget property points to same (except that target resource.  If present, DAV:references is a read-only
property, maintained by the server.  By retrieving this property, a
client can discover Ref-Target header would be
OPTIONAL), had the URIs of No-Passthrough header been used in the request.

4.5.5 Example: COPY on a Collection That Contains a Direct Reference and
a Redirect Reference

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

Request:

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

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>tuva</D:href>
      <D:status>HTTP/1.1 201 Created</D:status>
      <D:prop>
         <D:reftype>direct</D:reftype>
         <D:reftarget>
            <D:href>http://www.feynman.com/tuva/</D:href>
         </D:reftarget>
      </D:prop>
   </D:response>
   <D:response>
      <D:href>nunavut</D:href>
      <D:status>HTTP/1.1 201 Created</D:status>
      <D:prop>
         <D:reftype>redirect</D:reftype>
         <D:reftarget>
            <D:href>http://www.inac.gc.ca/art/inuit/</D:href>
         </D:reftarget>
      </D:prop>
   </D:response>
</D:multistatus>

When references that point are involved, it is not possible to follow the target,
and so can also discover rules in
[WebDAV] Section 8.8.3 for reducing the collections length of which those URIs are
members.  As for all DAV: properties, this specification is silent as responses to
how COPY
requests.  Although the DAV:references property is implemented on entire COPY operation in the server.

The DAV:references property example was
successful, a Multi-Status response is expected to be supported mainly by
Document Management Systems (DMSs) and other servers still REQUIRED, so that will maintain the property only
DAV:reftype and DAV:reftarget properties can be returned for the
references within their own domain.  It is not in
general possible for a server to maintain the property collection.  The results for references on
other servers.  If each reference MUST be
reported in a separate DAV:response element so that it is clear which
reference on is associated with which values of DAV:reftype and
DAV:reftarget.  In this case, since /MyCollection/tuva is a different server points to direct
reference, its target resource was copied into the new collection.
Since /MyCollection/nunavut is a redirect reference, the reference
itself, and not its target, was copied into the server where new collection.  There
are no response elements for the target is located is unlikely to know about
that reference.  This protocol provides collection /MyCollection/ or for the
ordinary resource /MyCollection/diary.html, since they were successfully
copied and no mechanism special information needs to be returned for one server them.

4.6 Deleting and Moving Referential Resources

The DELETE method is used to
notify another of delete referential resources.  For both
direct and redirect references, DELETE MUST affect the creation of a reference to one of itself,
and not its resources.
Consequently, the list of references target.  Similarly, when a DELETE on a collection encounters
a reference in DAV:reftarget may be incomplete.

Rationale: the subtree under that collection, it MUST delete the
reference, and not its target.

A number of scenarios require clients to navigate from MOVE operation on a
target referential resource to MUST move the references that point referential
resource to it, a different location, and to MUST NOT change the
collections that contain those references.  This capability location of
its target. The DAV:reftarget property is
particularly important for DMSs, which may populate their collections
entirely by reference.  Their clients may need to determine, for any
object unchanged after a MOVE.
Similarly, when a MOVE on a collection encounters a reference in the DMS, what collections
subtree under that collection, it belongs to.  It is also important
in MUST move the reference, and not its
target.

DELETE and MOVE differ from other contexts.  For example, some servers enforce referential
integrity by refusing to delete any methods in that they do not alter the
resource that is referenced by other
resources.  In such an environment, the client must be able to discover being deleted or moved, but rather the references in order to delete them before attempting to delete collection that
contains its URI.  They change the
target.

Once membership of that collection.

When a search capability [DASL] reference is available, it may be possible for a
client to discover the references that point added to a given target by
searching for resources with DAV:reftarget equal to the URI of the
target resource.  However, it will be much more efficient for collection, the client aim is to retrieve a list of references from make it look as
if the target resource.

***** Only if DASL provides search of structured properties or we define
DAV:reftarget as resource were a string value, not an href.

Risks: member of that collection.  When deciding whether to support the DAV:references property,
server implementors / administrators should balance
reference is removed from that collection, the efficiencies it
provides in discovering references against aim is to change the cost
membership of that collection.  Membership of maintaining the
property and the security risks enumerated target in Sections 11.4 any other
collections, either internally or by reference, should not be affected.
Consequently, DELETE and 11.5.

3.12 Behavior of Dangling Direct References

***** Think about chains MOVE do not follow the normal rules of direct behavior
for references.

GET and HEAD respond with 404 (Not Found), but  Instead, they are always applied to the Ref-Type reference
itself, not to its target, and Ref-
Target headers are included they never result in 302 status codes.

Although clients MAY use the response, so that the client can tell
that it is the target, and not the reference, that was not found. (If
the Hide-Target No-Passthrough header was used when creating the reference, then Ref-
Target is not included.)

PUT, MKCOL, and MKREF succeed, creating a new resource at the location
specified by the referenceís DAV:reftarget property.

POST fails with 404 (Not Found), since a nonexistent resource cannot
accept another resource as its subordinate.  The Ref-Type and Ref-Target
headers are included in the response, so that the client can tell that
it is the target, DELETE and not the reference, that was not found. (If MOVE
requests, the
Hide-Target header was used when creating has no effect on their behavior.  Whether the reference, then Ref-Target No-
Passthrough header is not included.)

OPTIONS fails with 404 (Not Found). The Ref-Type and Ref-Target headers present or not, they are included in the response, so that always applied to the client can tell that it
reference.

[WebDAV] defines MOVE to be logically equivalent to COPY followed by
DELETE.  For direct references, MOVE is logically equivalent to COPY
with the
target, and not the reference, that was not found. (If the Hide-Target No-Passthrough header was used when creating the reference, then Ref-Target is not

included.)

PROPFIND responds with followed by DELETE.

4.7 Locking Referential Resources

The semantics of LOCK described here resulted from balancing a 207 Multistatus, including set of
incompatible considerations:

o Ideally, a 404 (Not Found) as
the status for LOCK on a reference should lock both the reference and its
  target resource.  The DAV:reftype and DAV:reftarget
properties owner of an exclusive write lock, for example,
  would be surprised if anyone else could modify the references are included in content of the response.  (If
  target resource while he held the
Hide-Target header was used when creating lock.  He would also be surprised
  if anyone else could delete the reference, then
DAV:reftarget is not included.)  Their presence informs the client that
it is the target, not the reference, that was not found. These two
elements are extensions reference to it, or replace the DAV:multistatus element as defined in
{WEBDAV].

For example,

Request:

PROPFIND /collection1/directref7 HTTP/1.1
Host: www.somehost.com
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:">
   <D:prop xmlns:X="http://www.somehost.com/schemas/x">
      <X:author/>
      <X:title/>
   </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.somehost.com/collection1/directref7</D:href>
      <D:status>HTTP/1.1 404 Not Found</D:status>
      <D:reftype><D:direct/></D:reftype>
      <D:reftarget>
         <D:href>http://www.somehost.com/collection2/file19</D:href>
      </D:reftarget>
   </D:response>
   <D:responsedescription>Target resource not
found.</D:responsedescription>
</D:multistatus>

PROPPATCH responds
  reference with one pointing to a 207 Multistatus, including a 404 (Not Found)
as the status for the target resource.  The DAV:reftype different target.

o Non-referencing clients should be able to use both direct and
DAV:reftarget properties of
  redirect references without encountering surprising results.

o Preserve the clear distinction between redirect and direct
  references.  Redirect references are included 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.  Direct
  references rely on more sophisticated server capabilities to give
  clients the response.
(If illusion of operating directly on the Hide-Target header was used when creating target resource.

o There should be consistency between the reference, then
DAV:reftarget is not included.)  Their presence informs behavior of LOCK on a single
  referential resource and the client behavior of LOCK on a collection that
it is the target, not
  contains referential resources.

o Keep the reference, that was not found. These two
elements are extensions behavior of all requests to the DAV:multistatus element references as defined consistent as
  possible.  Try to adhere to the general rule that in

{WEBDAV].

***** Is the absence of a response to
  No-Passthrough header, all methods return a PROPPATCH required 302 when sent to be a 207 (Multi-Status),
or could it just be a 404 (Not Found)?

For example,

Request:

PROPPATCH /collection1/directref7 HTTP/1.1
Host: www.somehost.com
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" ?>
<D:propertyupdate xmlns:D="DAV:">
   <D:set>
      <D:prop xmlns:X="http://www.somehost.com/schemas/x">
         <X:author>Pauloosie Padluq</X:author>
         <X:title>South Baffin Carvers</X:title>
      </D:prop>
   </D:set>
</D:propertyupdate>

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.somehost.com/collection1/directref7</D:href>
      <D:status>HTTP/1.1 404 Not Found</D:status>
      <D:reftype><D:direct/></D:reftype>
      <D:reftarget>
         <D:href>http://www.somehost.com/collection2/file19</D:href>
      </D:reftarget>
   </D:response>
   <D:responsedescription>Target resource not
found.</D:responsedescription>
</D:multistatus>

MOVE, COPY, and DELETE succeed.  For MOVE and COPY, the reference at the
destination will be broken, just as the
  redirect reference at and are applied to the source was.

If target when sent to a single resource is being LOCKed or UNLOCKed,
  direct reference.

o Be consistent with the response is a 404
(Not Found).  The Ref-Type LOCK semantics defined in [WebDAV].

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

4.7.1 LOCK on Direct References

LOCK follows the
response. (If general principle that operations on direct references
are applied to the Hide-Target header was used when creating target resource unless the
reference, then Ref-Target No-Passthrough header is not included.) Their presence informs the
client that it
used.  When a LOCK request is sent to a direct reference without the target, not No-
Passthrough header, the target resource MUST be locked.  When a LOCK
request with the No-Passthrough header is sent to a direct reference, that was not found.

If
the dangling reference itself MUST be locked.

A principle followed throughout this specification is that behavior when
a member of reference is encountered during an operation on a collection that is being
LOCKed or UNLOCKed, must be
the response is same as behavior when operating on an individual reference.  When a 207 (Multi-Status).  The

DAV:status element for the dangling reference
LOCK request with Depth > 0 is sent to a 404 (Not Found).  The
DAV:reftype and DAV:reftarget properties of collection, the targets of any
direct references are included
in encountered MUST be locked, unless the response.  (If the Hide-Target No-Passthrough
header was used when creating the
reference, then DAV:reftarget is not included.)  Their presence informs used.  If the client that it No-Passthrough header is the target, not the reference, that was not found.
These two elements are extensions to the DAV:multistatus element as
defined in {WEBDAV].

3.13 Summary of Referencing Headers Required in Responses

This section summarizes the rules that determine which referencing
headers must be included in responses to requests present on references.

o Every response to a LOCK
request on with Depth > 0 to a reference collection, then any direct references
encountered MUST include the Ref-Type
  header, so that the client knows that it was operating on a
  reference, and whether the operation themselves be locked.

As was applied to noted above, more intuitive results would have been obtained by
requiring that both the reference
  itself or to and its target.

o Every target to be locked in
response to a request on a direct reference MUST include the
  Ref-Target header, unless the reference was created LOCK request.  Reference-aware clients can obtain this
result by performing two LOCK operations, one with the Hide-
  Target header. No-Passthrough
header and one without.  Non-referencing clients cannot do so.  This allows
means that for non-referencing clients there is always the risk that a
referencing client may delete or replace the reference that was used to tell what
lock a target resource was
  affected by while the operation.  A request that includes non-referencing client has the Re-Direct
  header target
locked.  To insure intuitive results for non-referencing clients,
referencing clients SHOULD be designed to check whether the target
resource is treated as if it were a request on locked before replacing, moving, or deleting a redirect reference,
  and so direct
reference.

UNLOCK behaves as specified in [WebDAV], unlocking all resources
included in the response NEED NOT include lock identified by the Ref-Target Lock-Token header.

o Every response to a GET or HEAD request

4.7.2 LOCK on a Redirect References

The behavior of LOCK for redirect reference (or
  on a direct reference with the Re-Direct header) MUST include all references was determined by what is
possible for the
  referencing entity headers case of locking collections that make sense for contain redirect references:
  Ref-Type, Ref-Target, and Ref-Integrity.

4 Ordered Collections

4.1 Overview

Collections
references.

The expected behavior for any operation on a compliant server may be ordered, but need not be.  It redirect reference is up to that
a 302 (Moved Temporarily) response will be returned, unless the client to decide whether No-
Passthrough header is used.  However, this policy would have
unacceptable consequences when locking a collection that contains
redirect references.  Since [WebDAV} requires LOCK on a given collection is ordered and,
if so, to specify the semantics to be used for ordering its members.  If
an atomic operation, if a collection 302 response is ordered, each received for any member of its members must be in the ordering
exactly once, and
collection, the ordering entire LOCK must not include fail.  This would make it impossible to
lock any resource collection that is not contained a member of the collection.  Only one ordering can be attached to any
collection.  Multiple orderings of the same resources can be achieved by
creating multiple collections referencing those resources, and attaching redirect reference.

To avoid this result, a different ordering to each collection.

The server is responsible for enforcing these constraints LOCK on orderings.
The server MUST remove a resource from the ordering when collection with Depth > 0 MUST lock
any redirect references it encounters, and not return 302 responses for
them, whether or not the No-Passthrough header is removed
from used.

This gives part of the collection. The server MUST add a resource to expected lock behavior without forcing the ordering when
it is added server
to resolve the collection.

When responding to a PROPFIND on redirect reference or become a collection, the proxy server MUST order the
response elements according to in cases
where the ordering defined target resides on the collection.

4.2 Creating an Ordered Collection

4.2.1 Overview

When a collection is created, different server.

Each DAV:response element for a redirect reference MUST include the
DAV:reftype and DAV:reftarget properties so that a referencing client
can request that lock the targets if it wishes.  (There will be ordered
and specify the semantics of the ordering by using the new Ordered
header no hint in the MKCOL request, setting its value to the URI of the
semantics any
response code that there are redirect references whose targets need to
be used.  If the locked.  The client does will most likely not want the collection to be
ordered, it may omit the Ordered header, or use lock any targets until it with the value
"DAV:unordered".

Every collection MUST have the new DAV:orderingtype property, which
indicates whether
attempts an operation on the collection is ordered and, if so, identifies target and gets a 302 response.)  Non-

referencing clients cannot lock the
semantics targets of the ordering.  A value of DAV:unordered indicates that redirect references
and may never realize that
collection is not ordered.  That is, the client cannot depend targets have not been locked.

Clearly, a LOCK with Depth = infinity on a collection MUST NOT follow
any redirect references whose targets are collections into the
repeatability of the ordering target
collections; it MUST NOT cause any members of results from a PROPFIND request.  For those target collections that are ordered, DAV:orderingtype SHOULD be set
to an href
that identifies the semantics be locked.

The behavior of the ordering, allowing a human user or
software package LOCK for individual redirect references is designed to insert new collection members into the ordering
intelligently.  Although the href 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 DAV:orderingtype property MAY
be set to DAV:custom to
indicate consistent with LOCK behavior for collections that the collection is to be ordered, but the semantics of the
ordering is contain redirect
references.  Whether or not being advertised.

If the Ordered a No-Passthrough header is present present, a LOCK
on a MKCOL request, the server redirect reference MUST set
the collection's DAV:orderingtype property to the value of the Ordered
header.  If lock only the Ordered header is reference, not present, the server MUST treat the
request as if its target,
and it had an Ordered header with MUST NOT return a 302 response.  The response MUST include the value "DAV:unordered",
meaning
Ref-Type and Ref-Target headers, so that a referencing client can lock
the collection is not ordered.  If target resource if it wishes.

UNLOCK behaves as specified in [WebDAV], unlocking all resources
included in the collection is
ordered, lock identified by the server MUST respond to PROPFIND requests Lock-Token header.

4.7.3 Example: LOCK on the collection
using the specified ordering.

4.2.2 Status Codes

No new error conditions are introduced.

4.2.3 Example a Direct Reference

Request:

MKCOL /theNorth/

LOCK /MyCollection/tuva HTTP/1.1
Host: www.server.org
Ordered: <http://www.server.org/orderings/compass.html> 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 201 Created 200 OK
Ref-Type: direct
Ref-Target: /Asia/History/tuva.html
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>

In this example, the request-URI identifies a new, ordered collection direct reference whose
target resource is identified by
http://www.svr.com/Asia/History/tuva.html.  This target resource was created.  Its
DAV:orderingtype property has as its value
locked.  The Ref-Type and Ref-Target headers included with the URI from the Ordered
header.  In this case, response
insure that the URI points to client knows that it was operating on a description of the semantics
governing the 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.

4.3 Setting direct
reference, and that the Position of client knows which resource was locked.

4.7.4 Example: LOCK on a Redirect Reference

4.7.5 Example: LOCK on a Collection Member

4.3.1 Overview

When That Contains a new member is added to Direct Reference and
a collection with MKREF, PUT, COPY, MOVE,
or LOCK, its position in the ordering can be set with the new Position
header.  The Position header allows Redirect Reference

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

Request:

LOCK /MyCollection/ 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 207 Multi-Status
Content-Type: text/xml
Content-Length: nnnn

<?xml version="1.0" ?>

<D:multistatus xmlns:D="DAV:">
   <D:response>
      <D:href>/MyCollection/</D:href>
      <D:status>HTTP/1.1 200 OK</D:status>
      <D:prop>
         <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>
   </D:response>
   <D:response>
      <D:href>/MyCollection/tuva</D:href>
      <D:status>HTTP/1.1 200 OK</D:status>
      <D:prop>
         <D:reftype>direct</D:reftype>
         <D:reftarget>
            <D:href>http://www.feynman.com/tuva/</D:href>
         </D:reftarget>
      </D:prop>
   </D:response>
   <D:response>
      <D:href>/MyCollection/nunavut</D:href>
      <D:status>HTTP/1.1 200 OK</D:status>
      <D:prop>
         <D:reftype>redirect</D:reftype>
         <D:reftarget>
            <D:href>http://www.inac.gc.ca/art/inuit/</D:href>
         </D:reftarget>
      </D:prop>
   </D:response>
</D:multistatus>

Although the client to specify entire LOCK operation was successful, a Multi-Status
response is still REQUIRED, so that the
member should DAV:reftype and DAV:reftarget
properties can be first in the collection's ordering, last in the
collection's ordering, before some other collection member in returned for the
collection's ordering, or after some other collection member references in the
collection's ordering. collection.  The server
results for each reference MUST insert the new member into the ordering at the location
specified be reported in the Position header, if one a separate DAV:response
element so that it is present (and if the
collection clear which reference is ordered); otherwise, it MUST append the new member to the
end associated with which
values of the ordering (if the collection DAV:reftype and DAV:reftarget.  In this case, since
/MyCollection/tuva is ordered).  If a PUT or MKREF
causes an existing direct reference, its target resource to be replaced, and if the Position header was
locked.  Since /MyCollection/nunavut is absent, the server MUST leave a redirect reference, the member at
reference itself, and not its previous position in
thee collection ordering.  If the Position header target, was locked.  There is present, the server
MUST remove the member from its previous position, and then insert it at no response
element for the requested position.

4.3.2 Status Codes

201 (Created): The ordinary resource /MyCollection/diary.html, since it was
successfully created.

409 (Conflict): The request may locked and no special information needs to be attempting returned for
it.

4.8 Other WebDAV Operations on Redirect Referential Resources

Although non-referencing WebDAV clients cannot create referential
resources, they should be able to position use the resource
before or after references created by
reference-aware WebDAV clients.  They should be able to follow any
references to their targets.  To make this possible, a resource server that is not in the collection, or before or
after itself,
receives a PROPFIND, PROPPATCH, MKCOL, or it may be attempting to position the resource in an
unordered collection.

4.3.3 Examples

Request: MKREF /~whitehead/dav/spec08.ref HTTP/1.1
HOST: www.ics.uci.edu
Ref-Target: <http://www.ics.uci.edu/i-d/draft-webdav-protocol-08.txt>
Position: After <requirements.html>

Response:

HTTP/1.1 201 Created

This request resulted in the creation of made via a new referential resource at
www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the resource
identified by the Ref-Target header.
redirect reference MUST return a 302 (Moved Temporarily) status code.
The Position header in this
example caused the client and server to set its position in the ordering of the
/~whitehead/dav/ collection immediately after the requirements.html
resource.

Request:

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

Position: First

Response:

HTTP/1.1 409 Conflict

In this case, the server returned a 409 Conflict status code because MUST follow [HTTP] Section 10.3.3 "302 Moved
Temporarily," but with these additional rules:

o The Location response header MUST contain the
/~whitehead/dav/ collection is an unordered collection.  Consequently, target URI of the server was unable to satisfy
  reference.

o The response MUST include the Position Ref-Type header.

4.4 Changing  This header allows
  reference-aware WebDAV clients to recognize the Semantics of a Collection Ordering

After a collection has been created, resource as a client can change its ordering
semantics, or change an ordered collection to an unordered collection or
vice versa, by using PROPPATCH to change
  reference and understand the value of its
DAV:orderingtype property.  The client is then responsible reason for updating the ordering 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 collection members according request to
the new semantics.
PROPPATCH is defined URI in [WebDAV], Section 7.2.

4.5 Changing the Position of a Collection Member

4.5.1 The ORDERPATCH Method

To change the positions of collection members Location header in order to operate on the collection's
ordering, target
resource.  Alternatively, it can resubmit the client MUST use an ORDERPATCH request with a request body
containing an order XML element.  The request-URI of an ORDERPATCH request is to the URI of the collection whose ordering is to be updated.
The order XML element identifies
redirect reference with the member resources whose positions
are No-Passthrough header in order to operate on
the reference itself.  If the No-Passthrough header is present, the
request MUST be changed, applied to the reference itself, and describes their new positions in the ordering.
Each new position can a 302 response MUST
NOT be specified as first in returned.

If a reference-aware client knows before submitting its request that the ordering, last in
request-URI identifies a redirect reference, it can save the
ordering, before some other collection member in round trip
caused by the ordering, or after
some other collection member 302 response by using No-Passthrough in its initial
request to the ordering.  The server MUST apply URI.

Since MKCOL and MKREF fail when applied to existing resources, if the
changes in
client attempts to resubmit the order they appear in request to the order element.

4.5.2 Status Codes

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

Within dangling reference).
Similarly, if the 207 Multi-Status response, client attempts to resubmit the following status codes are
possible:

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

409 (Conflict): An attempt was made request to position the resource before or
after
reference with a resource that is not in the collection, or before or after
itself, or an attempt was made to position No-Passthrough header, the resource in an unordered
collection.

A request to reposition MUST fail.

4.8.1 Example: PROPPATCH on a collection member to Redirect Reference

4.9 Other WebDAV Operations on Direct Referential Resources

With the same place in exception of DELETE and MOVE, which were discussed above,
operations on direct references affect the
ordering is target resource, not an error.

4.5.3 Example

Consider the
reference, unless the No-Passthrough header is used.

Unless the No-Passthrough header is used, a collection /coll-1/ with members 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
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>

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

4.5.4 Design Rationale

The decision to introduce PROPPATCH on a direct
reference MUST modify the new ORDERPATCH method was made after
investigating properties of its target resource, not the possibility
properties of using the existing MOVE method with reference itself.

Unless the No-Passthrough header is used, a
Position header.  The use of MOVE initially looked appealingly simple:

MOVE /root/coll-1/foo HTTP/1.1
Host: www.somehost.com
Destination: </root/coll-1/foo>
Position: First

Unfortunately, several features of PROPFIND on a direct
reference MUST return the semantics properties of MOVE make it
unsuitable for changing its target resource, not the position
properties of a collection member in the
collection's ordering.  First, [WebDAV] defines MOVE as logically
equivalent to a copy followed by a delete of reference itself.

If the source resource.  This
definition makes it impossible to MOVE No-Passthrough header is used with a resource to PROPPATCH or PROPFIND

request on a destination URL
that is the same as direct reference, the source URL.  The resource would operation MUST be deleted applied to the
reference itself rather than moved.  Second, [WebDAV] states that when moving a to its target resource.

MKCOL and MKREF fail if their request-URI identifies an existing
resource of any kind.  Consequently, when submitted to a destination where a target resource already exists, the Overwrite header
must be "T", and in this case the server must DELETE the resource at the
destination before performing
via a direct reference, they MUST fail unless the MOVE.  Again, this makes it impossible
to MOVE reference is a resource
dangling reference.  If they are submitted to an existing direct
reference with the same location.  Finally, [WebDAV] states that
locks are lost No-Passthrough header, they MUST also fail.

4.9.1 Example: PROPPATCH on a MOVE, an outcome that seems undesirable in this
case.

5 New Headers

***** Decide which headers intended for MKREF also can be used with
MOVE, COPY, LOCK.  Is it possible to Direct Reference

4.10 HTTP Operations on Redirect Referential Resources

Although existing HTTP clients cannot create a referential resource by
invoking LOCK?  If so, Ref-Type, Ref-Target, and Ref-Integrity would all
have resources, they
should be able to use collections created by reference-aware WebDAV
clients.  They should be usable with LOCK.  We might need a Resource-Type header able to follow any references identified by
URIs in those collections to their targets.  To enable existing HTTP
clients to
say use GET, HEAD, PUT, POST, or OPTIONS via redirect references,
a server that it is receives any of these requests on a redirect reference we are creating.  What about MOVE and COPY?
At the moment, weíre saying you can change Ref-Type, Ref-Target, and
Ref-Integrity on
MUST return a MOVE or COPY.  It would be pretty weird to change
Resource-Type.  What about Hide-Target?

5.1 Ref-Target Entity Header

Ref-Target = "Ref-Target" ":" Coded-url

Coded-url is defined in [WebDAV], 302 (Moved Temporarily).  The client and server MUST
follow [HTTP] Section 8.4. 10.3.3 "302 Moved Temporarily," but with these
additional rules:

o The Ref-Target Location response header is used with the MKREF method to identify MUST contain the target resource URI of the new referential resource being created.  It is a
required header in MKREF requests.
  reference.

o The response MUST include the Ref-Type header.  This header may also be used with
COPY and MOVE requests allows
  reference-aware WebDAV clients to change recognize the target of resource as a
  reference and understand the destination
reference.

Servers MUST include reason for the Ref-Target header redirection.

Reference-aware clients can act on a 302 response in either of two ways.
Like plain HTTP clients, they can resubmit the following responses
unless the Hide-Target header was used when request to the reference was created, URI in which case the Ref-Target
Location header MUST NOT be included in responses:

o Responses (the URI of the target resource).  They may, however,
want to GET and HEAD requests operate on redirect references

o Responses to all requests the reference rather than on direct references, unless its target.  In this
case, they may resubmit the request
  included the Re-Direct header

5.2 Ref-Type Entity Header

Ref-Type = "Ref-Type" ":" ("DAV:direct" | "DAV:redirect")

The Ref-Type header is defined to distinguish between direct and
redirect references.  The possible values the URI of this header are DAV:direct the reference and DAV:redirect.
include the No-Passthrough header with the request.  If the No-
Passthrough header is not present on a MKREF request, present, the
server request MUST treat be applied to the
reference itself, and a 302 response MUST NOT be returned.

If a reference-aware client knows before submitting its request as if it has that the
request-URI identifies a Ref-Type header with redirect reference, it can save the
value DAV:redirect.  This round trip
caused by the 302 response by using No-Passthrough in its initial
request to the URI.

The No-Passthrough header may also can be used with a COPY GET or MOVE
request on HEAD to retrieve the
entity headers of a redirect reference.  If this header  When No-Passthrough is not present on a COPY used
with GET or MOVE
request, HEAD, the DAV:reftype property MUST be treated like any other live
property, as specified in [WebDAV] sections 7.8.2 referencing entity headers (Ref-Type and 7.9.1.

Servers Ref-
Target) MUST include the Ref-Target header in the following responses:

o Responses to be returned, along with all requests on both direct and redirect HTTP headers that make sense
for references

5.3 Ref-Integrity Entity Header

Ref-Integrity = "Ref-Integrity" ":" ("DAV:weak") (at a minimum, Cache-Control, Age, ETag, Expires, and
Last-Modified).

The Ref-Integrity No-Passthrough header is defined can be used with PUT to allow future support for strong
references.  It specifies whether replace the server should enforce referential
integrity for a referential resource being created redirect
reference with MKREF.  The only
value currently defined for the Ref-Integrity header is "DAV:weak",
which means that the server need not enforce referential integrity for
the newly created reference.  Other values may an ordinary resource.  It can be used by private
agreement between the client and server.  If with OPTIONS to
retrieve the header is not present
on capabilities of a MKREF request, the server redirect reference.

Clients MUST treat NOT, however, use the request as if it has a
Ref-Integrity No-Passthrough header set with POST.
Since a reference cannot accept another entity as its subordinate, an
attempt to "DAV:weak".  This header may also be used POST to a reference with COPY and MOVE requests. No-Passthrough will also fail.  If this a
server receives a POST request with the No-Passthrough header is not present on a COPY or
MOVE request, the DAV:refintegrity property MUST be treated like any
other live property, as specified in [WebDAV] sections 7.8.2 and 7.9.1.

***** Again, does DAV:weak mean that the server need not maintain
referential integrity, or that
redirect reference, it must not?

Servers MUST include the Ref-Integrity header in fail the following
responses:

o Responses to request with a 400 (Bad Request)
status code.

4.10.1 Example: GET and HEAD requests on redirect references (or a Redirect Reference

4.10.2 Example: GET on
  direct a Redirect Reference with No-Passthrough

4.11 HTTP Operations on Direct Referential Resources

GET, HEAD, PUT, POST, and OPTIONS on direct references if are automatically
passed through to their target resources.  GET MUST return the request included content
and headers of the Re-Direct header)

5.4 Re-Direct Request Header

Re-Direct = "Re-Direct" ":" target resource, HEAD MUST return the headers of the
target resource, PUT MUST replace the content of the target resource,
POST MUST perform the expected function at the target resource, and
OPTIONS MUST report the communication options available at the target
resource.

The optional Re-Direct No-Passthrough request header can MAY be used on any request to a direct
reference except PUT with GET, HEAD, PUT, or POST.  It forces the reference to behave like a
redirect reference for that request.  The operation will be applied
OPTIONS to view the reference itself, not to headers or capabilities of the reference, rather
than its target.  If the Re-Direct

The No-Passthrough request header is MUST NOT be used on a request with POST, which
cannot be applied to any other sort of resource besides references.  If a direct
reference, the server SHOULD ignore it.  If the Re-Direct header is used
with receives a PUT or POST request on
a direct reference, reference with the server No-Passthrough header, it MUST
respond fail the
request with a 400 (Bad Request).

***** Confirm behavior for exception cases.

***** What if there is Request) status code.

4.11.1 Example: GET on a chain Direct Reference

4.11.2 Example: GET on a Direct Reference with No-Passthrough

4.12 Operations on Targets of direct references?  Suppose I want Referential Resources

In general, operations on targets of weak referential resources have no
effect on the referential resource.  However, servers that choose to
see
maintain the properties integrity of references are free to make changes to the second reference in the chain - how would I do
that?

5.5 Hide-Target Entity Header

Hide-Target = "Hide-Target" ":"

The optional Hide-Target header is for use
state of references when creating moving or deleting their targets.

When moving a new direct
reference.  It specifies that target resource, a server MAY insert an optional step into
the URI semantics of MOVE as defined in [WebDAV] for the purpose of
maintaining referential integrity.  Between the target resource is to be
hidden.  If this header is used when creating copy step and the delete
step of a direct reference, MOVE, the server MUST NOT include MAY perform an update step, which changes the Ref-Target header in
DAV:reftarget property of any response references to the target to reflect its
new location.

When deleting a
request target resource, a server MAY perform any internal
operations necessary to implement its policy on preserving referential
integrity.  For example, it might delete any references to the reference. If the Hide-Target header is not present, deleted
target, or it might flag them as having a deleted target, or it might
replace references with copies of the
server MUST assume that target.

4.13 Discovering a Targetís References

An OPTIONAL DAV:references property on the target resource provides a
list of referential resources whose DAV:reftarget property is not points to be hidden.
that target resource.  If the Hide-Target header present, DAV:references is used in a request with Ref-Type =
DAV:redirect, the server MUST ignore read-only
property, maintained by the Hide-Target header.

***** If we want to let clients change their minds about Hide-Target
after a reference has been created, we need server.  By retrieving this property, a DAV:hidetarget property to
allow that.

5.6 Resource-Type Entity Header

Resource-Type = "Resource-Type" ":" ["DAV:collection" | "DAV:reference"
                                     |""]

The Resource-Type header contains
client can discover the value URIs of the DAV:resourcetype
property.  It is used with LOCK, MOVE, or COPY references that point to set or change the
resource type.

***** Not needed unless you target,
and so can create a reference with LOCK, or change
resource type with MOVE or COPY.

5.7 Ordered Entity Header

Ordered = "Ordered" ":" ("DAV:unordered" | "DAV:custom" | Coded-url)

The Ordered header may be used with MKCOL to request also discover the collections that contain those URIs as
members.  As for all DAV: properties, this specification is silent as to
how the new
collection DAV:references property is implemented on the server.

The DAV:references property is expected to be ordered supported mainly by
Document Management Systems (DMSs) and to specify its ordering semantics.  A value of
"DAV:unordered" indicates other servers that will maintain
the collection property only for references within their own domain.  It is not ordered.  That is, in
general possible for a server to maintain the client cannot depend property for references on
other servers.  If a reference on a different server points to the repeatability of
target, the ordering of results
from a PROPFIND request. A Coded-url value indicates that server where the collection target is ordered, and identifies the semantics located is unlikely to know about
that reference.  This protocol provides no mechanism for one server to
notify another of the ordering, allowing creation of a
human user or software package to insert new collection members into the
ordering intelligently.  The Coded-url MAY point reference to a resource that
contains a definition one of its resources.
Consequently, the semantics list of the ordering. references in DAV:reftarget may be incomplete.

Rationale: A value number of
"DAV:custom" indicates that scenarios require clients to navigate from a
target resource to the collection is references that point to it, and to be ordered, but the
semantics of
collections that contain the ordering URIs of those references.  This capability
is not being advertised.

If particularly important for DMSs, which may populate their collections
entirely by reference.  Their clients may need to determine, for any
object in the Ordered header DMS, what collections contain URIs that identify
references to that object.  It is not present on a MKCOL request, the server MUST
treat the request as if it had also important in other contexts.  For
example, some servers enforce referential integrity by refusing to
delete any resource that is referenced by other resources.  In such an Ordered header with
environment, the value
"DAV:unordered".

5.8 Position Request Header

Position = "Position" ":" ("First" | "Last" |
                           (("Before" | "After") Coded-url))

The Position header may client must be used with MKREF, PUT, COPY, MOVE, or LOCK able to
tell discover the server where references in the collection ordering order
to position delete them before attempting to delete the
resource being added target.

Risks: When deciding whether to support the collection.  It may be used for both
ordinary and referential members.

If DAV:references property,
server implementers / administrators should balance the Coded-url is a relative URL, benefits it is interpreted relative to
provides against the
collection in which cost of maintaining the resource is being created.

If property and the Position request header is not used, then:

If security
risks enumerated in Sections 12.4 and 12.5.

4.14 Behavior of Dangling Direct References

Whenever the No-Passthrough header accompanies a request is replacing an existing resource, the server MUST
preserve on a dangling
direct reference, the present ordering.

If request succeeds.  Since No-Passthrough causes the
request is adding a new member to the collection, the server MUST
append the new member be applied to the end of the ordering (if reference rather than to its target, it
does not matter that the collection is
ordered).

5.9 DAV-Collections Entity Header

DAV-Collections = "DAV-Collections" ":" 1#collection-capability
collection-capability = "DAV:basicref" | "DAV:directref" |
"DAV:orderedcoll" target resource does not exist.  The DAV-Collections header is used in responses to OPTIONS requests, client
will not be informed that the reference points to
enumerate a nonexistent target.

In the collection-related capabilities absence of the resource.  A value
of "DAV:basicref" indicates No-Passthrough header, the responses MUST be as
follows:

GET, HEAD, OPTIONS, POST, PROPFIND, PROPPATCH, LOCK, UNLOCK, and COPY
respond with 404 (Not Found), but the Ref-Type and Ref-Target headers
are included in the response, so that the resource provides basic referencing
(redirect references).  A value of "DAV:directref" indicates client can tell that it is the
resource provides direct references.  If
target, and not the reference, that was not found.

If, however, a resource provides PROPFIND, LOCK, UNLOCK, or COPY with Depth header greater
than 0 on a collection encounters a dangling direct
references, it MUST also provide redirect references.  A value reference inside the

collection, the response is a 207 (Multi-Status).  The DAV:response
element for the dangling reference will have a status of
"DAV:orderedcoll" indicates 404 (Not
Found). The DAV:reftype and DAV:reftarget properties of the references
are included in the response.  Their presence informs the client that it
is the resource provides ordered
collections.

6 New Properties

6.1 reftarget Property

Name:	    reftarget
Namespace:  DAV:
Purpose:    A required property of referential resources target, not the reference, that provides was not found.  Including these
two properties requires an efficient way for clients extension to discover the URI of the
            target resource. DAV:response element as
defined in {WEBDAV].  This extension is defined in Section 9 below.

PUT succeeds, creating a read-only property, whose value
            can only be set by using new resource at the Ref-Target header with a MKREF,
            COPY, or MOVE request.
Value: 	    URI of location specified by the target resource.

<!ELEMENT reftarget href>

6.2 refintegrity Property

Name:	    refintegrity
Namespace:  DAV:
Purpose:    A required property of a referential
referenceís DAV:reftarget property.

MKREF and MKCOL succeed, since there is no existing resource that indicates
            whether at the server guarantees referential integrity for that
            reference.  The refintegrity property is defined to allow
            future support for strong references.  The only value
            currently defined for refintegrity is weak, which means that
target URI.

MOVE and DELETE succeed, since they always affect the server need not [does not?] enforce referential
            integrity for reference rather
than its target.  For MOVE, the reference.  Other values may be used by
            private agreement between reference at the client and server.  This is a
            readonly property, whose value can only destination will be set by using
broken, just as the
            Ref-Integrity header reference at the source was.

4.14.1 Example: PROPFIND on a Collection with a MKREF, COPY, or MOVE request.
Value:	    weak

<!ELEMENT refintegrity (weak)>

6.3 reftype Property

Name:       reftype
Namespace:  DAV
Purpose:    A required property Dangling Direct
Reference

Request:

PROPFIND /collection1/ HTTP/1.1
Host: www.somehost.com
Depth: 1
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:">
   <D:prop xmlns:X="http://www.somehost.com/schemas/x">
      <X:author/>
      <X:title/>
   </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.somehost.com/collection1/</D:href>
      <D:propstat>
         <D:prop xmlns:X=http://www.somehost.com/schemas/x>
            <X:author>Smith, J.H.</X:author>
            <X:title>My Working Collection</X:title>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
   </D:response>
   <D:response>
      <D:href>http://www.somehost.com/collection1/directref7</D:href>
      <D:status>HTTP/1.1 404 Not Found</D:status>
      <D:prop>
         <D:reftype><D:direct/></D:reftype>
         <D:reftarget>
            <D:href>/collection2/file19</D:href>
         </D:reftarget>
      </D:prop>
      <D:responsedescription>Target resource not found.
      </D:responsedescription>
   </D:response>
</D:multistatus>

4.15 Chains of Direct References

Unless a referential resource No-Passthrough header is present, any operation on a direct
reference that
            identifies is part of a chain of direct references MUST get passed
through to the target of the last reference as direct or redirect.  This in the chain.

Whenever a response is required to include the Ref-Target header, for a
            read-only property, whose value can only
chain of direct references, there MUST be set by using
            the Ref-Type header with a MKREF, COPY, or MOVE request.
Value:      direct | redirect

<!ELEMENT reftype (direct | redirect)>

6.4 references Property

Name:	    references
Namespace:  DAV:
Purpose:    Enables clients to discover, Ref-Target header for any target resource, what
            references point each
reference in the chain.  In order for the client to it and what collections contain it by
            reference.  This is an optional property.  If present, it is
            a read-only property, maintained by know which reference
in the server.
Value:	    List of chain each Ref-Target belongs to, the URIs value of each Ref-Target
header MUST include a hop-number of the references that point to reference as well as the URL of
its target resource.

<!ELEMENT references (href*)>

6.5 orderingtype Property

Name:	    orderingtype
Namespace:  DAV:
Purpose:    Indicates  For example,

Request:

HEAD /math/ref1 HTTP/1.1
Host: www.somehost.edu

Response:

HTTP/1.1 200 ok
Ref-Type: direct
Ref-Target: 0; /logic/ref2
Ref-Target: 1; /library/ref3
Ref-Target: 2; /library/frege/grundgesetze.html
.
.

A server cannot tell whether the collection is ordered and, if so,
            uniquely identifies the semantics of the ordering being
            used.  May also point a dangling reference once pointed to an explanation of the semantics in
            human and /
ordinary resource or machine-readable form.  At a minimum, this
            allows human users who add members to the collection to
            understand where to position them another reference in the ordering.
Value:	    unordered for an unordered collection, or a URI that
            uniquely identifies the semantics chain of direct
references.  When a break occurs before the collection's
            ordering.  The URI MAY point to end of a definition chain of direct
references, the ordering
            semantics.  The value custom may serverís behavior will be used the same as for any other
dangling direct reference, as described in Section 4.13.  For example, a collection
            that is to be ordered, but for which
PUT will create the semantics are not
            being advertised.

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

7 New XML Elements

7.1 reference XML Element

Name: 	    reference
Namespace:  DAV:
Purpose:    A new value of resource at the DAV:resourcetype location specified by the
DAV:reftarget property of the broken reference, even if that identifies
            its resource as a referential resource.  The
            DAV:resourcetype property is in the
middle of what was once a referential resource MUST
            have this value.
Value:	    EMPTY

<!ELEMENT reference EMPTY >

7.2 direct XML Element

Name: chain of direct
Namespace:  DAV:
Purpose:    A value for references.

4.16 URIs and References

In a request-URI /segment1/segment2/segment3, any of the DAV:reftype property that identifies its
            resource as three segments
may identify a direct reference.
Value:      EMPTY

<!ELEMENT direct EMPTY >

7.3 redirect XML Element

Name:	    redirect
Namespace:  DAV:
Purpose:    A value  (See [URI], Section 3.3, for definitions of

"path" and "segment".)  Servers will be unable to resolve such URIs
unless certain constraints hold.  If any segment of the DAV:reftype property that path identifies its
a reference, that reference MUST ultimately resolve to a resource that
behaves as a redirect reference.
Value:      EMPTY

<!ELEMENT redirect EMPTY >

7.4 weak XML Element

Name:	    weak
Namespace:  DAV:
Purpose: container.  (Examples are WebDAV collections, tar files,
and some CGI scripts.)  The only value currently defined for succeeding segment of the DAV:refintegrity
            property.  It means path MUST resolve
to a resource that the is immediately contained in that container.

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

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

The server need not [does not?]
            enforce referential integrity is able to resolve the request-URI because each segment of
the URI's path satisfies the constraints stated above.  Except for the
final segment, each segment that is a reference resolves to which a collection
that contains the
            property belongs.
Value: 	    EMPTY

<!ELEMENT weak EMPTY >

7.5 unordered XML Element

Name:	    unordered
Namespace:  DAV:
Purpose:    A value of next segment as an internal member.  The final
segment, which is a reference, does have a target resource.

If the DAV:orderingtype property that indicates that references are direct references, the collection is not ordered.  That is, server automatically
applies the request to the ultimate target, /c/d.html.

If the references are redirect references, the client cannot
            depend on must follow up
three separate 302 responses before finally reaching the repeatability of target
resource.  The server responds to the ordering of results from initial request with a PROPFIND request.
Value:	    EMPTY

<!ELEMENT unordered EMPTY >

7.6 custom XML Element

Name: 	    custom
Namespace:  DAV:
Purpose:    A value of 302 with
Location: /a/y/z.html, and the DAV:orderingtype property that indicates that client resubmits the collection is ordered, but request to
/a/y/z.html.  The server responds to this request with a 302 with
Location: /b/z.html, and the semantics of client resubmits the ordering
            are not being advertised.
Value: 	    EMPTY

<!ELEMENT custom EMPTY >

7.7 order XML Element

Name: 	    order
Namespace:  DAV:
Purpose:    For use request to /b/z.html.
The server responds to this request with the new ORDERPATCH method.  Describes a change 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 made in ordered, but need not be.  It
is up to the client to decide whether a given collection ordering.
Value: 	    A description of is ordered and,
if so, to specify the new positions of semantics to be used for ordering its members.  If
a collection is ordered, each of its members must be in the collection's ordering.

<!ELEMENT order (member+) >

7.8 ordermember XML Element

Name: 	    ordermember
Namespace:  DAV:
Purpose:    Occurs in the order XML Element, ordering
exactly once, and describes the new
            position of ordering must not include any resource that is not
a single collection member in the collection's
            ordering.
Value: 	    An href containing of the relative URI collection.  Only one ordering can be attached to any
collection.  Multiple orderings of the collection
            member, same resources can be achieved by
creating multiple collections referencing those resources, and attaching
a description of its new position in the
            ordering. different ordering to each collection.

The href XML element server is defined in [WebDAV],
            Section 11.3.

<!ELEMENT ordermember (href, position) >

7.9 position XML Element

Name: 	    position
Namespace:  DAV:
Purpose:    Occurs in responsible for enforcing these constraints on orderings.
The server MUST remove a member URI from the ordering when it is removed
from the collection. The server MUST add a member XML element.  Describes URI to the new
            position in ordering
when it is added to the collection.

When responding to a collection's PROPFIND on a collection, the server MUST order the

response elements according to the ordering of one of defined on the
            collection's members.
Value: 	    The new position collection.

5.2 Creating an Ordered Collection

5.2.1 Overview

When a collection is created, the client can request that it be described as first in the
            collection's ordering, last in ordered
and specify the collection's ordering,
            before some other member semantics of the collection, or after some
            other member of ordering by using the collection.

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

7.10 first XML Element

Name: 	    first
Namespace:  DAV:
Purpose:    Occurs new Ordered
header in the position XML element.  Describes MKCOL request, setting its value to the
            collection member's position as first in URI of the collection's
            ordering.
Value: 	    EMPTY

<!ELEMENT first EMPTY >

7.11 last XML Element

Name: 	    last
Namespace:  DAV:
Purpose:    Occurs in the position XML element.  Describes the
            collection member's position as last in
semantics to be used or setting its value to DAV:custom if the collection's
            ordering.
Value: 	    EMPTY

<!ELEMENT last EMPTY >

7.12 before XML Element

Name: 	    before
Namespace:  DAV:
Purpose:    Occurs in semantics
are not being advertised.  If the position XML element.  Describes client does not want the collection member's position as coming before some other
            collection member in the collection's ordering.
Value: 	    href of to
be ordered, it may omit the member Ordered header, or use it precedes in with the ordering

<!ELEMENT before href >

7.13 after XML Element

Name: 	    after
Namespace:  DAV:

Purpose:    Occurs in value
"DAV:unordered".

Every collection MUST have the position XML element.  Describes new DAV:orderingtype property, which
indicates whether the collection member's position as coming after some other
            collection member in is ordered and, if so, identifies the collection's ordering.
Value: 	    href
semantics of the member it follows in the ordering

<!ELEMENT after href >

8 Extensions to the DAV:multistatus XML Element

As described in Section 3.12, ordering.  A value of DAV:unordered indicates that that
collection is not ordered.  That is, the DAV:reftype property and client cannot depend on the
DAV:reftarget property may be returned in
repeatability of the DAV:response element ordering of results from a
207 Multi-Status response, PROPFIND request.  For
collections that are ordered, DAV:orderingtype SHOULD be set to indicate an href
that a problem is not with a
direct reference, but with its target resource.

Consequently, identifies the definition semantics of the DAV:response XML element changes ordering, allowing a human user or
software package to insert new collection members into the following:

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

9 Capability Discovery

9.1 Using OPTIONS

Since referencing and ordering are independent capabilities, a resource
intelligently.  Although the href MAY support either or both.  A point to a resource that provides referencing MUST
support redirect references, and MAY in addition support direct
references.  A response to an OPTIONS request MUST indicate which contains
a definition of
these capabilities the resource supports.

This specification defines two new methods: MKREF in support semantics of
referencing, and ORDERPATCH the ordering, clients are discouraged
from accessing that resource, in support of ordering. order to avoid overburdening its
server.  The response MUST DAV:orderingtype property MAY be set to DAV:custom to
indicate which that the collection is to be ordered, but the semantics of these methods the resource allows.  In addition,
ordering is not being advertised.

If the
response Ordered header is present on a MKCOL request, the server MUST include set
the DAV-Collections header, listing those collection's DAV:orderingtype property to the value of the
three collection-related capabilities Ordered
header.  If the resource provides.  Possible
values for Ordered header is not present, the server MUST treat the DAV-Collections
request as if it had an Ordered header are DAV:basicref, DAV:directref,
and DAV:orderedcoll.

9.2 Example with the value "DAV:unordered",
meaning that the collection is not ordered.  If the collection is
ordered, the server MUST respond to PROPFIND requests on the collection
using the specified ordering.

5.2.2 Status Codes

Servers MUST use the HTTP/1.1 status codes as defined in [HTTP].

5.2.3 Example: Creating an Ordered Collection

Request:

OPTIONS /somecollection/

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

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, MKREF, ORDERPATCH
Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL,
PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREF, ORDERPATCH

DAV-Collections: DAV:basicref, DAV:directref, DAV:orderedcoll

This response indicates that the resource /somecollection/ provides
basic referencing, direct references, and 201 Created

In this example, a new, ordered collections.

10 Dependencies on Other Specifications

TBD

11 Security Considerations

This section is provided to detail issues concerning security
implications of which WebDAV applications need to be aware.

All of collection was created.  Its
DAV:orderingtype property has as its value the security considerations of HTTP/1.1 and URI from the base WebDAV
protocol also apply to WebDAV collections. Ordered

header.  In addition, referential
resources and ordered collections introduce several new security
concerns and increase this case, the risk of some existing threats.  These issues URI identifies the semantics governing the
ordering.  As new members are detailed below.

11.1 Redirect Loops

Although redirect loops were already possible added to the collection, clients or end
users can use the semantics to determine where to position the new
members in HTTP 1.1, the
introduction ordering.

5.3 Setting the Position of referential resources creates a Collection Member

5.3.1 Overview

When a new avenue for clients member is added to create loops accidentally a collection (for example, with PUT,
MKREF, or maliciously.  If the referential
resource and MKCOL), its target are on the same server, position in the server may ordering can be able set with the new
Position header.  The Position header allows the client to detect MKREF requests specify that would create loops. See also [HTTP],
Section 10.3 "Redirection 3xx."

11.2 References and Denial of Service

The introduction of referential resources creates a new avenue for
denial of service attacks. Clients can create heavily used references to
target locations that were not designed for heavy usage.

11.3 Maintaining Referential Integrity May Reveal Private Locations

Although this specification does not require servers to maintain
referential integrity, it does not prevent them from doing so.  If a
server updates a referenceís DAV:reftarget property when its target
resource is moved, there is
the risk that a private location will member should be
revealed first in the new value of DAV:reftarget.  Clients can avoid this risk
by doing a COPY followed by a DELETE rather than a MOVE.

If collection's ordering, last in the owner of
collection's ordering, before some other collection member in the target also owns
collection's ordering, or after some other collection member in the direct reference to it,
collection's ordering.

The server MUST insert the
Hide-Target header can be used when creating new member into the direct reference to
prevent others from discovering ordering at the location of the target through that
reference.

11.4 DAV:references and Denial of Service

If
specified in the server maintains Position header, if one is present (and if the DAV:references property in response to
references created in other administrative domains, it
collection is exposed to
hostile attempts to make ordered); otherwise, it devote resources to adding references MUST append the new member to the
list.

11.5 DAV:references and Malicious Deletion
end of Resources

Servers that support the DAV:references property should insure that
clients cannot create editable properties with ordering (if the name DAV:references.
An editable DAV:references property would constitute a security risk on
servers that enforce referential integrity by deleting references when
their target collection is deleted.  These servers could be tricked into deleting ordered).  If a
resource by listing PUT causes an
existing resource to be replaced, and if the Position header is absent,
the server MUST leave the member at its previous position in thee
collection ordering.  If the Position header is present, the server MUST
remove the member from its previous position, and then insert it at the
requested position.

5.3.2 Status Codes

Servers MUST use the HTTP/1.1 status codes as defined in [HTTP].  Some
likely client errors for when setting the DAV:references property of some target
resource.

11.6 Malicious Modifications position of Ordering

Particularly in large collections, moving a collection
member include:

409 (Conflict): The request may be attempting to a
different position the collection
member before or after a URI that is not in the ordering can make collection, or before or
after itself, or it very difficult for users
to find.

11.7 Denial of Service and DAV:orderingtype

There may be some risk of denial of service at sites that are advertised attempting to position the collection member
in an unordered collection.

5.3.3 Examples: Setting the DAV:orderingtype property Position of collections.  However, it is
anticipated that widely-deployed applications will use hard-coded values
for frequently-used ordering semantics rather than looking up 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
semantics creation of a new referential resource at
www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the location specified resource
identified by DAV:orderingtype.

12 Internationalization Considerations

This specification follows the practices of [WebDAV] Ref-Target header.  The Position header in encoding all
human-readable content using XML [XML] and this
example caused the server to set its position in the treatment ordering 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

/~whitehead/dav/ collection immediately after requirements.html.

Request:

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

Response:

HTTP/1.1 409 Conflict

In this case, the language tagging functionality of server returned a 409 Conflict status code because the XML
specification.  This constraint ensures that
/~whitehead/dav/ collection is an unordered collection.  Consequently,
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 server was unable to satisfy the Position header.

5.4 Changing the Semantics of properties.  Naming 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 protocol elements follows its
DAV:orderingtype property.  The client is then responsible for updating
the precedent ordering of HTTP, using English names encoded the collection members according to the new semantics.
PROPPATCH is defined in USASCII for
methods and headers. [WebDAV], Section 7.2.

5.5 Changing the Position of a Collection Member

5.5.1 The names ORDERPATCH Method

To change the positions of XML elements used in this
specification are English names encoded collection members in UTF-8.

For error reporting, [WebDAV] follows the convention of HTTP/1.1 status
codes, including collection's
ordering, the client MUST use an ORDERPATCH request with each status code a short, English description request body
containing an order XML element.  The request-URI of
the code (e.g., 423 Locked).  Internationalized applications will ignore
this message, and display an appropriate message in ORDERPATCH
request is the user's language
and character set.

For rationales for these decisions and advice for application
implementors, see [WebDAV].

13 IANA Considerations

TBD

14 Copyright

15 Intellectual Property

16 Acknowledgements

This draft has benefited from thoughtful discussion by Steve Carter,
Geoffrey Clemm, Ellis Cohen, Bruce Cragun, Spencer Dawkins, Rajiv
Dulepet, David Durand, Chuck Fay, Roy Fielding, Yaron Goland, Fred Hitt,
Alex Hopmann, Marcus Jager, Chris Kaler, Rohit Khare, Daniel LaLiberte,
Steve Martin, Surendra Koduru Reddy, Sam Ruby, Bradley Sergeant, Nick
Shelness, John Stracke, John Tigue, John Turner, URI of the collection whose ordering is to be updated.
The order XML element identifies the member URIs whose positions are to
be changed, and others.

17 References

[WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D.
Jensen, "HTTP Extensions for Distributed Authoring - WebDAV." Draft-
ietf-webdav-protocol-09. Internet Draft, work describes their new positions in progress.  Microsoft,
U.C. Irvine, Netscape, Novell. November, 1998.

[DASL] Saveen Reddy, D. Jensen, Surendra Reddy, R. Henderson, J. Davis,
A. Babich, "DAV Searching & Locating." Draft-reddy-dasl-protocol-03.
Internet Draft, work the ordering.  Each new
position can be specified as first in progress. Microsoft, Novell, Oracle, Netscape,
Xerox, Filenet.  November, 1998.

[WebDAVReq] J. Slein, J. Davis, "Requirements for Advanced Collection
Functionality the ordering, last in WebDAV." Draft-ietf-webdav-collection-reqts-02.
Internet Draft, work the
ordering, before some other collection member in progress.  Xerox, 1998.

[HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1." RFC 2068.  UC Irvine, DEC,
MIT/LCS.  January, 1997.

[XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup
Language (XML)."  World Wide Web Consortium Recommendation REC-xml-
19980210. http://www.w3.org/TR/1998/REC-xml-19980210.

18 the ordering, or after
some other collection member in the ordering.  The server MUST apply the
changes in the order they appear in the order element.

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

Within the 207 Multi-Status response, the following status codes are
possible:

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

409 (Conflict): An attempt was made to position the collection member
before or after a URI that is not in the collection, or before or after
itself, or an attempt was made to position the collection member in an

unordered collection.

A request to reposition a collection member to the same place in the
ordering is not an error.

5.5.3 Example: Changing the Positions of Collection Members in the
Ordering

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

nunavut.map
nunavut.img
baffin.map
baffin.desc
baffin.img
iqaluit.map
nunavut.desc
iqaluit.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
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>

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 Design Rationale

The decision to introduce the new ORDERPATCH method was made after
investigating the possibility of using the existing MOVE method with a
Position header.  The use of MOVE initially looked appealingly simple:

MOVE /root/coll-1/foo HTTP/1.1
Host: www.somehost.com
Destination: </root/coll-1/foo>
Position: First

Unfortunately, several features of the semantics of MOVE make it
unsuitable for changing the position of a collection member in the
collection's ordering.  First, [WebDAV] defines MOVE as logically
equivalent to a copy followed by a delete of the source resource.  This
definition makes it impossible to MOVE a resource to a destination URL
that is the same as the source URL.  The resource would be deleted
rather than moved.  Second, [WebDAV] states that when moving a resource
to a destination where a resource already exists, the Overwrite header
must be "T", and in this case the server must DELETE the resource at the
destination before performing the MOVE.  Again, this makes it impossible
to MOVE a resource to the same location.  Finally, [WebDAV] states that
locks are lost on a MOVE, an outcome that seems undesirable in this
case.

6 Headers

6.1 Ref-Target Entity Header

Ref-Target = "Ref-Target" ":" 1#([hop-count ";"] Coded-url)
hop-count = 1*DIGIT
Coded-url is defined in [WebDAV], Section 8.4.

In general, the Ref-Target header has the simpler form:

Ref-Target = "Ref-Target" ":" Coded-url

The more complicated syntax is provided only for use in responses
involving chains of direct references.

The Ref-Target header is used with MKREF requests to identify the target
resource of the new referential resource being created.  It is a
REQUIRED header in MKREF requests.   When used with a MKREF request, its
value is simply a Coded-url, and only a single value is allowed.  For an
example, see Section 4.3.3.

Servers MUST include the Ref-Target header in responses to the following
types of requests:

Reference Type     | No-Passthrough | Method
--------------------------------------------------------------
direct or redirect | Present        | GET, HEAD
--------------------------------------------------------------
direct             | Absent         | All except MKREF, UNLOCK
--------------------------------------------------------------
redirect           | Absent         | COPY, LOCK, DELETE, MOVE

The only case where multiple values of Ref-Target are allowed is when it
is included in a response for a reference that is part of a chain of
direct references.  In this case, the response MUST include a value of
Ref-Target for each reference in the chain.  Each value MUST include a
hop-count, starting with 0, indicating which reference in the chain that
Ref-Target belongs to.  For an example, see Section 4.14.

The Coded-url in a Ref-Target header MAY be a relative URI.  If it is a
relative URI, the base URI to be used for resolving it to absolute form
has as its scheme component "http", as its authority component the value
of the Host: header from the request, and as its path component the
request-URI from the request.  See [URI] Section 5 for a discussion of
relative URI references and how to resolve them.

6.1.1 Example: Resolving a Relative URI in Ref-Target

Request:

PUT /north/inuvik HTTP/1.1
Host: www.somehost.edu
Content-Type: image/gif
Content-Length: nnnnnn

<body>

Response:

HTTP/1.1 200 ok
Ref-Type: direct
Ref-Target: mapcollection/inuvik.gif

In this example, the base URI is http://www.somehost.edu/north/inuvik.

The relative URI in Ref-Target resolves to the absolute URI
http://www.somehost.edu/north/mapcollection/inuvik.gif.

6.2 Ref-Type Entity Header

Ref-Type = "Ref-Type" ":" ("DAV:direct" | "DAV:redirect")

The Ref-Type header is defined to distinguish between direct and
redirect references.  The possible values of this header are DAV:direct
and DAV:redirect.  If the header is not present on a MKREF request, the
server MUST treat the request as if it has a Ref-Type header with the
value DAV:redirect.

Servers MUST include the Ref-Target header in every response to a
request whose request-URI identifies a reference, with the exception of
responses to MKREF requests.

6.3 Ref-Integrity Request Header

Ref-Integrity = "Ref-Integrity" ":" ("do-not-enforce" | "enforce" |
                extend)
extend = 1#CHAR

The Ref-Integrity header is defined primarily to allow future support
for strong references.  It specifies whether the server should enforce
referential integrity for a referential resource being created with
MKREF.

The value "do-not-enforce" means that the server MUST NOT enforce
referential integrity for the newly created reference.  A client might
use this value if, for example, it wanted to populate a collection with
references before their content was made available on the Web.

The value "enforce" means that the server MUST enforce referential
integrity for the newly created reference, but does not constrain the
server to use any particular policy for enforcing referential integrity.
It is beyond the scope of this specification to define precisely the
meaning of referential integrity or to enumerate any set of policies
that might be considered compliant.

Clients and servers may use other values of the Ref-Integrity header by
private agreement, to specify more precisely the desired policy for
enforcing referential integrity.  If a server receives an extension
value that it does not understand, it MUST fail the request.

If the Ref-Integrity header is not present on a MKREF request, the
server MAY enforce referential integrity or not, and if it does enforce
referential integrity, it MAY follow any policy it chooses.

6.4 No-Passthrough Request Header

No-Passthrough = "No-Passthrough" ":"

The optional No-Passthrough header can be used on any request to a
reference except POST.  For a direct reference, if the No-Passthrough

header is present, the request MUST be applied to the reference itself
rather than to its target.  For a redirect reference, if the No-
Passthrough header is present, the request MUST be applied to the
reference itself, and a 302 response MUST NOT be returned.  If the No-
Passthrough header is used on a request to any other sort of resource
besides a reference, the server SHOULD ignore it.  If the No-Passthrough
header is used with a POST request to a reference, the server MUST
respond with a 400 (Bad Request).

The No-Passthrough header can be used with PROPFIND requests on
collections with Depth = infinity.  When it is used in this way, the
server MUST return the properties of any redirect references in the
collection, and not return 302 (Moved Temporarily) status codes for
them.  It MUST also return the properties of any direct references in
the collection (not the properties of their targets), and it MUST NOT
follow any direct references to collections into their target
collections.

The No-Passthrough header can be used with LOCK requests on collections
with Depth = infinity.  When it is used in this way, the server MUST
lock any redirect references in the collection, just as it would if the
No-Passthrough header were absent.  It MUST also lock any direct
references in the collection (not their target resources), and it MUST
NOT follow any direct references to collections into their target
collections.

The No-Passthrough header can be used with COPY requests on collections
with Depth > 0.  When it is used in this way, the server MUST copy any
redirect references in the collection, just as it would if the No-
Passthrough header were absent.  It MUST also copy any direct references
in the collection (not their target resources), and it MUST NOT follow
any direct references to collections into their target collections.

6.5 Ordered Entity Header

Ordered = "Ordered" ":" ("DAV:unordered" | "DAV:custom" | Coded-url)

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.  That is,
the client cannot depend on the repeatability of the ordering of results
from a PROPFIND request. A Coded-url value indicates that the collection
is ordered, and identifies the semantics of the ordering, allowing a
human user or software package to insert new collection members into the
ordering intelligently.  The Coded-url MAY point to a resource that
contains a definition of the semantics of the ordering.  A value of
"DAV:custom" indicates that the collection is to be ordered, but the
semantics of the ordering is not being advertised.

If the Ordered header is not present on a MKCOL request, the server MUST
treat the request as if it had an Ordered header with the value
"DAV:unordered".

6.6 Position Request Header

Position = "Position" ":" ("First" | "Last" |
                           (("Before" | "After") Coded-url))

The Position header may be used with any method that adds a member to a
collection to tell the server where in the collection ordering to
position the new member being added to the collection.  It may be used
for both ordinary and referential members.

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

If the Position request header is not used, then:

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

If the request is adding a new member to the collection, the server MUST
append the new member to the end of the ordering (if the collection is
ordered).

7 Properties

7.1 reftarget Property

Name:	    reftarget
Namespace:  DAV:
Purpose:    A REQUIRED property of referential resources 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 a variety of requests.  It always occurs in
            the context of a Multi-Status response, inside a
            DAV:response element that has 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.)  See [URI] Section 5 for a
            discussion of relative URI references and how to resolve
            them.

<!ELEMENT reftarget href>

7.1.1 Example: Resolving a Relative URI in the DAV:reftarget

Request:

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

Content-Length: nnn

<?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:">
   <D:prop>
      <D:resourcetype/>
      <D:reftype/>
      <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>collection</D:resourcetype>
          </D:prop>
          <D:status>HTTP/1.1 200 ok</D:status>
     </D:propstat>
     <D:propstat>
           <D:prop><D:reftype/> <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>reference</D:resourcetype>
            <D:reftype>direct</D:reftype>
            <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.

7.2 refintegrity Property

Name:	    refintegrity

Namespace:  DAV:
Purpose:    A REQUIRED property of a referential resource that indicates
            whether the server enforces referential integrity for that
            reference.  The refintegrity property is defined to allow
            future support for strong references.  The only value
            currently defined for refintegrity is weak, which means that
            the server does not enforce referential integrity for the
            reference.  Although a server may assign another value to
            identify its policy for enforcing referential integrity for
            the reference, it cannot count on clients understanding such
            extension values.  This is a readonly property.
Value:	    weak or an extension value

<!ELEMENT refintegrity (weak | ANY)>

7.3 reftype Property

Name:       reftype
Namespace:  DAV:
Purpose:    A required property of a referential resource that
            identifies the reference as direct or redirect.  This is a
            read-only property, whose value can only be set by using
            the Ref-Type header with a MKREF request.
Value:      direct | redirect

<!ELEMENT reftype (direct | redirect)>

7.4 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 >

7.5 references Property

Name:	    references
Namespace:  DAV:
Purpose:    Enables clients to discover, for any target resource, what
            references point to it and what collections contain it by
            reference.  This is an optional property.  If present, it is
            a read-only property, maintained by the server.
Value:	    List of the URIs of the references that point to the target
            resource.

<!ELEMENT references (href*)>

7.6 orderingtype Property

Name:	    orderingtype
Namespace:  DAV:
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 URI MAY point to a definition of the ordering
            semantics.  The value custom may be used for a collection
            that is to be ordered, but for which the semantics are not
            being advertised.

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

8 XML Elements

8.1 reference XML Element

Name: 	    reference
Namespace:  DAV:
Purpose:    A new value of the DAV:resourcetype property that identifies
            its resource as a referential resource.  The
            DAV:resourcetype property of a referential resource MUST
            have this value.
Value:	    EMPTY

<!ELEMENT reference EMPTY >

8.2 direct XML Element

Name:	    direct
Namespace:  DAV:
Purpose:    A value for the DAV:reftype property that identifies its
            resource as a direct reference.
Value:      EMPTY

<!ELEMENT direct EMPTY >

8.3 redirect XML Element

Name:	    redirect
Namespace:  DAV:
Purpose:    A value for the DAV:reftype property that identifies its
            resource as a redirect reference.

Value:      EMPTY

<!ELEMENT redirect EMPTY >

8.4 weak XML Element

Name:	    weak
Namespace:  DAV:
Purpose:    A value of the DAV:refintegrity property.  It means that the
            server does not enforce referential integrity for the
            reference to which the property belongs.
Value: 	    EMPTY

<!ELEMENT weak EMPTY >

8.5 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.
Value:	    EMPTY

<!ELEMENT unordered EMPTY >

8.6 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.
Value: 	    EMPTY

<!ELEMENT custom EMPTY >

8.7 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 collection members in
            the collection's ordering.

<!ELEMENT order (ordermember+) >

8.8 ordermember XML Element

Name: 	    ordermember
Namespace:  DAV:
Purpose:    Occurs in the order XML Element, and describes the new
            position of a single collection member in the collection's
            ordering.
Value: 	    An href containing a relative URI, 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) >

8.9 position XML Element

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

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

8.10 first XML Element

Name: 	    first
Namespace:  DAV:
Purpose:    Occurs in the position XML element.  Describes the
            collection member's position as first in the collection's
            ordering.
Value: 	    EMPTY

<!ELEMENT first EMPTY >

8.11 last XML Element

Name: 	    last
Namespace:  DAV:
Purpose:    Occurs in the position XML element.  Describes the
            collection member's position as last in the collection's
            ordering.
Value: 	    EMPTY

<!ELEMENT last EMPTY >

8.12 before XML Element

Name: 	    before
Namespace:  DAV:
Purpose:    Occurs in the position XML element.  Describes the
            collection member's position as coming before some other
            collection member in the collection's ordering.
Value: 	    href of the member it precedes in the ordering

<!ELEMENT before href >

8.13 after XML Element

Name: 	    after
Namespace:  DAV:
Purpose:    Occurs in the position XML element.  Describes the
            collection member's position as coming after some other
            collection member in the collection's ordering.
Value: 	    href of the member it follows in the ordering

<!ELEMENT after href >

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

As described in Sections 4.5 and 4.6, 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
to the target resource of a redirect reference.

As described in Section 4.13, the DAV:reftype and DAV:reftarget
properties may be returned in the DAV:response element of a 207 Multi-
Status response, to indicate that a problem is not with a direct
reference, but with its target resource.

Whenever these properties are included in a Multi-Status response, they
will be 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?) >

10 Capability Discovery

10.1 Using OPTIONS

Since referencing and ordering are independent capabilities, a resource
MAY support either or both.  A resource that provides referencing MUST
support redirect references, and MAY in addition support direct
references.  A response to an OPTIONS request MUST indicate which of
these capabilities the resource supports.

This specification defines two new methods: MKREF in support of
referencing, 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].  Three new compliance classes are defined here for use
with the DAV header: basicref, directref, 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 immediate member
URIs can be ordered.  It implies nothing about whether any collections

identified by its member URIs can be ordered.

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

10.2 Example: Capability Discovery

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
Accept-Ranges: none
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL,
PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREF, ORDERPATCH
Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL,
PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREF, ORDERPATCH
DAV: 1, 2, basicref, directref, orderedcoll

This response indicates that the resource /somecollection/ is level 1
and level 2 compliant, as defined in [WebDAV].  In addition,
/somecollection/ supports ordering and is in a part of the server
namespace that allows creation of redirect and direct references.  (In
light of the semantics of MKREF, the resource currently at
/somecollection/ would have to be deleted before a reference could be
created at that URI.)

11 Dependencies on Other Specifications

TBD

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 base WebDAV
protocol also apply to WebDAV collections.  In addition, referential
resources and ordered collections introduce several new security
concerns and increase the risk of some existing threats.  These issues
are detailed below.

12.1 Privacy Concerns

By creating 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 for redirect

references, 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.)  For direct references, clients can determine
the resource type, reference type, and target location before sending a
request, but are not required to notify users if the target is on
another server.

12.2 Redirect Loops

Although redirect loops were already possible in HTTP 1.1, the
introduction of referential resources creates a new avenue for clients
to create loops accidentally or maliciously.  If the referential
resource and its target are on the same server, the server may be able
to detect MKREF requests that would create loops. See also [HTTP],
Section 10.3 "Redirection 3xx."

12.3 References 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
introduction of referential resources creates a new avenue for similar
denial of service attacks.  Clients can now create references at heavily
used sites to target locations that were not designed for heavy usage.

12.4 References May Reveal Private Locations

There are several ways that the referencing mechanisms described here
may reveal information about directory structures.  First, the
DAV:reftarget property of every 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 header, which is
returned in most responses to requests on direct references, reveals 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.

Second, although this specification does not require servers to maintain
referential integrity, it does not prevent them from doing so.  If a
server updates a referenceís DAV:reftarget property when its target
resource is moved, there is the risk that a private location will be
revealed in the new value of DAV:reftarget.  Clients can avoid this risk
by doing a COPY followed by a DELETE rather than a MOVE.

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

12.5 DAV:references and Denial of Service

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

12.6 DAV:references and Malicious Deletion of Resources

Servers that support the DAV:references property should insure that
clients cannot create editable properties with the name DAV:references.
An editable DAV:references property would constitute a security risk on
servers that enforce referential integrity by deleting references when
their target is deleted.  These servers could be tricked into deleting a
resource by listing it in the DAV:references property of some target
resource.

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

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

16 Intellectual Property

To be supplied.

17 Acknowledgements

This draft has benefited from thoughtful discussion by Jim Amsden, Steve
Carter, Ken Coar, Ellis Cohen, Bruce Cragun, Spencer Dawkins, Rajiv
Dulepet, David Durand, Roy Fielding, Yaron Goland, Fred Hitt, Alex
Hopmann, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare,
Daniel LaLiberte, Steve Martin, Surendra Koduru Reddy, 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
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

J. Davis
Xerox Corporation
3333 Coyote Hill Road
Palo Alto, CA 94304
Email: jdavis@parc.xerox.com

A. Babich

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

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: ababich@filenet.com cfay@filenet.com

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

A. Babich
FileNet Corporation
3565 Harbor Boulevard
Costa Mesa, CA 92626-1420
Email: ababich@filenet.com

20 Appendices

20.1 Appendix 1: Extensions to the WebDAV Document Type Definition

<!--============= XML Elements from Section 8 =======================-->
<!ELEMENT reference EMPTY >
<!ELEMENT direct EMPTY >
<!ELEMENT redirect EMPTY >
<!ELEMENT weak EMPTY >

<!ELEMENT location href>
<!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 >
<!--============= Property Elements from Section 7 ==================-->
<!ELEMENT reftarget href>
<!ELEMENT refintegrity (weak | ANY)>
<!ELEMENT reftype (direct | redirect)>
<!ELEMENT references (href*)>
<!ELEMENT orderingtype (arbitrary | custom | href) >
<!--====== Changes to the DAV:response Element from Section 9 ====-->
<!ELEMENT response (href, ((href*, status, prop?) | (propstat+)),
responsedescription?) >

20.2 Appendix 2: Summary of Referencing Headers Required in Responses

This section summarizes the rules that determine which referencing
headers are included in responses to requests on references.  The
normative statements that are summarized here can be found in Sections
4.5 - 4.10, 4.13, 4.14, 6.1, and 6.2.

Reference Type | No-Passthrough | Method          | Headers Included in
               |                |                 | Response
-----------------------------------------------------------------------
both           |Present / Absent| All except      | Ref-Type
               |                | MKREF, UNLOCK   |
-----------------------------------------------------------------------
both           |Present         | GET, HEAD       | Ref-Target
-----------------------------------------------------------------------
direct         |Absent          | All except      | Ref-Target
               |                | MKREF, UNLOCK   |
-----------------------------------------------------------------------
redirect       |Absent          | COPY, LOCK,     | Ref-Target
               |                | DELETE, MOVE    |

o Every response to a request on a reference includes the Ref-Type
  header, so that the client knows that it was operating on a
  reference, and can understand the behavior of the reference.

o Since [HTTP] requires responses to GET and HEAD to include all entity
  headers, Ref-Target is included in all responses to GET and HEAD
  requests on references with the No-Passthrough header.

o For all other requests with the No-Passthrough header, the client is
  aware that it is operating on the reference rather than the target,
  so the Ref-Target header is OPTIONAL.

o When the No-Passthrough header is absent from a request on a direct
  reference, the target resource is affected.  Consequently, the Ref-
  Target header is required.  This allows the client to tell what
  resource was affected by the operation.  The exceptions are MKREF,
  since the client knows the value of Ref-Target that it sent in the
  request, and UNLOCK, which affects just the resources that were
  locked with the same lock token.

o When the No-Passthrough header is absent from a request on a direct
  reference, in most cases the response is a 302 with the Location
  header.  The Location header contains the URI of the target resource.
  Consequently, the Ref-Target header is OPTIONAL in the response.
  COPY, LOCK, DELETE, and MOVE do not return a 302 response, but
  instead operate on the reference.  For these methods, a Ref-Target
  header is REQUIRED in the response.  This allows the client to locate
  the target resource in case it wants to resubmit the request to the
  target.

Requests on collections with Depth header greater than 0 typically get
Multi-Status responses.  Consequently, information about any references
in the collection cannot be returned in headers.  Instead, the
corresponding DAV properties are returned in the DAV:response elements
for the references.

20.3  Appendix 3: Summary of Method Semantics for References

This section summarizes the semantics of California, Irvine
Irvine, CA 92697-3425
Email: ejw@ics.uci.edu

19 Appendices

19.1 Appendix 1 each HTTP and WebDAV method
when the request-URI identifies a reference.  The normative statements
that are summarized here can be found in Sections 4.3 - Extensions 4.10.

For each method, there are four cases to consider:

o Request-URI identifies a redirect reference, and the No-Passthrough
  header is not used
o Request-URI identifies a redirect reference, and the No-Passthrough
  header is present
o Request-URI identifies a direct reference, and the No-Passthrough
  header is not used
o Request-URI identifies a direct reference, and the No-Passthrough
  header is present

When the No-Passthrough header is used, the situation is simple.  For
all methods, the request is applied to the reference, not to its target
resource.

The following table summarizes behavior for the cases where the No-
Passthrough header is not used:

METHOD    | REDIRECT REFERENCE           | DIRECT REFERENCE
---------------------------------------------------------------------
GET       | Respond with 302 status code | Apply method to target
---------------------------------------------------------------------
HEAD      | Respond with 302 status code | Apply method to target
---------------------------------------------------------------------
OPTIONS   | Respond with 302 status code | Apply method to target
---------------------------------------------------------------------
PUT       | Respond with 302 status code | Apply method to target

---------------------------------------------------------------------
POST      | Respond with 302 status code | Apply method to target
---------------------------------------------------------------------
MKCOL     | Respond with 302 status code | Apply method to target
          |                              | (fails unless dangling)
---------------------------------------------------------------------
MKREF     | Respond with 302 status code | Apply method to target
          |                              | (fails unless dangling)
---------------------------------------------------------------------
PROPPATCH | Respond with 302 status code | Apply method to target
---------------------------------------------------------------------
PROPFIND  | Respond with 302 status code | Apply method to target
=====================================================================
DELETE    | Apply method to the WebDAV Document Type Definition

<!--============= XML Elements from Section 7 =======================-->
<!ELEMENT reference EMPTY >
<!ELEMENT direct EMPTY >
<!ELEMENT redirect EMPTY >
<!ELEMENT weak EMPTY >
<!ELEMENT unordered EMPTY >
<!ELEMENT custom EMPTY >
<!ELEMENT order (member+) >
<!ELEMENT ordermember (href, position) >
<!ELEMENT position (first    | last Apply method to reference
---------------------------------------------------------------------
MOVE      | before Apply method to reference    | after)>
<!ELEMENT first EMPTY >
<!ELEMENT last EMPTY >
<!ELEMENT before href >
<!ELEMENT after href >
<!--============= Property Elements from Section 6 ==================-->
<!ELEMENT reftarget href>
<!ELEMENT refintegrity (weak)>
<!ELEMENT reftype (direct Apply method to reference
=====================================================================
COPY      | redirect)>
<!ELEMENT references (href*)>
<!ELEMENT orderingtype (arbitrary Apply method to reference    | custom Apply method to target
---------------------------------------------------------------------
LOCK      | href) >
<!--======== Changes Apply method to the DAV:multistatus Element from Section 8 ==-->
<!ELEMENT response (href, ((href*, status, reftype?, reftarget?) reference    |
(propstat+)), responsedescription?) > Apply method to target
---------------------------------------------------------------------
UNLOCK    | Apply method to reference    | Apply method to target

PROPFIND, DELETE, MOVE, COPY, LOCK, and UNLOCK can be applied to
collections.  In cases where the collection contains references,
behavior for the references in the collection follows the same rules as
the table describes for individual references.  So, for example, if a
PROPFIND encounters a redirect reference within a collection, it returns
a 302 status code for that redirect reference in the Multi-Status
response.  If the PROPFIND encounters a direct reference, it returns the
properties of the direct referenceís target resource in the Multi-Status
response.

Expires May 10, August 26, 1999