WEBDAV Working Group                                     J. Slein, Xerox
INTERNET DRAFT                             E.J. Whitehead Jr., UC Irvine
                                                     J. Davis, Xerox
<draft-ietf-webdav-collection-protocol-03>       T. Chihaya, DataChannel CourseNet
                                                      G. Clemm, Rational
                                                         C. Fay, FileNet
                                           E.J. Whitehead Jr., UC Irvine
                                                      A. Babich, FileNet
                                                       February 26,
                                                        J. Crawford, IBM
                                                 T. Chihaya, DataChannel
                                                           June 18, 1999
Expires August 26, December 18, 1999

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

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.

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

To view the

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

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

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

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

Abstract

The base WebDAV protocol [WebDAV] Distributed Authoring Protocol 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 URIs
that are immediately relative to the URI of offering the collection. ability to create and list unordered
collections.  Many applications, however, need more powerful collections.  There are
two areas in particular where more powerful functionality is often
needed: referential resources
collections, especially for resource sharing and collection ordering.

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

Table of Contents

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

4	Referential Resources.........................................5	Shared Resources............................................6
4.1	Scope.........................................................5	Overview....................................................6
4.2	Overview......................................................6	Bindings....................................................7
4.2.1	BIND Method.................................................8
4.2.2	Bindings to Collections.....................................9
4.2.3	URI Mappings Created by BIND...............................10
4.2.4	Example: Generating the Set of URI Mappings................10
4.2.5	Status Codes...............................................11
4.2.6	Example: BIND..............................................11
4.2.7	Example: BIND Conflict.....................................12
4.2.8	DELETE and Bindings........................................12
4.2.9	COPY and Bindings..........................................13
4.2.10	MOVE and Bindings..........................................13
4.2.11	LOCK and UNLOCK............................................15
4.2.12	Bindings and Other Methods.................................16
4.2.13	Discovering the Bindings to a Resource.....................16
4.3	Creating Referential Resources................................8	Redirect References........................................17
4.3.1	The	MKREF Method..............................................8 Method...............................................17
4.3.2	Status 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 with References............10
4.4.2	Example: PROPFIND with No-Passthrough on the Redirect References in a Collection with
        References...................................................12
4.5 Collection............19
4.3.3	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 References................................22
4.3.4	Deleting and Moving Redirect References....................24
4.3.5	Locking Redirect References................................24
4.3.6	LOCK on a Direct Reference..........................16
4.5.4	Example: COPY Redirect References................................25
4.3.7	Other Operations 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....24
4.8.1	Example: PROPPATCH on a Redirect Reference...................24
4.9	Other WebDAV Operations on Direct Referential Resources......24
4.9.1	Example: PROPPATCH on a Direct Reference.....................25
4.10	HTTP Operations on Redirect Referential 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..............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 References....................28
4.3.8	Operations on Targets of Referential Resources...............26
4.13	Discovering a Target’s References............................26
4.14	Behavior of Dangling Direct References.......................27
4.14.1	Example: PROPFIND on a Collection with a Dangling Direct
        Reference....................................................28
4.15	Chains of Direct References..................................29
4.16 Redirect References...............30
4.3.9	Relative URIs in Ref-Target and References..........................................29 DAV:reftarget..............31
4.3.10	Redirect References to Collections.........................32
5	Ordered Collections..........................................30 Collections........................................33
5.1	Overview.....................................................30	Overview...................................................33
5.2	Creating an Ordered Collection...............................31 Collection.............................34
5.2.1	Overview.....................................................31	Overview...................................................34
5.2.2	Status Codes.................................................31
5.2.3	Example: Creating an Ordered Collection......................31 Collection....................34
5.3	Setting the Position of a Collection Member..................32 Member................35
5.3.1	Overview.....................................................32	Overview...................................................35
5.3.2	Status Codes.................................................32 Codes...............................................35
5.3.3	Examples: Setting the Position of a Collection Member........32 Member......35
5.4	Changing the Semantics of a Collection Ordering..............33 Ordering............36
5.5	Changing the Position of a Collection Member.................33 Member...............36
5.5.1	The	ORDERPATCH Method........................................33 Method..........................................36
5.5.2	Status Codes.................................................33 Codes...............................................36
5.5.3	Example: Changing the Positions of Collection Members in
        the Ordering.................................................34 an Ordered Collection.......37
5.5.4	Design Rationale.............................................35	Example: Failure of an ORDERPATCH Request..................38
6	Headers......................................................35	Headers....................................................39
6.1	Ref-Target Entity Header.....................................35
6.1.1	Example: Resolving a Relative URI in Ref-Target..............36	All-Bindings Request Header................................39
6.2	Ref-Type	Ref-Target Entity Header.......................................37 Header...................................39
6.3	Ref-Integrity Request Header.................................37	Resource-Type Entity Header................................40
6.4	No-Passthrough	Passthrough Request Header................................37 Header.................................40
6.5	Ordered Entity Header........................................38 Header......................................40
6.6	Position Request Header......................................38 Header....................................40
7	Properties...................................................39	Status Codes...............................................41

7.1	reftarget Property...........................................39
7.1.1	Example: Resolving a Relative URI in the DAV:reftarget.......39	506 Loop Detected..........................................41
7.2	refintegrity Property........................................40
7.3	reftype Property.............................................41
7.4	location Property............................................41
7.5	references Property..........................................41
7.6	orderingtype Property........................................42	425 Unordered Collection...................................41
8	XML Elements.................................................42	Properties.................................................41
8.1	reference XML Element........................................42	reftarget Property.........................................41
8.2	direct XML Element...........................................42	location Property..........................................42
8.3	redirect XML Element.........................................42	bindings Property..........................................42
8.4	weak	orderingtype Property......................................42
9	XML Element.............................................43
8.5	unordered Elements...............................................43
9.1	redirectref XML Element....................................43
9.2	segment XML Element........................................43
8.6
9.3	unordered XML Element......................................43
9.4	custom XML Element...........................................43
8.7 Element.........................................43
9.5	order XML Element............................................43
8.8 Element..........................................44
9.6	ordermember XML Element......................................43
8.9 Element....................................44
9.7	position XML Element.........................................44
8.10 Element.......................................44
9.8	first XML Element............................................44
8.11 Element..........................................44
9.9	last XML Element.............................................44
8.12 Element...........................................44
9.10	before XML Element...........................................44
8.13 Element.........................................45
9.11	after XML Element............................................44
9 Element..........................................45
9.12	options XML Element........................................45
9.13	orderingoptions XML Element................................45
10	Extensions to the DAV:response XML Element for Multi-Status
        Responses....................................................45
10
        Responses..................................................45
11	Capability Discovery.........................................45
10.1	Using OPTIONS................................................45
10.2 Discovery.......................................46
11.1	Compliance Classes.........................................46
11.2	Example: Capability Discovery................................46
11	Dependencies on Other Specifications.........................46 Discovery of Compliance Classes...................46
11.3	Additional Advanced Collections Capabilities...............47
11.4	Example: Discovery of Ordering Options.....................47
12	Security Considerations......................................46 Considerations....................................48
12.1	Privacy Concerns.............................................46 Concerns...........................................48
12.2	Redirect Loops...............................................47 Loops.............................................48
12.3	References	Redirect References, Bindings, and Denial of Service.............................47 Service.......48
12.4	References May Reveal	Private Locations......................47 Locations May Be Revealed..........................49
12.5	DAV:references	DAV:bindings and Denial of Service.........................48 Service.........................49
12.6	DAV:references and Malicious Deletion of Resources...........48
12.7	Denial of Service and DAV:orderingtype.......................48 DAV:orderingtype.....................49
13	Internationalization Considerations..........................48 Considerations........................49
14	IANA Considerations..........................................48 Considerations........................................50
15	Copyright....................................................49	Copyright..................................................50
16	Intellectual Property........................................49 Property......................................50
17	Acknowledgements.............................................49	Acknowledgements...........................................50
18	References...................................................49	References.................................................50
18.1	Normative References.........................................49 References.......................................50
18.2	Informational References.....................................49 References...................................51
19	Authors' Addresses...........................................50 Addresses.........................................51
20	Appendices...................................................50	Appendices.................................................52
20.1	Appendix 1: Extensions to the WebDAV Document Type
        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
        Definition.................................................52

1 Notational Conventions

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

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
Distributed Authoring Protocol specification [WebDAV].

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

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

Referential terms resource, Uniform Resource Identifier (URI), and Uniform
Resource (or Reference) Locator (URL) are provided in [URI].

Association
     A direct or indirect connection between a resource that has no body of its own (though it does have
     properties), but rather is and a reference to another resource

Ordinary Resource
     A resource namespace
     element that is not a reference to another supports resource

Target Resource sharing. The resource referenced by bindings, URI
     mappings, and redirect references defined in this specification
     are types of associations.

URI Mapping
     An association between an absolute URL or URI and a resource.
     Since a referential resource

Direct Reference
     A reference can represent items that is resolved by the server without any client
     action, giving the client the illusion are not network
     retrievable, as well as those that are, it is operating
     directly on the target possible for a
     resource

Redirect Reference
     A reference that requires client action before it can be resolved,
     so that the client is aware that to have zero, one, or many URI mappings to URLs or URIs.
     Mapping a reference is mediating between resource to an "http" scheme URL makes it and possible to
     submit HTTP protocol requests to the target resource

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

Weak Reference
     A reference whose referential integrity is not enforced by URL.

Path Segment
     Informally, the
     server

Referential Integrity
     The integrity characters found between slashes ("/") in a URL or
     URI.  Formally, as defined in section 3.3 of [URI].

Binding
     An association between a reference single path segment (in a collection) and
     a resource. A binding creates one or more URI mappings, and hence
     is preserved as long as it points to
     the same a mechanism for resource sharing, allowing a single resource it pointed to when it was created.  Its
     integrity may
     be destroyed if the target accessed from multiple locations in a URI namespace.

Collection
     A resource is moved without
     updating the reference to reflect that contains, as part of its new location, or if the
     target resource is deleted.

3 Introduction state, a set of bindings
     which identify member resources.

Internal Member URI
     The simple collections URI mapping, created by a binding that the base WebDAV specification supports are
powerful enough is contained in a
     collection.  While, in general, bindings can create multiple URI
     mappings to be widely useful.  They provide a resource, for the hierarchical
organization a given request, only one of resources, with mechanisms for creating and deleting
collections, copying and moving them, locking them, adding members these URI
     mappings is referred to
them and removing members from them, and getting listings as the internal member. The URI of their
members.  Delete, copy, move, list, and lock operations can be applied
recursively, so that the
     parent collection used in a client can operate on whole hierarchies with given request determines the base URI
     for internal member URI calculation.

     In [WebDAV], a
single request.

Many applications, however, need more powerful collections.  There are
two areas in particular collection is defined as containing a list of
     internal member URIs, where more powerful functionality an internal member URI 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 URI of
     the collections
share collection, plus a single path segment.  This definition
     combines the resource by referencing it, only one physical copy two concepts of the
resource need exist, binding and any changes made in the resource are visible
from all the collections mapping that reference it.

It is useful for many applications are
     separated in this specification.  As a result, this specification
     redefines a collection's state to be able to impose an ordering on a
collection. Orderings may be based on property values, but they may be
completely independent set of any properties on the resources identified by
the collection’s bindings, and
     redefines an internal member URIs.  Orderings based on properties can be
obtained using URI to be a search protocol [DASL], but orderings not based on
properties need some other mechanism.

Since these two areas are independent mapping derived from a
     binding. After this redefinition, an internal member URI can be
     used when reading [WebDAV] without loss of each other, servers may elect
to comply with the Referential Resources section meaning. For purposes
     of interpretation, when [WebDAV] discusses a collection
     "containing" an internal member URI, this specification
or with should be read as 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
     collection containing a binding whose mapping to a URI creates an OPTIONS request,
as specified
     internal member URI, in Section 10 below.

4 Referential Resources

4.1 Scope

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

references.  This this sense "containing" the internal
     member URI.  The authors of this specification supports weak references, direct
references, and redirect references, anticipate and
     recommend that future revisions of [WebDAV] perform a full
     reconciliation of terms between these two specifications.

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

Redirect Reference
     A resource whose purpose is to provide access to another resource,
     and that requires client action before it can be
extended to support strong references in the future.

Strong references are references whose integrity resolved.  The
     client is enforced by aware that this type of reference is mediating between
     it and the
server; weak references are those whose integrity target resource.

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

Target Resource
     The resource referenced by a referential resource.

Referential Integrity
     The integrity of a reference is preserved as long as it points to
     the
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 same resource it pointed to
reference target resources on multiple servers, where referential when it was created.  Its
     integrity cannot be enforced, and may be less concerned about possible
broken references.

Several considerations led to destroyed if the decision not target resource is moved without
     updating the reference to support strong
references in reflect its new location, or if the current specification.  First, there are many possible
policies that applications and services might use in enforcing
referential integrity.  Some examples are:

o Delete strong references when their targets are deleted.
o Decline
     target resource is deleted while a reference to delete targets of strong references.
o Notify strong references when their targets have been deleted.
o Replace strong references with copies of their targets before
  deleting it still exists.

3 Introduction

The simple collections that the targets.

There appears WebDAV Distributed Authoring Protocol
specification supports are powerful enough to be no common practice in this area.  Moreover, some of widely useful.  They
provide for the policies have significant security risks.

o Moving a target hierarchical organization of strong references could be a security risk resources, with mechanisms
for creating and deleting collections, copying and moving them, locking
them, adding members to the
  owner them and removing members from them, and getting
listings of the target by revealing secret locations on the target's
  server.
o A strong reference could their members.  Delete, copy, move, list, and lock
operations can be applied recursively, so that a security risk to the owner of the
  reference by revealing secret locations on his server.
o The presence of strong references to resources client can operate on
whole hierarchies with a server could make
  it impossible single request.

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

Organizing resources into hierarchies places them into smaller
groupings, known as collections, which are more easily browsed and
manipulated than a flat namespace.  However, hierarchies require
categorization decisions that server by moving or deleting
  those target resources.

These considerations together led to the decision not to support strong
references locate resources at a single location in
the short term.

4.2 Overview

A referential resource is hierarchy, a drawback when a resource that has no body multiple valid categories.
For example, in a hierarchy of its own, but
instead references another resource.  The resource it references may
have vehicle descriptions containing
collections for cars and boats, a URI in the same collection as the reference, or description of a combination car/boat
vehicle could belong in any other either collection.  This target resource may Ideally, the description

should be accessible from both.

Hierarchies also make resource sharing more difficult, since resources
that have utility across many collections are still forced into a collection or single
collection. For example, the mathematics department at one university
might create a simple
resource or another reference, or any other sort collection of resource information on fractals that contains
bindings to some local resources, but also provides access to some
resources at other universities.  For many reasons, it may be
defined in the future.  A resource may be the target of any number of
referential resources.  To make it possible
undesirable to distinguish references
from ordinary resources, a new value make physical copies of the DAV:resourcetype property is
defined here.  The DAV:resourcetype property of all references MUST have shared resources on the value DAV:reference.

Redirect references are references that require action by local
server - to conserve disk space, to respect copyright constraints, or to
make any changes in the client

before they can be resolved.  They are simple shared resources visible automatically.

This protocol provides two mechanisms for servers allowing resources to implement,
straightforward appear
in multiple places in an http URL hierarchy, and for clients to use, sharing resources:
bindings and have only limited security
implications.  Any server that complies with WebDAV referencing MUST
provide redirect references.

If the client is aware that it is operating on a redirect reference, it
can resolve the reference by retrieving the reference’s DAV:reftarget
property, whose value is the URI of the target resource.  It can then
submit requests to the target resource.

Otherwise, the client submits a request to the redirect reference.  For
most operations, the response is a 302 (Moved Temporarily), accompanied
by the Ref-Type header with the value "DAV:redirect" and the Location
header with the URI of the target resource.

The client can then
resubmit the request WebDAV Distributed Authoring Protocol added to the URI of Web the target resource.  A few
operations, for reasons that will be explained, are exceptions to this
general behavior. These exceptional operations are applied ability
to the
reference itself and do not result navigate Web resources hierarchically, complementing existing
hypertext navigation facilities. In hypertext navigation, links appear
in a 302 response.

Direct references, specific order in a document. By 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 hierarchical navigation
has fewer mechanisms for expressing 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 ordering of a direct reference set of resources.

There are many scenarios where it is useful to apply most operations
directly to its target, so that the client is not aware that impose an ordering on a reference
is mediating between it and the target resource.  The exceptions are
operations that affect membership in
collection, such as expressing a collection rather than the state recommended access order, or a revision
history order. Orderings may be based on property values, but they may
be completely independent of any properties on the target resource.  At present, resources identified
by the operations that fall into this
category are DELETE and MOVE. collection's internal member URIs.  Orderings based on properties
can be obtained using a search protocol [DASL], but orderings not based
on properties need some other mechanism.  These operations are applied to the
reference itself rather than orderings generally need
to its target, so that only the collection
containing the reference is affected. be maintained by a human user.  The No-Passthrough request header is ordering protocol defined here
focuses on support for such human-maintained orderings, but also provided, to force an
operation to be applied to allows
for server-maintained orderings.

4 Shared Resources

4.1 Overview

Shared resources make the reference itself rather than its target.
It can be used with most requests to direct or redirect references. same resource accessible from multiple
locations in http URL namespaces.  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 protocol provides two mechanisms
for sharing resources: bindings and redirect references.  This goal is more difficult to meet for redirect
references, since client action is required to resolve them.

The
strategy of having redirect references respond to most requests with a
302 (Moved Temporarily), accompanied by the URI of the target resource binding mechanism defined in the Location header, fulfills this goal in most cases.

To distinguish between direct and redirect references, specification provides a way for
clients to add new DAV:reftype
property URI mappings to existing resources.  A URI mapping is defined, with the values DAV:direct
an association between an absolute URI 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 resource, which makes it
possible to submit requests to the value DAV:redirect.

Every reference MUST have resource using that URI as the DAV:reftarget property, whose value is
Request-URI. Bindings, and the URI of the reference’s target resource.

Although strong references mappings based on them, are not currently supported, a new
DAV:refintegrity property is defined in anticipation of future support appealing
mechanisms for strong references.  DAV:refintegrity will allow resource sharing because:

o Once URI mappings are created with a BIND request, clients need do
  nothing special to
distinguish between weak and strong references.  All references MUST
have this property.  Although the only currently defined for
DAV:refintegrity is DAV:weak, use them.  They behave just like any other values may be defined in URI
  mappings, transparently applying operations to the future, target resource.
o HTTP and WebDAV servers MAY use extension values already provide URI mappings, so there is
  little extra work involved in allowing clients to identify their policy for
enforcing referential create them.
o The integrity for of bindings is guaranteed.  MOVE and DELETE operations
  cannot leave bindings in an inconsistent state.

A limitation of bindings is that resource.

4.3 Creating Referential Resources

4.3.1 The MKREF Method

Referential a server would need proxy capabilities
in order to support bindings to resources are created using the MKREF method.  The request-
URI on another server.  In light
of the MKREF request identifies the this complexity, support for cross-server bindings is OPTIONAL.

A redirect reference is a resource whose purpose is to be created.  The
REQUIRED Ref-Target header contains provide access to
another resource.  It redirects most requests on the URI reference to
another resource, thereby providing a form of mediated access to the target
other resource.

An OPTIONAL Ref-Integrity request header  Since the HTTP 302 (Moved Temporarily) status code is defined below, primarily for
future support for strong references.  The only values currently defined
for this header are "do-not-enforce" and "enforce", although other
values may be
used by private agreement.  If a server receives the value
"do-not-enforce", it MUST NOT enforce referential integrity for the
reference being created.  If to redirect client requests on a server receives the value "enforce", it
MUST enforce referential integrity for redirect reference, from the reference being created, but
is free
clientÆs point of view redirect references are less convenient to follow any policy it chooses for enforcing referential
integrity.  If use
than bindings.  Redirect references require action by the Ref-Integrity header is not used with a MKREF
request, client before
they can be resolved.  Moreover, the server MAY enforce referential integrity, but is not required to do so, and if it does enforce referential integrity, it may
do so according to 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 fail the request.

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.

An OPTIONAL Position request header supports ordered collections by
allowing
the client creating integrity of redirect references.  However, redirect references have
a reference to specify where the new member
is number of advantages:

o They are simple for servers to be placed implement.  Servers already provide
  redirect resources in the collection's ordering.  (This header form of 301 / 302 redirection control, and
  the same mechanism can also be used with any other method for redirect references.
o The same simple implementation works equally well for target
  resources that adds a member to a collection, to
specify its position in reside on the collection ordering.)

When a same server processes and for target resources
  that reside on a MKREF request, it MUST set the
DAV:resourcetype property (defined in [WebDAV]) different server.
o Redirect references have only limited security implications.
o Since redirect references are resources, they can carry properties of the new resource to
  their own.

Ideally, non-referencing clients should be DAV:reference.

When a server processes a MKREF request, it MUST set the DAV:reftarget
property able to use both bindings and
redirect references.  This goal is more difficult to meet for redirect
references, since client action is required to resolve them.  The
strategy of having redirect references respond to most requests with a
302 (Moved Temporarily), accompanied by the URI of the target resource.

When a server processes a MKREF request, it MUST set the DAV:reftype
property based on resource
in the value Location header, fulfills this goal in most cases.

4.2 Bindings

Bindings are part of the Ref-Type header.

When a server processes state of 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 collection. In general, there is
enforcing referential integrity for the new reference, it MAY set the
value of DAV:refintegrity to an extension value identifying a
one-to-one correspondence between a collection's bindings and its
enforcement policy.
internal member URIs.  The client MUST NOT send any content URI segment associated with the MKREF request, and so MUST
NOT use the Content-Length or Transfer-Encoding headers.  (See [HTTP]
Section 4.3.)

If a MKREF request has resource by one
of a request-URI that identifies an existing
resource, the request MUST fail.  This behavior collection's bindings is analogous to also the
behavior final segment of one of the MKCOL method [WebDAV].

4.3.2 Status Codes

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

400 (Bad Request):
collection's internal member URIs.  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 final segment of each internal
member URI identifies one of the location specified in Ref-Target, on a server bindings that
prohibits dangling references.  The request may be attempting to create is part of the reference in a collection that does
collection's state, unless the internal member URI is not exist.  The request may be
attempting bound to position the reference before or after a resource that
resource.

Even though a binding is
not in the collection, or before just an association between a path segment and
a resource, a binding creates one or after itself.  The request may be
attempting more URI mappings of a URI to position a
resource.  For example, if the reference in an unordered collection.

4.3.3 Example: MKREF

Request:

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

Response:

HTTP/1.1 201 Created

This request resulted segment "index.html" is being bound to a
resource in a collection with URL "http://www.foo.net/A/", the creation of binding
creates a new referential resource at
www.ics.uci.edu/~whitehead/dav/spec08.ref, which points URI mapping of URL "http://www.foo.net/A/index.html" to the resource
identified by
HTML resource. If the Ref-Target header.  Its DAV:resourcetype property is
set to DAV:reference.  Its DAV:reftarget property parent collection is set then bound to the segment
"B", this creates two URI of
its target resource.  Its DAV:refintegrity property is set mappings, "http://www.foo.net/B/" to the value
of DAV:weak, indicating that
collection resource, and "http://www.foo.net/B/index.html" to the server will not enforce referential
integrity for HTML
resource.  Both the new reference.  Its DAV:reftype property is set to collection and the
default value of DAV:redirect.

4.4 Listing Referential Members of a Collection

A URI of a reference can be HTML resource are now accessible
via two URLs apiece.

For a member of resource implemented by a collection just as computer, the relationship between a URI of
an ordinary resource can.  A listing of members of
mapping and a collection shows
all of the URIs resource is highlighted in the collection, whether they identify references or
ordinary resources.  That is, a WebDAV PROPFIND request on following diagram:

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

As discussed in [URI], a collection resource with Depth = 1 or infinity MUST return is an abstraction that maps a response XML element
for each URI in the collection, whether it identifies to
an ordinary
resource entity or set of entities.  This resource can have multiple URIs/URLs
mapped to it.

The identity of a referential resource.

For each direct reference, the properties returned binding is determined by the PROPFIND MUST
be the properties of URI segment (in its
collection) and the target resource unless that the No-Passthrough
header binding associates.  If the
resource is included with destroyed, the PROPFIND request.

For each redirect reference, binding also goes out of existence.  If the response element MUST contain
URI segment comes to be associated with a 302
(Moved Temporarily) status code unless different resource, the No-Passthrough header
original binding ceases to exist and another binding is
included with created.

Bindings are not unique to advanced collections, although the PROPFIND request.  The DAV:location BIND
method for explicitly creating bindings is introduced here.  Existing
methods that create resources, such as PUT, MOVE, COPY, and DAV:reftype
properties MUST be included MKCOL,
implicitly create bindings.  There is no difference between implicitly
created bindings and bindings created with BIND.

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

It is especially difficult to maintain the DAV:response element that was defined in [WebDAV] as
described in Section 9 below.  A referencing client can tell from integrity of cross-server
bindings.  Unless the
DAV:reftype property server where the resource resides knows about all
bindings on all servers to that resource, it may unwittingly destroy the collection contains
resource or move it without notifying a redirect reference.
The DAV:location property contains the absolute URI server where a binding resides.
For example, if server A permits creation of the target
resource. a binding to a resource on
server B, server A referencing client can either use must notify server B about its binding and must have
an agreement with B that B will not destroy the DAV:location property resource while A's
binding exists.  Otherwise server B may receive a DELETE request that it
thinks removes the last binding to retrieve the properties of resource and destroy the target resource or can submit
while A's binding still exists.

Consequently, support for cross-server bindings is OPTIONAL.

4.2.1 BIND Method

The BIND method creates a
PROPFIND new binding from the final segment of the
Request-URI (minus any trailing slash) to the redirect reference with resource identified
by the No-Passthrough header Destination header.  This binding is added to
retrieve the collection
identified by the Request-URI minus its properties. trailing slash (if present) and
final segment.  The DAV:location property Destination header 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 Section 9.3 of the target resource.

[WebDAV].

If Depth = infinity in a server cannot guarantee the PROPFIND request, binding behavior specified for GET
(Section 4.2.12), DELETE (Section 4.2.8), and MOVE (Section 4.2.10), the server
BIND request MUST NOT follow
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 fail with a 501 (Not Implemented) status code.

If the request.  That is, if Request-URI ends in a slash ("/") (i.e., the
target resource is Request-URI
identifies a collection, collection), the server MUST list resource identified by the members of
that collection.

The No-Passthrough Destination
header MAY MUST be used with a PROPFIND collection resource, or the request on fails with a
collection. 409
(Conflict) status code. This ensures that URIs ending in a slash are
always bound to collections.  If the No-Passthrough header is present, then the
properties Request-URI does not contain a path
segment (i.e., it consists simply of a slash "/"), the references in the collection BIND operation
MUST be returned, 302
(Moved Temporarily) fail and report a 409 (Conflict) status codes code.

After successful processing of a BIND request, it MUST NOT be returned possible for redirect
references, direct references MUST NOT pass
clients to use the request through Request-URI to their
target resources, and submit requests to the resource
identified by the Destination header.

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

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

A server MUST NOT follow direct references MAY allow the BIND method to
collections into their target collections.

4.4.1 Example: PROPFIND on be used to create bindings to
resources that support content negotiation or to resources that
dynamically generate response entities.

4.2.2 Bindings to Collections

BIND can create a Collection with 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 binding to 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 No-Passthrough header is not
used.  The collection contains one URI that identifies resource.  A collection
accessed through such a redirect
reference.  The response element for binding behaves exactly as would a collection
accessed through any other binding.  Bindings to collections can result
in loops, which servers MUST detect when processing "Depth: infinity"
requests.  When a loop is detected, the redirect reference has server MUST respond with a 506
(Loop Detected) status
of 302 (Moved Temporarily), and includes code (defined in Section 7.1).

Creating a DAV:prop element with the
DAV:location and DAV:reftype properties to allow clients new binding to retrieve the
properties of its target resource.  The a collection also contains one URI makes each resource associated
with a binding in that identifies collection accessible via a direct reference.  The response element for the direct
reference contains new URI, but does not
result in the properties creation of its target collection.  There are
also response elements a new binding for each member of its target collection.

4.4.2 Example: PROPFIND with No-Passthrough on these resources.

For example, suppose a Collection with
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 new binding COLLX is present, the response shows the
properties of the references in the created for collection rather than the
properties of their targets.  Even though Depth = infinity, C1 in
the No-
Passthrough header prevents figure below.  It immediately becomes possible to access resource R1
using the server from listing URI /COLLX/x.gif and to access resource R2 using the members URI
/COLLX/y.jpg, but no new bindings for these child resources were
created.  This is because bindings are part of the
collection state of a
collection, and associate a URI that is the *relative to that collection*
with its target of the direct reference.  No-Passthrough
also prevents a 302 response from being returned for resource.  No change to the redirect
reference.

4.5 Copying Referential Resources

In determining the semantics of COPY, the desire to provide intuitively
correct behavior was weighed against consistency considerations.

A client’s intent bindings in performing a COPY operation is to create a new
resource that Collection C1 is similar
needed to the original resource and behaves like the
original resource, make its children accessible using /COLLX/x.gif and that can be modified without affecting the
original resource.  For references to ordinary resources, the
expectation would be that the target resource
/COLLX/y.jpg.

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

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

4.2.3 URI Mappings Created by BIND

The set of URI mappings created by a successful BIND operation MUST be copied.  This would
yield
determined as follows:

1. Start with an independent resource that could be modified without affecting empty set of URLs, called U.
2. Take the original resource.  For collections Request-URI and remove path segments (and associated "/"
characters) from the situation right until either (a) a non-WebDAV collection, or
a non-WebDAV advanced collection is less clear.
There found, or (b) the root, "/" is tension between two expectations. On
reached (i.e., no characters after the one hand, scheme and authority parts of the client
may expect
URL).  This is the new copy base URL B.
3. Add B, and all possible domain name variants of B (i.e., all other
domain names which can be substituted for the collection to behave like the old one
(which implies having references where domain name in B, and
still retrieve the old one had references).  On resource mapped to B), to URL set U.
4. Calculate the other hand, next path segment of the client may expect that Request-URI, going from right
to left, and call it will be possible S, which is bound to modify
the members resource R.
5. For each member of the URL set U, called Um, remove Um, then for every
possible binding to R, create a new collection without affecting URL by adding the members of binding's path
segment to Um, then add this new URL to U.
6. If there is no further path segment, then U has the
old collection (which implies having copies complete set of
URI mappings. Otherwise, go back to step 4.

4.2.4 Example: Generating the targets where the
original Set of URI Mappings

Assume a server responds to two domain names, www.fuzz.com, and
fuzz.com, and has a top level that is not WebDAV-aware, called A/.
Below A/ is an advanced collection had references).

4.5.1 COPY for Direct References

COPY follows the general principle that operations on direct references
are applied is bound to the target resource unless the No-Passthrough header both 1/ and one/. In
collection one/ there is
used.  A COPY on a direct reference MUST be applied to its target resource unless called index.html.

>> Request:

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

>> Response:

HTTP/1.1 201 Created

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

1. U is used, then empty.
2. The base URL, B, is http://www.fuzz.com/A/, since A/ is not WebDAV-
aware.
3. Since there are two domain names for this server, the COPY MUST be applied domain name
variations of B are added to U, making U contain: http://www.fuzz.com/A/
and http://fuzz.com/A/.
4. (iteration 1) The next path segment of the direct
reference rather than Request-URI is 1/, which
is bound to its target.

For consistency, an advanced collection resource, R.
5. (iteration 1) Since the same is true when a COPY request advanced collection resource R is sent bound to a
collection, 1/
and direct references are encountered inside one/, the collection.
Unless value of U after the No-Passthrough header operation is:
http://www.fuzz.com/A/1/, http://www.fuzz.com/A/one/,
http://fuzz.com/A/1/, and http://fuzz.com/A/one/.
6. Go back to step 4, since there is present on the request, one more path segment in the targets
Request-URI.
4. (iteration 2) The next path segment of the direct references MUST be copied into the new collection.  If the
No-Passthrough header Request-URI is used, then the direct references, and not their
targets, MUST be copied into the new collection.

These semantics yield intuitively correct results when a COPY request info.html,
which is

sent bound to an individual reference.  It is less clear that HTML resource, R.
5. (iteration 2) Since the results are
intuitive when a COPY request HTML resource is sent bound to a collection containing direct
references, but consistency dictates that we follow info.html and
index.html, the same semantics
for this case.  A design principle that is followed throughout this
specification is that a method behaves value of U after the same when it is sent to operation is:
http://www.fuzz.com/A/1/index.html, http://www.fuzz.com/A/1/info.html,
http://www.fuzz.com/A/one/index.html,
http://www.fuzz.com/A/one/info.html, http://fuzz.com/A/1/index.html,
http://fuzz.com/A/1/info.html, http://fuzz.com/A/one/index.html,
http://fuzz.com/A/one/info.html.
6. Since there are no further path segments in the
URI of a reference as it does when it is sent to a Request-URI, U now
has the URI complete set of a
collection and encounters a reference inside that collection.

4.5.2 COPY URI mappings for Redirect References

For redirect references, the normal behavior would be to respond to a
request with a 302 (Moved Temporarily) status code, allowing the client
to resubmit the request to the target resource identified in by the
Location
Destination header.  This would also yield intuitively correct behavior for
COPY.  However, it seems undesirable to respond to a COPY request on a
collection with a Multi-Status including a 302 response

4.2.5 Status Codes

201 (Created): The binding was successfully created.

400 (Bad Request): The client set an invalid value 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 MUST be applied to the reference itself,
whether Destination
or not Position header.

409 (Conflict): Several conditions may produce this response.  The URI
in the No-Passthrough Destination header is present. not mapped to a resource.  The same request is true when
attempting to create a COPY binding in a collection that does not exist.  The
request is sent attempting to a collection, and
redirect references are encountered inside position the binding in an unordered
collection.  Whether or
not The request is attempting to re-bind the No-Passthrough top-level
collection.

412 (Precondition Failed): The Overwrite header is present on the request, "F", and a binding
already exists for the redirect
references themselves are copied into the new collection, and 302 status
codes are not returned for them.

4.5.3 request-URI.

4.2.6 Example: COPY on a Direct Reference BIND

>> Request:

COPY /MyCollection/tuva

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

>> Response:

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

In this example, the request-URI identifies 201 Created

The server created a direct reference whose
target new binding, associating "spec08.txt" with the
resource is identified by
http://www.svr.com/Asia/History/tuva.html.  This target resource was
copied to the destination location in the Destination header,
http://www.svr.com/OtherCollection/tuva.html.  The headers included with URL "http://www.ics.uci.edu/pub/i-d/draft-
webdav-protocol-08.txt".  Clients can now use the response insure Request-URI,
"http://www.ics.uci.edu/~whitehead/dav/spec08.txt", to submit requests
to that resource.  As part of this operation, the client knows that it was operating on a
direct reference, and that server added the client knows which resource was copied.

4.5.4
binding "spec08.txt" to collection /~whitehead/dav/.

4.2.7 Example: COPY on a Redirect Reference BIND Conflict

>> Request:

COPY /MyCollection/tuva

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

>> Response:

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

In this example, 409 Conflict

The client requested the request-URI identifies server to create a redirect reference whose
target binding between "prlogo.gif"
and the resource is identified by
http://www.svr.com/Asia/History/tuva.html.  In this case, the reference
was copied to URL "http://www.softcorp.com/logos/".
Since the destination location Destination does end in a slash, while the Destination header,
http://www.svr.com/OtherCollection/tuva.html.  The Ref-Type header
included with Request-URI does
not, the response informs server failed the client that it was operating on request, returning a
redirect reference. 409 (Conflict) status
code.

4.2.8 DELETE and Bindings

The Ref-Target header provides DELETE method requests that the information server remove the
client needs to copy binding between
the target resource, should it wish to do so.

The result would have been exactly resource identified by the same, Request-URI and the response would have
been exactly binding name, the same (except that
last path segment of the Ref-Target header would Request-URI. The binding MUST be
OPTIONAL), had removed from
its parent collection, identified by the No-Passthrough Request-URI minus its trailing
slash (if present) and final segment. The All-Bindings header been may be
used in with DELETE to request that 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 are involved, it is not possible server remove all bindings to follow the rules in
[WebDAV] Section 8.8.3 for reducing
resource identified by the length of responses Request-URI.

Once all bindings to COPY
requests.  Although the entire COPY operation in resource are removed, the example was
successful, server MAY reclaim
system resources associated with the resource. If DELETE removes a Multi-Status response is still REQUIRED, so
binding to a resource, but there remain other bindings to that resource,
the
DAV:reftype and DAV:reftarget properties can be returned for the
references in the collection.  The results for each reference server MUST be
reported in a separate DAV:response element so that it is clear which
reference is NOT reclaim system resources associated with which values the
resource.

Since DELETE as specified in [WebDAV] is not an atomic operation, it may
happen that parts of DAV:reftype and
DAV:reftarget. the hierarchy under the request-URI cannot be
deleted.  In this case, since /MyCollection/tuva is a direct
reference, its target resource was copied into the new collection.
Since /MyCollection/nunavut response is a redirect reference, as described in [WebDAV].

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

not its target, was copied into distinguish between bindings and resources, the new collection.  There
are no response elements for intent of its
definition of DELETE is unclear.  We consider the collection /MyCollection/ or for definition presented
here to be a clarification of the
ordinary resource /MyCollection/diary.html, since they were successfully
copied and no special information needs to be returned for them.

4.6 Deleting and Moving Referential Resources

The DELETE method is used to delete referential resources.  For both
direct and redirect references, DELETE MUST affect the reference itself,
and not its target.  Similarly, when a definition in [HTTP].

Section 8.6.1 of [WebDAV] states that during DELETE on a collection encounters processing, a reference in server
"MUST remove any URI for the subtree under that collection, it MUST delete resource identified by the
reference, and not its target.

A MOVE operation on Request-URI from
collections which contain it as a referential resource MUST move member."  Servers that support
bindings SHOULD NOT follow this requirement.

4.2.9 COPY and Bindings

As defined in Section 8.8 of [WebDAV], COPY causes the referential resource
identified by the Request-URI to a different location, be duplicated, and MUST NOT change makes the location new
resource accessible using the URI specified in the Destination header.
Upon successful completion of
its target. The DAV:reftarget property is unchanged after a MOVE.
Similarly, when a MOVE on a collection encounters COPY, a reference in new binding is created between
the
subtree under that collection, it MUST move last path segment of the reference, and not its
target.

DELETE Destination header (including trailing "/",
if present), and MOVE differ from other methods in that they do not alter the
resource that destination resource. The new binding is being deleted or moved, but rather added to
its parent collection, identified by the collection that
contains Destination header minus its URI.  They change
trailing slash (if present) and final segment.

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

When

As an example, suppose that a reference COPY is added issued to a collection, the aim URI 3 for resource R
below (which is also mapped to make it look as
if URI 1 and URI 2), with the target resource were a member Destination
header set to URIX.  After successful completion of that collection.  When the
reference is removed from that collection, the aim COPY operation,
resource R is duplicated to change create resource R', and a new binding has
been created which creates at least the
membership of that collection.  Membership of URI mapping between URIX and the target in any
new resource (although other
collections, either internally or by reference, should not be affected.
Consequently, DELETE URI mappings may also have been created).

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

4.2.10 MOVE and Bindings

The MOVE do not follow method has the normal rules effect of behavior
for references.  Instead, they are always applied creating a new binding to a resource
(at the reference
itself, not to its target, Destination), and they never result in 302 status codes.

Although clients MAY use removing an existing binding (at the No-Passthrough header with DELETE and MOVE
requests, Request-
URI). The name of the header has no effect on their behavior.  Whether new binding is the No-
Passthrough header last path segment of the
Destination header, and the new binding is present or not, they are always applied added to its parent
collection, identified by the
reference.

[WebDAV] defines Destination header minus its trailing
slash (if present) and final segment.

As an example, suppose that a MOVE is issued to be logically equivalent to COPY followed by
DELETE.  For direct references, MOVE URI 3 for resource R
below (which is logically equivalent also mapped to COPY URI 1 and URI 2), with the No-Passthrough Destination
header followed by DELETE.

4.7 Locking Referential Resources

The semantics of LOCK described here resulted from balancing a set to URIX.  After successful completion of
incompatible considerations:

o Ideally, a LOCK on a reference should lock both the reference MOVE operation,
a new binding has been created which creates at least the URI mapping
between URIX and its
  target resource. resource R (although other URI mappings may also have
been created).  The owner of an exclusive write lock, for example,
  would be surprised if anyone else could modify binding corresponding to the content final segment of the
  target resource while he held the lock.  He would URI 3
has been removed, which also be surprised
  if anyone else could delete the reference to it, or replace causes the
  reference with one pointing URI mapping between URI 3 and R
to a different target.

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

o Preserve removed.

>> Before Request:

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

>> After Request:

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

Since MOVE as specified in [WebDAV] is not an atomic operation, it may
happen that parts of the clear distinction between redirect and direct
  references.  Redirect references should hierarchy under the request-URI can be simple for servers to
  implement. moved.
In particular, a server should never have to resolve a
  redirect reference.  A server should not have to provide proxy
  capabilities this case, the response is as described in order to implement redirect references.  Direct
  references rely [WebDAV].

4.2.10.1 Implementation Note

In some situations, particularly when the destination is on more sophisticated a different
server capabilities to give
  clients from the illusion of operating directly on original resource, the target resource.

o There should be server may implement MOVE by
performing a COPY, performing some consistency between the behavior of LOCK maintenance on a single
  referential resource bindings
and the behavior of LOCK on properties, and then performing a collection that
  contains referential resources.

o Keep DELETE. In the behavior of end, all requests of the
original bindings except the one corresponding to references as consistent as
  possible.  Try the Request-URI will
be associated with the new resource. The binding corresponding to adhere the
URI in the Destination header will be associated with the new resource.
And the original resource together with the binding corresponding to the general rule that
Request-URI will have been deleted. This implementation is in accord
with the absence definition of a
  No-Passthrough header, all methods return a 302 when sent to a
  redirect reference MOVE in [WebDAV], and are applied is logically equivalent to
the target when sent to a
  direct reference.

o Be consistent with definition given above.

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

The DAV:creationdate property of the LOCK semantics defined in [WebDAV].

We new resource SHOULD have compromised the intuitive locking behavior and support for non-
referencing clients in order to preserve various sorts same
value as the DAV:creationdate property of consistency.

4.7.1 LOCK on Direct References

LOCK follows the general principle that operations on direct references
are applied to old resource.

The DAV:getlastmodified property of the target new resource unless SHOULD have the No-Passthrough header is
used.  When a LOCK request is sent to a direct reference without
same value as the No-
Passthrough header, DAV:getlastmodified property of the target old resource.

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

Consider again the case where a LOCK
request MOVE is issued to URI 3 for resource R
(which is also mapped to URI 1 and URI 2), with the No-Passthrough Destination header is sent
set to a direct reference, URIX.  Unlike the reference itself MUST be locked.

A principle followed throughout previous example, in this specification is that behavior when
a reference is encountered during an operation on a collection must be implementation, after
successful completion of the same MOVE operation, resource R has been

duplicated as behavior when operating on an individual reference.  When a
LOCK request resource R'.  The original bindings corresponding to URI 1
and URI2 are now associated with Depth > 0 is sent R'.  The binding corresponding to the
Request-URI (URI 3) has been removed.  And a collection, new binding has been
created which creates at least the targets of any
direct references encountered MUST be locked, unless URI mapping between URIX and resource
R'. Note that the No-Passthrough
header is used.  If server may reclaim the No-Passthrough header is present on a LOCK
request storage associated with Depth > 0 to a collection, then any direct references
encountered MUST themselves be locked.

As was noted above, more intuitive results would have been obtained by
requiring that both
resource R once the reference MOVE operation has finished.

>> Before Request:

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

>> After Request:

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

4.2.11 LOCK and its target to be locked UNLOCK

Bindings do not affect the semantics of locks, as specified in
response to a [WebDAV].
Specifically, the requirement in section 8.10.3 that "a LOCK request.  Reference-aware clients request on
a resource MUST NOT succeed if it can obtain this
result not be honored by performing two all the URIs
through which the resource is accessible" still holds.  The LOCK operations, one with method
locks the No-Passthrough
header resource, and one without.  Non-referencing clients cannot do so.  This
means that for non-referencing clients there a lock is always the risk visible via all URIs mapped to that
resource. Similarly, a
referencing client may delete or replace the reference that was used successful UNLOCK issued via any URI mapping to
lock a target
resource while removes the non-referencing client has lock from the target
locked.  To insure intuitive results for non-referencing clients,
referencing clients SHOULD resource, and this lock removal is
visible via all URI mappings.

When a resource is locked, the lock owner expects to be designed able to check whether access
the target resource is locked before replacing, moving, or deleting a direct
reference.

UNLOCK behaves as specified in [WebDAV], unlocking all resources
included in -- using the same Request-URI that he used to lock identified by the Lock-Token header.

4.7.2 LOCK on Redirect References

The behavior of LOCK for redirect references was determined by what is
possible
resource -- for as long as he holds the case lock.  This would not be
possible if another user could move or delete any of locking the collections that contain redirect
references.

The expected behavior
corresponding to segments of the request-URI.

Consequently, for any operation on a redirect reference is that
a 302 (Moved Temporarily) response will be returned, unless the No-
Passthrough header is used.  However, this policy would have
unacceptable consequences when locking duration of a collection that contains
redirect references.  Since [WebDAV} requires LOCK on lock, it MUST NOT be possible for a collection
principal other than the lock owner to be
an atomic operation, if make a 302 response is received for locked resource
inaccessible via the URI mapping used to lock the resource.  Only the
lock owner can move or delete any member of the
collection, collections corresponding to
segments of the entire LOCK must fail. Request-URI. This would make it impossible restriction does not prevent others
from modifying those collections, by adding members to
lock any collection that contained them, removing
members from them, or changing their property values.

For example, if a redirect reference.

To avoid this result, a LOCK on a collection with Depth > 0 MUST lock
any redirect references user locks /plants/herbs/rosemary.html, it encounters, and is not return 302 responses
possible for
them, whether another user to move /plants/herbs/ to
/plants/flowering/herbs/, or not the No-Passthrough header to completely delete /plants/herbs/, though

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

4.2.12 Bindings and Other Methods

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

For most of these methods, no new complexities are introduced by
allowing explicit creation of multiple bindings to resolve the redirect reference or become a proxy server in cases
where same resource.
For the target resides on a different server.

Each DAV:response element for access operations (GET, HEAD, OPTIONS, and PROPFIND), it is
simply the case that no matter which URI mapping to a redirect reference MUST include given resource is
used as the
DAV:reftype and DAV:reftarget properties so Request-URI, the response is mediated by that same resource.
The responses may, however, vary depending upon which Request-URI was
used.  For example, the response to a referencing client
can lock GET request may contain the targets if it wishes.  (There will be no hint
Request-URI in any its entity.

The same is true for POST.  No matter which URI mapping to a given
resource is used as the Request-URI, the response code is mediated by that there are redirect references whose targets need to
be locked.
same resource.  The client will most likely not lock any targets until it
attempts an operation changes made on the target server and gets a 302 response.)  Non-

referencing clients cannot lock the targets of the redirect references
and may never realize that responses may,
however, vary depending upon which Request-URI was used.

If the targets have not been locked.

Clearly, Request-URI of a LOCK with Depth = infinity on PUT identifies an existing resource, then a collection PUT
via one URI mapping to this resource MUST NOT follow
any redirect references whose targets are collections into produce the target
collections; it MUST NOT cause same result as a
PUT with the same headers and request entity body via any members of those target collections other URI
mapping to be locked. the same resource. The behavior of LOCK change made by a PUT via one URI
mapping MUST affect the resource that generates the GET response for individual redirect references is designed all
URI mappings to the same resource.

A PROPPATCH through one URI mapping to
be consistent with LOCK behavior for collections that contain redirect
references.  Whether or not a No-Passthrough header is present, a LOCK
on a redirect reference resource MUST lock only produce the reference, not same
changes to its target,
and it MUST NOT return a 302 response.  The response MUST include properties as the
Ref-Type and Ref-Target headers, so that same PROPPATCH request through a referencing client can lock
different URI mapping to the target resource if it wishes.

UNLOCK behaves as same resource.

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

The semantics of MKREF are specified in Section 4.5.1 below.  A MKREF
through one URI mapping to a resource MUST produce the lock identified by the Lock-Token header.

4.7.3 Example: LOCK on same result as a Direct Reference

Request:

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

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

Response:

HTTP/1.1 200 OK
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,
MKREF with the request-URI identifies a direct reference whose
target resource is identified by
http://www.svr.com/Asia/History/tuva.html.  This target resource was
locked.  The Ref-Type and Ref-Target same headers included through any other URI mapping to the same
resource.  By default, it overwrites the resource with a new redirect
reference.

The semantics of ORDERPATCH are specified in 5.5.1 below.  An ORDERPATCH
through one URI mapping to a collection MUST produce the response
insure that same changes to
its ordering as the client knows that it was operating same ORDERPATCH request through any other URI
mapping to the same collection.

4.2.13 Discovering the Bindings to a Resource

An OPTIONAL DAV:bindings property on a direct
reference, and that resource provides a list of the
bindings that associate URI segments with that resource. By retrieving
this property, a client knows which can discover the bindings that point to the
resource was locked.

4.7.4 Example: LOCK on a Redirect Reference

4.7.5 Example: LOCK and the collections that contain bindings to the resource.  As

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

Rationale: A number of scenarios require clients to navigate from a Collection That Contains a Direct Reference
resource to the bindings that point to it, and
a 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 to the entire LOCK operation was successful, a Multi-Status
response is still REQUIRED, so collections that
contain those bindings.  This capability is particularly important for
Document Management Systems.  Their clients may need to determine, for
any object in the DAV:reftype and DAV:reftarget
properties DMS, what collections contain bindings to that object.
This information can be returned used for the references upward navigation through a hierarchy
or to discover related documents in other collections.

Risks: When deciding whether to support the collection.  The
results for each reference MUST be reported in a separate DAV:response
element so that DAV:bindings property,
server implementers / administrators should balance the benefits it is clear which reference is associated with which
values
provides against the cost of DAV:reftype maintaining the property and DAV:reftarget.  In this case, since
/MyCollection/tuva is a direct reference, its target resource was
locked.  Since /MyCollection/nunavut is the security
risks enumerated in Sections 12.5 and 12.6.

4.3 Redirect References

For most operations submitted to a redirect reference, the
reference itself, and not its target, was locked.  There is no response
element for is a
302 (Moved Temporarily), accompanied by the ordinary resource /MyCollection/diary.html, since it was
successfully locked Resource-Type header
(defined in Section 6.2 below) set to "DAV:redirectref" and no special information needs the Location
header set to be 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 use the references created by
reference-aware WebDAV clients.  They should be able to follow any
references to their targets.  To make this possible, a server that
receives a PROPFIND, PROPPATCH, MKCOL, or MKREF request made via a
redirect reference MUST return a 302 (Moved Temporarily) status code.
The client and server MUST follow [HTTP] Section 10.3.3 "302 Moved
Temporarily," but with these additional rules:

o The Location response header MUST contain the target URI of the
  reference.

o The response MUST include the Ref-Type header.  This header allows
  reference-aware WebDAV clients to recognize the resource as a
  reference and understand the reason for target resource.  With this information,
the redirection.

A reference-aware WebDAV client can act on this response in one of two
ways.  It can, like a non-referencing client, resubmit the request to the URI in the Location header in order to operate on of the target resource.  Alternatively, it can resubmit the request to the URI of the
The methods COPY (for collections containing redirect reference with the No-Passthrough header in order to operate on
the reference itself.  If the No-Passthrough header is present, the
request MUST references),
DELETE, MOVE, and LOCK, for reasons that will be explained, are
exceptions to this general behavior. These exceptional operations are
applied to the reference itself, itself and do not result in a 302 response MUST
NOT be returned. response.

If a reference-aware the client knows before submitting its request is aware that the
request-URI identifies it is operating on a redirect reference, it
can save resolve the round trip
caused reference by retrieving the 302 response by using No-Passthrough reference's DAV:reftarget
property (defined in its initial
request to the URI.

Since MKCOL and MKREF fail when applied to existing resources, if Section 7.1 below), whose value is the
client attempts to resubmit URI of the request
target resource.  It can then submit requests to the target resource, the
request MUST fail (unless the resource.

A redirect reference is a dangling reference).
Similarly, if the client attempts to resubmit the request to the
reference with a No-Passthrough header, the request MUST fail.

4.8.1 Example: PROPPATCH on a Redirect Reference

4.9 Other WebDAV Operations on Direct Referential Resources

With the exception new type of DELETE and MOVE, which were discussed above,
operations on direct resource. To distinguish redirect
references affect the target resource, not the
reference, unless the No-Passthrough header is used.

Unless the No-Passthrough header is used, a PROPPATCH on from ordinary resources, a direct
reference MUST modify the properties of its target resource, not the
properties new value of the reference itself.

Unless the No-Passthrough header DAV:resourcetype
property (defined in [WebDAV]), DAV:redirectref, is used, a PROPFIND on defined in Section
8.1 below.

Since a direct redirect reference MUST return the properties of its target is a resource, not the
properties of it is possible to apply
methods to the reference itself.

If the No-Passthrough rather than to its target.  The Passthrough
request header (defined in Section 6.4 below) is used with a PROPPATCH or PROPFIND

request on a direct reference, the provided so that
referencing-aware clients can control whether an operation MUST be is applied to
the redirect reference itself rather than or to its target resource.

MKCOL and MKREF fail if their request-URI identifies an existing
resource of any kind.  Consequently, when submitted  The Passthrough
header can be used with most requests to a target resource
via a direct reference, they MUST fail unless the reference is a
dangling reference.  If they are submitted to an existing direct
reference redirect references.  This
header is particularly useful with PROPFIND, to retrieve the No-Passthrough header, they MUST also fail.

4.9.1 Example: PROPPATCH on reference's
own properties.

4.3.1 MKREF Method

The MKREF method creates a Direct Reference

4.10 HTTP Operations on Redirect Referential Resources

Although existing HTTP clients cannot create referential resources, they
should be able to use collections created redirect reference resource identified by reference-aware WebDAV
clients.  They should be able to follow any references the
Request-URI, whose target is identified by
URIs in those collections to their targets.  To enable existing HTTP
clients the REQUIRED Ref-Target
header. MKREF sets the value of the REQUIRED DAV:reftarget property to use GET, HEAD, PUT, POST, or OPTIONS via redirect references,
a server that receives any
the value of these requests on the Ref-Target header.

The MKREF method creates a new binding between the new redirect

reference
MUST return a 302 (Moved Temporarily).  The client resource and server MUST
follow [HTTP] Section 10.3.3 "302 Moved Temporarily," but with these
additional rules:

o The Location response header MUST contain the target URI last path segment of the
  reference.

o Request-URI.  The response MUST include the Ref-Type header.  This header allows
  reference-aware WebDAV clients
new binding is added to recognize its parent collection, identified by the resource as a
  reference
Request-URI minus its trailing slash (if present) and understand final segment.

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

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

By default, if the redirection.

Reference-aware clients can act on a 302 response in either Request-URI of two ways.
Like plain HTTP clients, they can resubmit the MKREF request to identifies an
existing resource, the URI in server MUST perform a delete operation on the
Location header (the URI of
existing resource before performing the target resource).  They may, however,
want to operate on MKREF. This default behavior can
be overridden using the Overwrite header defined in Section 9.6 of
[WebDAV].

4.3.1.1 Status Codes

201 (Created): The redirect reference rather than on its target.  In resource was successfully created.

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

409 (Conflict): Several conditions may produce this
case, they response.  There may resubmit
be no resource at the location specified in Ref-Target, on a server that
prohibits dangling references.  The request may be attempting to the URI of create
the reference and
include the No-Passthrough header with the request.  If in a collection that does not exist.  The request may be
attempting to position the No-
Passthrough header reference before or after a resource that is present,
not in the collection, or before or after itself.  The request MUST may be applied
attempting to position the reference itself, in an unordered collection.

412 (Precondition Failed): The Overwrite header is "F", and a 302 response MUST NOT be returned.

If a reference-aware client knows before submitting its resource
already exists at the request-URI.

4.3.1.2 Example: MKREF

>> Request:

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

>> Response:

HTTP/1.1 201 Created

This request that resulted in the
request-URI identifies creation of a new redirect reference, it can save reference at
www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the round trip
caused resource
identified by the 302 response Ref-Target header. In this example, the target
resource of the referential resource is identified by using No-Passthrough in its initial
request to the URI. URI
http://www.ics.uci.edu/~whitehead/dav/i-d/draft-webdav-protocol-08.txt.
The No-Passthrough header can be used with GET or HEAD to retrieve referential resource's DAV:resourcetype property is set to
DAV:redirectref.  Its DAV:reftarget property is set to the
entity headers value of a redirect reference.  When No-Passthrough is used
with GET or HEAD, the referencing entity headers (Ref-Type and Ref-
Target) MUST be returned, along with all HTTP headers that make sense
for references (at a minimum, Cache-Control, Age, ETag, Expires, and
Last-Modified).

The No-Passthrough header can be used with PUT to replace
Ref-Target header, "/i-d/draft-webdav-protocol-08.txt".

4.3.2 Listing the Redirect References in a Collection

A URI of a redirect reference with an ordinary resource.  It can be used with OPTIONS to
retrieve the capabilities an internal member URI of a redirect reference.

Clients MUST NOT, however, use the No-Passthrough header with POST.
Since a reference cannot accept another entity
collection just as its subordinate, the URI of an
attempt to POST to a reference with No-Passthrough will also fail.  If ordinary resource can.  A listing of
the internal member URIs of a
server receives collection shows all of the URIs that are
internal members of the collection, whether they identify redirect
references or ordinary resources.  That is, a POST WebDAV PROPFIND request on
a collection resource with the No-Passthrough Depth header on set to 1 or infinity MUST
return a response XML element for each member URI in the collection,
whether it identifies an ordinary resource or a redirect reference.

For each redirect reference, it MUST fail the request with response element MUST contain a 400 (Bad Request) 302
(Moved Temporarily) status code.

4.10.1 Example: GET on a Redirect Reference

4.10.2 Example: GET on code unless a Redirect Reference Passthrough header with No-Passthrough

4.11 HTTP Operations on Direct Referential Resources

GET, HEAD, PUT, POST, and OPTIONS on direct references are automatically
passed through to their target resources.  GET MUST return the content
value "F" is included with the PROPFIND request.  The DAV:location and headers
DAV:resourcetype properties MUST be included with the 302 status code,
extending the syntax of the target resource, HEAD MUST return DAV:response element that was defined in
[WebDAV] as described in Section 9 below.  A referencing-aware client
can tell from the headers DAV:resourcetype property that the collection contains
a redirect reference.  The DAV:location property contains the absolute
URI of the target resource, PUT MUST replace resource.  A referencing-aware client can either use
the content URI value of the target resource,
POST MUST perform DAV:location property to retrieve the expected function at properties of
the target resource, and
OPTIONS MUST report or it can submit a PROPFIND to the communication options available at redirect
reference with "Passthrough: F" to retrieve its properties.  It is
recommended that future editors of [WebDAV] define the target
resource.

The No-Passthrough request header MAY DAV:location
property in [WebDAV], so that non-referencing clients will also be used with GET, HEAD, PUT, or
OPTIONS able
to view use the headers or capabilities response to retrieve the properties of the reference, rather
than its target.

The No-Passthrough request target resource.

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

The Passthrough header (defined in Section 6.4) MAY be used with POST, which
cannot be applied to references.  If a server receives a POST
PROPFIND request on a direct reference with the No-Passthrough header, it MUST fail the
request with a 400 (Bad Request) status code.

4.11.1 collection.

4.3.2.1 Example: GET PROPFIND on a Direct Reference

4.11.2 Example: GET on Collection with Redirect References

Suppose a Direct Reference PROPFIND request with No-Passthrough

4.12 Operations on Targets of Referential Resources

In general, operations on targets of weak referential resources have no
effect on the referential resource.  However, servers that choose Depth = infinity is submitted to
maintain the integrity of references are free to make changes
following collection, with the members shown here:

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

>> Request:

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

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

>> Response:

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

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

In this example the Depth header is set to infinity, and the
state of references when moving or deleting their targets.

When moving a target resource, Passthrough
header is not used.  The collection contains one URI that identifies a server MAY insert an optional step into
the semantics of MOVE as defined in [WebDAV]
redirect reference.  The response element for the purpose redirect reference has
a status of
maintaining referential integrity.  Between 302 (Moved Temporarily), and includes a DAV:prop element
with the copy step DAV:location and DAV:resourcetype properties to allow clients
to retrieve the delete
step properties of a MOVE, its target resource.  (The response
element for the server MAY perform an update step, which changes redirect reference does not include the
DAV:reftarget property of any references requested
properties.  The client can submit another PROPFIND request to the target URI
in the DAV:location property to reflect its
new location.

When deleting retrieve those properties.)

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

Suppose a server MAY perform any internal
operations necessary to implement its policy on preserving referential
integrity.  For example, it might delete any references PROPFIND request with Passthrough = F and Depth = infinity is
submitted to the deleted
target, or it might flag them as having a deleted target, or it might
replace references following collection, with copies the members shown here:

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

>> Request:

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

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

>> Response:

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

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

Since the Passthrough header has the value "F", the response shows the
properties of the redirect reference in the collection rather than the
properties of its target.

4.13 Discovering The value of the Passthrough header also
prevents a Target’s References

An OPTIONAL DAV:references property on 302 response from being returned for the target resource provides redirect reference.

4.3.3 Copying Redirect References

A client's intent in performing a
list of referential resources whose DAV:reftarget property points to
that target resource.  If present, DAV:references COPY operation is to create a read-only
property, maintained by the server.  By retrieving this property, a
client can discover the URIs of the references new
resource that point is similar to the target, original resource and so can also discover behaves like the collections
original resource, and that contain those URIs as
members.  As for all DAV: properties, this specification is silent as to
how the DAV:references property is implemented on the server.

The DAV:references property is expected to can be supported mainly by
Document Management Systems (DMSs) and other servers that will maintain modified without affecting the property only for references within their own domain.  It is not in
general possible for
original resource.  For a server COPY request to maintain the property for references on
other servers.  If a reference on redirect reference, the
expectation would be a different server points 302 response that the client could use to copy
the
target, target resource.  This would yield an independent resource that
could be modified without affecting the server where original resource.  For COPY
requests to collections that contain redirect references, the target situation
is located less clear.  There is unlikely to know about
that reference.  This protocol provides no mechanism for one server to
notify another of tension between two expectations. On the creation of a reference to one of its resources.
Consequently,
hand, the list of references in DAV:reftarget client may be incomplete.

Rationale: A number expect the new copy of scenarios require clients to navigate from a
target resource the collection to behave
like the old one (which implies having references that point to it, and to where the
collections that contain old one had
references).  On the URIs of those references.  This capability
is particularly important for DMSs, which may populate their collections
entirely by reference.  Their clients may need to determine, for any
object in other hand, the DMS, what collections contain URIs client may expect that identify
references it will be
possible to that object.  It is also important modify the resources 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
environment, the client must be able to discover new collection without affecting
the references resources in order
to delete them before attempting to delete the target.

Risks: When deciding whether to support the DAV:references property,
server implementers / administrators should balance the benefits it
provides against the cost old collection (which implies having copies of maintaining the property and the security
risks enumerated in Sections 12.4 and 12.5.

4.14 Behavior of Dangling Direct References

Whenever
targets where the No-Passthrough header accompanies original collection had references).

For a COPY request on a dangling
direct an individual reference, the request succeeds.  Since No-Passthrough causes the
request to response MUST be applied to a
302 (Moved Temporarily) status code, with the reference rather than to its target, it
does not matter that URI of the target resource does not exist.  The client
will not be informed that the reference points to a nonexistent target.

In the absence of
in the No-Passthrough Location header, the responses MUST be as
follows:

GET, HEAD, OPTIONS, POST, PROPFIND, PROPPATCH, LOCK, UNLOCK, and COPY
respond with 404 (Not Found), but "Resource-Type: DAV:redirectref" to
distinguish the Ref-Type and Ref-Target headers
are included in response from an ordinary HTTP redirect.  This is the response, so that
normal behavior for redirect references, allowing the client can tell that it is to resubmit
the
target, and not request to the reference, that was not found.

If, however, target resource identified in the Location header.
This also yields intuitively correct behavior for a PROPFIND, LOCK, UNLOCK, or COPY with Depth request to an
individual reference.  Reference-aware clients can use the Passthrough
header greater
than 0 with the value "F" to copy the redirect reference itself.

For COPY on a collection encounters a dangling direct reference inside the

collection, the response is containing redirect references, different

semantics may be desirable in different scenarios.  Consequently, this
specification makes a 207 (Multi-Status).  The DAV:response
element for fairly arbitrary choice to take the dangling reference will have simplest path.
When a status of 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 COPY request is submitted to a collection containing redirect
references, the target, not server MUST copy the reference, that was not found.  Including these
two properties requires an extension redirect references to the DAV:response element as
defined in {WEBDAV]. new
collection rather than returning 302 status codes for them.  This extension is defined will
result in Section 9 below.

PUT succeeds, creating a new resource at the location specified by collection that behaves like the
reference’s DAV:reftarget property.

MKREF old one, and MKCOL succeed, since there is no existing resource at avoids
responding with multiple 302 status codes, each of which the
target URI.

MOVE and DELETE succeed, since they always affect client
would have to process separately.  Reference-aware clients can force the reference
server to respond with 302 status codes rather than its target.  For MOVE, the reference at copying the destination will be
broken, just as
references by using the reference at Passthrough header with the source was.

4.14.1 value "T".

4.3.3.1 Example: PROPFIND COPY on a Collection with a Dangling Direct Redirect Reference

>> Request:

PROPFIND /collection1/

COPY /MyCollection/tuva 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> www.svr.com
Destination: http://www.svr.com/OtherCollection/tuva.html

>> 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 302 Moved Temporarily
Location: http://www.svr.com/Asia/History/tuva.html
Resource-Type: DAV:redirectref

In this example, the request-URI identifies a No-Passthrough header is present, any operation on a direct redirect reference that whose
target resource is part of identified by
http://www.svr.com/Asia/History/tuva.html.  In this case, the server
responded with a chain of direct references MUST get passed
through to 302, and provided the target URL of the last reference target resource in the chain.

Whenever a response is required
Location header.  The Resource-Type header indicates to include the Ref-Target header, for a
chain of direct references, there MUST be reference-
aware client that this is not an HTTP 1.1 redirect, but a Ref-Target header for each reference in to
the chain.  In order for resource identified by the Location header.  The client can now
resubmit the COPY request to know which reference
in the chain each Ref-Target belongs to, target resource, producing the value of each Ref-Target
header MUST include desired
result: a hop-number duplicate of the reference as well as the URL original target resource that can be modified
independently of
its the original.

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

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

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

>> Request:

HEAD /math/ref1

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

>> 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 201 Created

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

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

4.3.4 Deleting and Moving Redirect References

The DELETE method is used to an
ordinary resource or delete bindings to another redirect references.
DELETE MUST affect bindings to the reference itself, unless
"Passthrough: T" is used, in which case it generates a chain of direct
references.  When 302 (Moved
Temporarily) response.  Similarly, when a break occurs before the end of DELETE on a chain of direct
references, the server’s behavior will be the same as for any other
dangling direct reference, as described in Section 4.13.  For example, collection
encounters a
PUT will create the new resource at the location specified by redirect reference in the
DAV:reftarget property of subtree under that collection, it
MUST delete bindings to the broken reference, even if that unless "Passthrough: T" is used,
in the
middle of what was once which case it generates a chain of direct references.

4.16 URIs and References

In 302 (Moved Temporarily) response. Whether
deleting an individual resource or a request-URI /segment1/segment2/segment3, any of the three segments
may identify collection, DELETE on a reference.  (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 redirect
reference does not affect the target of the path identifies reference.

A MOVE operation on a reference, that redirect reference MUST ultimately resolve move the reference to a resource that
behaves as a container.  (Examples are WebDAV collections, tar files,
different location, and some CGI scripts.)  The succeeding segment MUST NOT change the location of its target,
unless "Passthrough: T" is used, in which case a 302 (Moved Temporarily)
response is generated. The DAV:reftarget property is unchanged after a
MOVE.  Similarly, when a MOVE on a collection encounters a redirect
reference in the path subtree under that collection, it MUST resolve
to move the
reference, and not its target, unless "Passthrough: T" is used, in which
case a resource that 302 (Moved Temporarily) response is immediately contained generated.

DELETE and MOVE differ from other methods in that container.

Consider request-URI /x/y/z.html.  Suppose they do not alter the
resource that /x/ is a reference whose
target is being deleted or moved, but rather the collection /a/, which contains reference y whose target is
collection /b/, which that
contains its binding.  They change the membership of that collection.

When a redirect reference z.html whose target is
/c/d.html.

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

The server added to a collection, the aim is able to resolve make
it look as if the request-URI because each segment target resource were a member of that collection.
When the URI's path satisfies the constraints stated above.  Except for the
final segment, each segment reference is removed from that collection, the aim is a reference resolves to a collection change
the membership of that contains collection.  Membership of the next segment as an internal member.  The final
segment, which is a reference, does have a target resource.

If in any
other collections, either internally or by reference, should not be
affected.  Consequently, DELETE and MOVE do not follow the references normal rules
of behavior for references.  Instead, they are direct references, the server automatically
applies the request applied by default to the ultimate
reference itself, not to its target, /c/d.html.

If the references are redirect references, the client must follow up
three separate and by default do not result in 302 responses before finally reaching
status codes.

4.3.5 Locking Redirect References

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

o Ideally, a LOCK on a redirect reference should lock both the
  reference and its target resource.  The server responds to owner of an exclusive write
  lock, for example, would be surprised if anyone else could modify the initial request with a 302 with
Location: /a/y/z.html, and
  content of the client resubmits target resource while he held the request lock.  He would also
  be surprised if anyone else could delete the reference to
/a/y/z.html.  The server responds to this request it, or
  replace the reference with one pointing to a 302 with
Location: /b/z.html, and the client resubmits the request different target.
o Non-referencing clients should be able to /b/z.html. use redirect references
  without encountering surprising results.
o The server responds basic characteristics of redirect references should be honored.
  Redirect references should be simple for servers to this request with implement. In
  particular, a 302 with Location: /c/d.html,
and the client resubmits the request server should never have to /c/d.html.  This final request
succeeds.

5 Ordered Collections

5.1 Overview

Collections on resolve a compliant redirect
  reference.  A server may be ordered, but need should not be.  It
is up have to the client provide proxy capabilities in
  order to decide whether implement redirect references.
o There should be consistency between the behavior of LOCK on a single
  redirect reference and the behavior of LOCK on a given collection is ordered and,
if so, that
  contains redirect references.
o The behavior of all requests to specify redirect references should be as
  consistent as possible. In the semantics absence of a Passthrough header, all
  methods should return a 302 when sent to be used for ordering its members.  If a collection is ordered, each of its members must redirect reference.
o LOCK semantics for redirect references should be consistent with the
  LOCK semantics defined in [WebDAV].

We have compromised the ordering
exactly once, intuitive locking behavior and the ordering must not include any resource that is not
a member of the collection.  Only one ordering can be attached support for non-
referencing clients in order to any
collection.  Multiple orderings preserve various sorts of the same resources can be achieved consistency.

4.3.6 LOCK on Redirect References

The behavior of LOCK for redirect references was determined by
creating multiple what is
possible for the case of locking collections referencing those resources, and attaching
a different ordering to each collection. that contain redirect
references.

The server is responsible default behavior for enforcing these constraints any operation on orderings.
The server MUST remove a member URI from the ordering when it redirect reference is removed
from the collection. The server MUST add that a member URI to
302 (Moved Temporarily) response will be returned, unless the ordering
when it
Passthrough header with a value of "F" is added to the collection.

When responding to used.  However, this policy
has unacceptable consequences when locking a PROPFIND collection that contains
redirect references.  Since [WebDAV] requires LOCK on a collection, the server MUST order the

response elements according collection to the ordering defined on the collection.

5.2 Creating be
an Ordered Collection

5.2.1 Overview

When atomic operation, if a collection 302 response is created, received for any member of the client can request
collection, the entire LOCK must fail.  This would make it impossible to
lock any collection that contained a redirect reference.

To avoid this result, a LOCK with Depth > 0 on a collection MUST lock
any redirect references it be ordered encounters, and specify not return 302 responses for
them, unless the semantics Passthrough header with a value of "T" is used.  Use of
the ordering by using the new Ordered Passthrough header in the MKCOL request, setting its with a value to the URI of "T" in a LOCK request on a
collection will cause the
semantics to be used or setting its value entire lock to DAV:custom fail if a redirect reference is
encountered.

This gives part of the semantics
are not being advertised.  If the client does not want expected default lock behavior without forcing
the collection server to
be ordered, it may omit resolve the Ordered header, redirect reference or use it with the value
"DAV:unordered".

Every collection MUST have the new DAV:orderingtype property, which
indicates whether the collection is ordered and, if so, identifies the
semantics of the ordering.  A value of DAV:unordered indicates that that
collection is not ordered.  That is, become a proxy server in
cases where the client cannot depend target resides on the
repeatability of the ordering of results from a PROPFIND request.  For
collections different server.

There will be no hint in any response code that there are ordered, DAV:orderingtype SHOULD be set redirect
references whose targets need to be locked.  The client will most likely
not lock any targets until it attempts an href
that identifies the semantics of the ordering, allowing a human user or
software package to insert new collection members into the ordering
intelligently.  Although operation on the href MAY point to target and
gets a resource 302 response.  It is possible 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 non-referencing client may
never realize that the collection is to be ordered, but the semantics of the
ordering is reference's target has not being advertised.

If the Ordered header is present been locked.

Clearly, a LOCK with Depth = infinity on a MKCOL request, the server collection MUST set
the collection's DAV:orderingtype property to the value of the Ordered
header.  If NOT follow
any redirect references whose targets are collections into the Ordered header target
collections; it MUST NOT cause any resources in those target collections
to be locked.

The behavior of LOCK for individual redirect references is not present, the server designed to
be consistent with LOCK behavior for collections that contain redirect
references.  By default a LOCK on a redirect reference MUST treat lock only
the
request as if reference, not its target, and it had an Ordered MUST NOT return a 302 response.  A
reference-aware client can use the Passthrough header with the a value "DAV:unordered",
meaning that the collection is not ordered.  If the collection is
ordered, the server MUST respond of
"T" to PROPFIND requests on get a 302 response with the collection
using URI of the specified ordering.

5.2.2 Status Codes

Servers MUST use target resource in the HTTP/1.1 status codes
Location header.

UNLOCK behaves as defined specified in [HTTP].

5.2.3 [WebDAV], unlocking all resources
included in the lock identified by the Lock-Token header.

4.3.6.1 Example: Creating an Ordered Collection LOCK on a Redirect 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
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>

The request and response look exactly as specified in [WebDAV].  In this
example, the request-URI, http://www.svr.com/MyCollection/tuva,
identifies a new, ordered collection redirect reference, which was created.  Its
DAV:orderingtype property has as its value the URI from the Ordered

header.  In this case, the URI identifies 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.

5.3 Setting the Position successfully locked.  The
target resource of the redirect reference is not locked.

4.3.6.2 Example: LOCK on a Collection Member

5.3.1 Overview

When That Contains a new member Redirect
Reference, with Passthrough: T

Suppose a LOCK request is added submitted to a collection (for example, with PUT,
MKREF, or MKCOL), its position in the ordering can be set following collection, with
the new
Position header. members shown:

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

>> Request:

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

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

>> Response:

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

<?xml version="1.0" ?>
<D:multistatus xmlns:D="Dav:">
   <D:response>
      <D:href>http://www.svr.com/MyCollection/</D:href>
      <D:propstat>
         <D:prop><D:lockdiscovery/></D:prop>
         <D:status>HTTP/1.1 424 Failed Dependency</D:status>
      </D:propstat>
   </D:response>
   <D:response>
      <D:href>http://www.svr.com/MyCollection/diary.html</D:href>
      <D:status>HTTP/1.1 424 Failed Dependency</D:status>
   </D:response>
   <D:response>
      <D:href>http://www.svr.com/MyCollection/nunavut</D:href>
      <D:status>HTTP/1.1 302 Moved Temporarily</D:status>
      <D:prop>
         <D:location>
            <D:href>http://www.inac.gc.ca/art/inuit/</D:href>
         </D:location>
         <D:resourcetype><D:redirectref/></D:resourcetype>
      </D:prop>
   </D:response>
</D:multistatus>

The Position "Passthrough: T" header allows caused the client server to specify that return a 302 response
code for the member should be first redirect reference in the collection's ordering, last in collection.  Consequently,
neither the
collection's ordering, before some other collection member in nor any of the
collection's ordering, or after some other collection resources identified by its
internal member in URIs were locked.  A referencing-aware client can submit
a separate LOCK request to the
collection's ordering.

The server MUST insert URI in the new member into DAV:location property returned
for the ordering at redirect reference, and can resubmit the location
specified in the Position header, if one is present (and if the
collection is ordered); otherwise, it MUST append the new member LOCK request with
"Passthrough: F" to the
end of collection.  At that point both the ordering (if reference
and its target will be locked (as well as the collection is ordered).  If a PUT causes an
existing resource to be replaced, and if all the Position header is absent,
resources identified by its other members).

4.3.7 Other Operations on Redirect References

Although non-referencing-aware clients cannot create referential
resources, they should be able to use the references created by
reference-aware WebDAV clients.  They should be able to follow any
references to their targets.  To make this possible, a server that
receives a GET, HEAD, PUT, POST, OPTIONS, PROPFIND, PROPPATCH, MKCOL,
MKREF, BIND, or ORDERPATCH request made via a redirect reference MUST leave the member at its previous position in thee
collection ordering.  If the Position header is present, the
return a 302 (Moved Temporarily) status code. The client and server MUST
remove
follow [HTTP] Section 10.3.3 "302 Moved Temporarily," but with these
additional rules:

o The Location response header MUST contain the member from its previous position, and then insert it at absolute target URI of
  the
requested position.

5.3.2 Status Codes

Servers reference.

o The response MUST use include the HTTP/1.1 status codes Resource-Type header.  This header
  allows reference-aware WebDAV clients to recognize the resource as defined in [HTTP].  Some
likely client errors a
  reference and understand the reason for when setting the position redirection.

A reference-aware WebDAV client can act on this response in one of two
ways.  It can, like a collection
member include:

409 (Conflict): The non-referencing client, resubmit the request may be attempting to position
the collection
member before or after a URI that is not in the collection, or before or
after itself, or it may be attempting Location header in order to position operate on the collection member
in an unordered collection.

5.3.3 Examples: Setting target
resource.  Alternatively, it can resubmit the Position of a Collection Member

Request:

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

Response:

HTTP/1.1 201 Created

This request resulted in to the creation URI of a new referential resource at
www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the resource
identified by
redirect reference with the Ref-Target header.  The Position Passthrough header in this
example caused the server to set its position to "F" in order to
operate on the ordering of the

/~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 server returned a 409 Conflict status code because reference itself.  If the
/~whitehead/dav/ collection Passthrough header is an unordered collection.  Consequently, present
with a value of "F", the server was unable request MUST be applied to satisfy the Position header.

5.4 Changing the Semantics of reference
itself, and a Collection Ordering

After 302 response MUST NOT be returned.

If a collection has been created, reference-aware client knows before submitting its request that the
request-URI identifies a redirect reference, and if the client wants to
apply the method to the reference, it can change save the round trip caused by
the 302 response by using "Passthrough: F" in its ordering
semantics, or change an ordered collection initial request to an unordered collection the

URI.

"Passthrough: F" can be used with GET or
vice versa, by using PROPPATCH HEAD to change retrieve the value entity
headers of its
DAV:orderingtype property.  The client a redirect reference.  When "Passthrough: F" is then responsible for updating
the ordering of used with GET
or HEAD, the collection members according referencing entity headers (Ref-Type and Ref-Target) MUST
be returned, along with all HTTP headers that make sense for references
(at a minimum, Cache-Control, Age, ETag, Expires, and Last-Modified).

"Passthrough: F" can be used with PUT to replace the new semantics.
PROPPATCH is defined in [WebDAV], Section 7.2.

5.5 Changing redirect reference
with an ordinary resource.  It can be used with OPTIONS to retrieve the Position
capabilities of a Collection Member

5.5.1 The ORDERPATCH Method

To change the positions of collection members in the collection's
ordering, the client redirect reference.

Clients MUST NOT, however, use an ORDERPATCH request "Passthrough: F" with POST. Since a request body
containing an order XML element.  The request-URI of
reference cannot accept another entity as its subordinate, an ORDERPATCH attempt to
POST to a reference with "Passthrough: F" will also fail.  If a server
receives a POST request is the URI of with "Passthrough: F" on a redirect reference,
it MUST fail the collection whose ordering is request with a 400 (Bad Request) status code.

Since MKCOL fails when applied to be updated.
The order XML element identifies existing resources, if the member URIs whose positions are client
attempts to
be changed, and describes their new positions in resubmit the ordering.  Each new
position can be specified as first in request to the ordering, last in target resource, the
ordering, before some other collection member in request
MUST fail (unless the ordering, or after
some other collection member in reference is a dangling reference).  Similarly, if
the ordering.  The server MUST apply client attempts to resubmit the
changes in request to the order they appear in reference with
"Passthrough: F", the order element.

5.5.2 Status Codes request MUST fail.

Since multiple changes can be requested in a single ORDERPATCH request, applies only to collections, an ORDERPATCH request with
a Passthrough header with the server value "F" on a redirect reference MUST return
fail.

4.3.7.1 Example: GET on a 207 Multi-Status response, as defined Redirect Reference

>> Request:

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

>> Response:

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

Since /bar.html is a redirect reference and the Passthrough header is
not included in
[WebDAV].

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

200 (OK): response is a 302 (Moved Temporarily).
The change in ordering was successfully made.

409 (Conflict): An attempt was made to position the collection member
before or after Resource-Type header informs a URI reference-aware client that this 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 ordinary HTTP 1.1 redirect, but is a collection member to redirect reference.  The URI
of the same place target resource is provided in the
ordering is not an error.

5.5.3 Example: Changing Location header so that the Positions of Collection Members in
client can resubmit the
Ordering

Consider request to the target resource.

4.3.7.2 Example: PUT on a collection /coll-1/ Redirect Reference with members ordered as follows:

nunavut.map
nunavut.img
baffin.map
baffin.desc
baffin.img
iqaluit.map
nunavut.desc
iqaluit.img
iqaluit.desc "Passthrough: F"

>> Request:

ORDERPATCH /coll-1/

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

Content-Type: text/xml text/xml; charset="utf-8"
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> xxxx

. . . some content . . .

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

Although /bar.html 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 a redirect reference, the possibility presence of using the existing MOVE method with
"Passthrough: F" header prevents 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 302 response, and instead causes the semantics of MOVE make it
unsuitable for changing
request to be applied to the position of a collection member reference.  The result in this case is that
the
collection's ordering.  First, [WebDAV] defines MOVE as logically
equivalent to a copy followed reference is replaced by a delete of an ordinary resource having the source resource.  This
definition makes it impossible to MOVE content
submitted with the request.

4.3.7.3 Example: PROPPATCH on a resource to Redirect Reference

Request:

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

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

Response:

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

Since /bar.html is a destination URL
that redirect reference and the Passthrough header is
not included in the same as request, the source URL.  The resource would be deleted
rather than moved.  Second, [WebDAV] states that when moving response is a resource
to 302 (Moved Temporarily).
The Resource-Type header informs a destination where reference-aware client that this is
not an ordinary HTTP 1.1 redirect, but is a resource already exists, redirect reference.  The URI
of the Overwrite header
must be "T", and target resource is provided in this case the server must DELETE the resource at Location header so that the
destination before performing
client can resubmit the MOVE.  Again, this makes it impossible
to MOVE a resource request 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 resource.

4.3.8 Operations on Targets 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 Redirect References

Operations on targets 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 references have no effect on the chain.  Each value MUST include a
hop-count, starting with 0, indicating which reference
reference.

4.3.9 Relative URIs in the chain that Ref-Target belongs to.  For an example, see Section 4.14. and DAV:reftarget

The Coded-url URI in a Ref-Target header MAY be a relative URI.  If it is  Similarly, the
href in a DAV:reftarget property MAY be a relative URI, URI.  In both cases,
the base URI to be used for resolving it the relative URI to absolute form
has as its scheme component "http", as its authority component
is the value
of URI used in the Host: header from HTTP message to identify the request, and as redirect reference
to which the Ref-Target entity header or DAV:reftarget property belongs.

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

6.1.1

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

4.3.9.1 Example: Resolving a Relative URI in Ref-Target

>> Request:

PUT

MKREF /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

>> Response:

HTTP/1.1 201 Created

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

The
Then, following the rules in [URI] Section 5, the relative URI in Ref-Target 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

4.3.9.2 Example: Resolving a Ref-Type header with the
value DAV:redirect.

Servers MUST include the Ref-Target header Relative URI 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 DAV:reftarget

>> Request:

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

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

>> Response:

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

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

In this example, the server should enforce
referential integrity relative URI statistics/population/1997.html is
returned as the value of reftarget for a referential resource being created with
MKREF. the reference identified by href
/geog/stats.html.  The value "do-not-enforce" means that href is itself a relative URI, which resolves to
http://www.xxsrv.com/geog/stats.html.  This is the server MUST NOT enforce
referential integrity base URI for
resolving the newly created relative URI in reftarget.  The absolute URI of reftarget
is http://www.xxsrv.com/geog/statistics/population/1997.html.

4.3.10 Redirect References to Collections

In a Request-URI /segment1/segment2/segment3, any of the three segments
may identify a redirect reference.  A client might
use this value if,  (See [URI], Section 3.3, for example, it wanted to populate
definitions of "path" and "segment".)  If any segment in a collection with
references before their content was made available on Request-URI
identifies a redirect reference, the Web. response is a 302.  The value "enforce" means that of
the server MUST enforce referential
integrity for Location header in the newly created reference, but does not constrain 302 response is as follows:

The leftmost path segment of the
server request-URI that identifies a redirect
reference, together with all path segments and separators to use any particular policy for enforcing referential integrity.
It is beyond the scope left of this specification to define precisely
it, is replaced by the
meaning value of referential integrity or the redirect reference's
DAV:reftarget property (resolved to enumerate any set of policies
that might be considered compliant.

Clients and servers may use other values an absolute URI).  The remainder of
the Ref-Integrity header by
private agreement, request-URI is concatenated to specify more precisely the desired policy for
enforcing referential integrity. this path.

Note: If the DAV:reftarget property ends with a server receives an extension
value that it does not understand, it MUST fail "/" and the request.

If remainder of
the Ref-Integrity header Request-URI is not present on non-empty (and therefore must begin with 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
final "/" in the No-Passthrough

header DAV:reftarget property is present, dropped before the request MUST be applied to remainder
of the reference itself
rather than to its target.  For Request-URI is appended.

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

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

In this case the request MUST be applied client must follow up three separate 302 responses
before finally reaching the target resource.  The server responds to the
reference itself, and
initial request with a 302 response MUST NOT be returned.  If with Location: /a/y/z.html, and the client
resubmits the No-
Passthrough header is used on a request to any other sort of resource
besides a reference, the /a/y/z.html.  The server SHOULD ignore it.  If the No-Passthrough
header is used with a POST request responds to this
request with a reference, the server MUST
respond 302 with a 400 (Bad Request). Location: /b/z.html, and the client resubmits
the request to /b/z.html.  The No-Passthrough header can be used server responds to this request with PROPFIND requests on
collections a
302 with Depth = infinity.  When it is used in this way, the
server MUST return Location: /c/d.html, and the properties of any redirect references in client resubmits the
collection, and request to
/c/d.html.  This final request succeeds.

5 Ordered Collections

5.1 Overview

Collections on a compliant server may be ordered, but need not return 302 (Moved Temporarily) status codes for
them. be.  It MUST also return the properties of any direct references in
is up to the client to decide whether a given collection (not is ordered and,
if so, to specify the properties of their targets), and it MUST NOT
follow any direct references semantics to collections into their target
collections.

The No-Passthrough header can be used with LOCK requests on collections
with Depth = infinity.  When it for ordering its bindings.
If a collection is used in this way, the server ordered, each of its bindings, and hence internal
member URIs, MUST
lock any redirect references be in the collection, just as it would if ordering exactly once, and the
No-Passthrough header were absent.  It ordering MUST also lock
NOT include any direct
references in binding that is not contained by the collection.  Only
one ordering can be attached to any collection. An ordering is
considered to be part of the state of a collection (not their target resources), resource, and it MUST
NOT follow any direct references hence
is the same across all URI mappings to collections into their target
collections.

The No-Passthrough header the collection.  Multiple
orderings of the same resources can be used with COPY requests on achieved by creating multiple
collections
with Depth > 0.  When it referencing those resources, and attaching a different
ordering to each collection.

The server is used in this way, the responsible for enforcing these constraints on orderings.
The server MUST copy any
redirect references in remove a binding (and its derived internal member URI)
from the collection, just as ordering when it would if is removed from the No-
Passthrough header were absent.  It collection. The server
MUST also copy any direct references
in add a binding (and its derived internal member URI) to the collection (not their target resources), and ordering
when it MUST NOT follow
any direct references is added 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 the collection.

When responding to request that a PROPFIND on a collection, the new
collection be ordered and server MUST order the
response elements according to specify its the ordering semantics.  A value of
"DAV:unordered" indicates that defined on the collection.

If the collection is not ordered.  That is, unordered, 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

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

5.2 Creating an Ordered Collection

5.2.1 Overview

When a
human user or software package to insert new collection members into is created, the
ordering intelligently.  The Coded-url client MAY point to a resource that
contains a definition of the semantics of the ordering.  A value of
"DAV:custom" indicates request that the collection is to it be ordered, but ordered
and specify the semantics of the ordering is not being advertised.

If by using the new Ordered
header is not present on (defined in Section 6.5) with a MKCOL request, the server MUST
treat the request as if it had an Ordered header with request.

For collections that are ordered, the value
"DAV:unordered".

6.6 Position Request Header

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

The Position header may be used client SHOULD identify the
semantics of the ordering with any method that adds a member to URI in the Ordered header.  This URI
may identify a
collection to tell server-maintained ordering.  Clients can discover the server where
available server-maintained orderings using the mechanism defined in
Section 11.3.  The URI may identify a semantics for a client-maintained
ordering, providing the information a human user or software package
needs to insert new collection members into the ordering to
position intelligently.
Although the new member being added URI in the Ordered header MAY point to a resource that
contains a definition of the collection.  It may be used
for both ordinary and referential members.

If semantics of the Coded-url is a relative URL, it is interpreted relative ordering, clients are
discouraged from accessing that resource, in order to avoid
overburdening its server.  The client MAY set the
collection header value to which
DAV:custom to indicate that the new member collection is ordered, but the semantics
of the ordering are not being added. advertised.  If the Position request header is client does not used, then:

If want
the request is replacing an existing resource, collection to be ordered, it may omit the server MUST
preserve Ordered header, or use it
with the present ordering. value DAV:unordered.

If the request is adding a new member to the collection, the server MUST
append the new member to does not recognize the end value of the Ordered header as one
of its server-maintained orderings, it MUST assume that a client-
maintained 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 intended.  If the
            target resource.  This is a read-only property, whose value
            can only be set by using of the Ref-Target Ordered header with a MKREF
            request.
Value: 	    URI is
one of the target resource.  This value MAY be a relative
            URI.  The reftarget property can occur in server-maintained orderings that the entity bodies
            of responses server supports, it MUST
maintain the collection's ordering according to that ordering semantics
as new members are added.

Every collection MUST have a variety of requests.  It always occurs DAV:orderingtype property (defined in
Section 7.5), which indicates whether the context collection is ordered and, if
so, identifies the semantics of a Multi-Status response, inside a
            DAV:response element that has a single DAV:href element. the ordering.  The server sets the
initial value of this DAV:href element serves as property based on 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 the Ordering header
in order to serve as the base URI for MKCOL request. If the
            relative URI in DAV:reftarget.)  See [URI] Section 5 for a
            discussion of relative URI references and how collection is unordered, the
DAV:orderingtype property MUST have the value DAV:unordered. An
ordering-aware client interacting with an ordering-unaware server (e.g.,
one that is implemented only according to resolve
            them.

<!ELEMENT reftarget href>

7.1.1 Example: Resolving [WebDAV]) SHOULD assume that
if a Relative URI in collection does not have the DAV:reftarget

Request:

PROPFIND /geog/ DAV:orderingtype property, the
collection is unordered.

5.2.2 Example: Creating an Ordered Collection

>>Request:

MKCOL /theNorth/ 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: www.server.org
Ordered: http://www.server.org/orderings/compass.html

>>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> 201 Created

In this example, example a new, ordered collection was created.  Its
DAV:orderingtype property has as its value the relative URI statistics/population/1997.html is
returned as from the value of reftarget for Ordered
header, http://www.server.org/orderings/compass.html.  In this case, the reference identified by href
/geog/stats.html.  The href is itself
URI identifies the semantics governing a relative URI, which resolves client-maintained ordering.  As
new members are added to
http://www.xxsrv.com/geog/stats.html.  This is the base URI for
resolving collection, clients or end users can use
the relative URI semantics to determine where to position the new members in reftarget.  The absolute URI the
ordering.

5.3 Setting the Position of reftarget a Collection Member

5.3.1 Overview

When a new member is http://www.xxsrv.com/geog/statistics/population/1997.html.

7.2 refintegrity Property

Name:	    refintegrity

Namespace:  DAV:
Purpose:    A REQUIRED property of added to a referential resource that indicates
            whether collection with a client-maintained
ordering (for example, with PUT, MKREF, or MKCOL), its position in the server enforces referential integrity for that
            reference.
ordering can be set with the new Position header (defined in Section
6.6).  The refintegrity property is defined Position header allows the client to allow
            future support for strong references.  The only value
            currently defined for refintegrity is weak, which means specify that the server does not enforce referential integrity for member
should be first in the
            reference.  Although a server may assign another value to
            identify its policy for enforcing referential integrity for collection's ordering, last in the reference, it cannot count on clients understanding such
            extension values.  This collection's
ordering, immediately before some other binding in the collection's
ordering, or immediately after some other binding in the collection's
ordering.

5.3.2 Status Codes

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

425 (Unordered Collection): The request specifies a collection position
in an extension value

<!ELEMENT refintegrity (weak | ANY)>

7.3 reftype Property

Name:       reftype
Namespace:  DAV:
Purpose:    A required property unordered collection or in a collection with a server-maintained
ordering.

5.3.3 Examples: Setting the Position of a Collection Member

>>Request:

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

>>Response:

HTTP/1.1 201 Created

This request resulted in the creation of a new referential resource that
            identifies at
www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the reference as direct or redirect.  This is a
            read-only property, whose value can only be set resource
identified by using the Ref-Type Ref-Target header.  The Position 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 this
example caused the absolute URI of server to set its position in the
            temporary location ordering of the resource.
/~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: http://www.ics.uci.edu/~whitehead/dav/draft-webdav-
     protocol-08.txt
Position: First

>>Response:

HTTP/1.1 425 Unordered Collection

In the context of
            redirect references, this value is case, the absolute URI of server returned a 425 (Unordered Collection) status
code because the
            target resource.  It /~whitehead/dav/ collection is analogous an unordered collection.
Consequently, the server was unable to satisfy the Location header in
            HTTP 302 responses defined in [HTTP] Section 10.3.3 "302
            Moved Temporarily."  Including Position header.

5.4 Changing the location property in a
            Multi-Status response requires Semantics of a Collection Ordering

After a collection has been created, a client can change its ordering
semantics, or change an extension ordered collection to an unordered collection or
vice versa, by using PROPPATCH to change the syntax value of
            the DAV:response element defined in [WebDAV], which is
            defined its
DAV:orderingtype property (defined in Section 9 below.  This property is not expected
            to be stored on 7.5).  If the reference. It is modeled as a property
            only so that it can be returned inside a DAV:prop element in new value
identifies a Multi-Status response.
Value:      href containing the absolute URI of client-maintained ordering, the target resource.

<!ELEMENT location href >

7.5 references Property

Name:	    references
Namespace:  DAV:
Purpose:    Enables clients to discover, client is then responsible
for any target resource, what
            references point updating the collection's ordering according to it and what collections contain it by
            reference.  This is an optional property. the new semantics.
If present, it is identifies a read-only property, maintained by the server.
Value:	    List of server-maintained ordering, the URIs of server MUST reorder
the references that point collection according to the target
            resource.

<!ELEMENT references (href*)>

7.6 orderingtype Property

Name:	    orderingtype
Namespace:  DAV:
Purpose:    Indicates whether the collection new semantics.  PROPPATCH is ordered and, if so,
            uniquely identifies defined in
[WebDAV], Section 7.2.

5.5 Changing the semantics Position of a Collection Member

5.5.1 ORDERPATCH Method

The ORDERPATCH method alters the ordering being
            used.  May also point to an explanation of the semantics bindings 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
identified by the Request-URI, based on instructions in the ordering.
Value:	    unordered for an unordered collection, or a URI that
            uniquely order XML
element. The order XML element identifies the semantics of bindings whose positions
are to be changed, and describes their new positions in the collection's ordering.
Each new position can be specified as first in the ordering, last in the
ordering, immediately before some other binding, or immediately after
some other binding.

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

5.5.2 Status Codes

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

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

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

409 (Conflict): The request specifies a collection position that is before or after
a URI 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 an internal member URI of the DAV:resourcetype property that identifies
            its resource as a referential resource. collection, or before or
after itself.

425 (Unordered Collection): The
            DAV:resourcetype property of request specifies a referential resource MUST
            have this value.
Value:	    EMPTY

<!ELEMENT reference EMPTY >

8.2 direct XML Element

Name:	    direct
Namespace:  DAV:
Purpose: collection position
in an unordered collection or in a collection with a server-maintained
ordering.

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 request to reposition a redirect reference.

Value:      EMPTY

<!ELEMENT redirect EMPTY >

8.4 weak XML Element

Name:	    weak
Namespace:  DAV:
Purpose:    A value of binding at the DAV:refintegrity property.  It means that same place in the
            server does ordering is
not enforce referential integrity for an error.

5.5.3 Example: Changing Positions in an Ordered Collection

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

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

>> Request:

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

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

>> Response:

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

Content-Length: xxx

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

If the
            reference href elements are relative URIs, as in this example, they are
interpreted relative 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 that is not ordered.  That is, the client cannot
            depend on being reordered.  In this
example, after the repeatability of request has been processed, the collection's ordering
is as follows:

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

5.5.4 Example: Failure of results from an ORDERPATCH Request

Consider 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 /coll-1/ with the new bindings ordered as follows:

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

>> Request:

ORDERPATCH method.  Describes a change
            to be made in /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.map</d:href>
      <d:position>
         <d:after>
            <d:href>pangnirtung.img</d:href>
         </d:after>
      </d:position>
   </d:ordermember>
</d:order>

>> Response:

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

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

In this example, the new client attempted to position of iqaluit.map after a single collection member
binding that is not contained in the collection's
            ordering.
Value: 	    An href containing collection /coll-1/.  The server
responded to this client error with a relative URI, and 409 (Conflict) status code.
Because ORDERPATCH is an atomic method, the request to reposition
nunavut.desc (which would otherwise have succeeded) failed with a description of its
            new position in 424
(Failed Dependency) status code.

6 Headers

6.1 All-Bindings Request Header

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

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

6.2 Ref-Target Entity Header

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

The href XML element Ref-Target header is defined in [WebDAV], Section 11.3.

<!ELEMENT ordermember (href, position) >

8.9 position XML Element

Name: 	    position
Namespace:  DAV:
Purpose:    Occurs in primarily for use with MKREF requests
to identify the member XML element.  Describes target resource of the new
            position redirect reference being
created.

6.3 Resource-Type Entity Header

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

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

6.4 Passthrough Request Header

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

The optional Passthrough header can be described as first in the
            collection's ordering, last in used on any request to a redirect
reference.  If the collection's ordering,
            before some other member of Passthrough header has the collection, or after some
            other member of value "F", the collection.

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

8.10 first XML Element

Name: 	    first
Namespace:  DAV:
Purpose:    Occurs in request
MUST be applied to the position XML element.  Describes reference itself, and a 302 response MUST NOT be
returned.  If the
            collection member's position as first in Passthrough header has the collection's
            ordering.
Value: 	    EMPTY

<!ELEMENT first EMPTY >

8.11 last XML Element

Name: 	    last
Namespace:  DAV:
Purpose:    Occurs in value "T", a 302 response
MUST be returned, with the position XML element.  Describes URI of the
            collection member's position as last target resource in the collection's
            ordering.
Value: 	    EMPTY

<!ELEMENT last EMPTY >

8.12 before XML Element

Name: 	    before
Namespace:  DAV:
Purpose:    Occurs in Location
header and the position XML element.  Describes Resource-Type header with a value "DAV:redirectref".

If the
            collection member's position as coming before some Passthrough header is used on a request to any other
            collection member in the collection's ordering.
Value: 	    href sort of
resource besides a reference, the member it precedes in server SHOULD ignore it.  If the ordering

<!ELEMENT before href >

8.13 after XML Element

Name: 	    after
Namespace:  DAV:
Purpose:    Occurs
Passthrough header with the value "F" appears in a POST or ORDERPATCH
request to a reference, the position XML element.  Describes server MUST respond with a 400 (Bad
Request).

6.5 Ordered Entity Header

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

The Ordered header may be used with MKCOL to request that the new
collection member's position as coming after some other
            collection member in be ordered and to specify its ordering semantics.  A value of
"DAV:unordered" indicates that the collection's ordering.
Value: 	    href collection is not ordered. A value of
"DAV:custom" indicates that the member it follows in collection is to be ordered, but the
semantics of the ordering

<!ELEMENT after href >

9 Extensions to is not being advertised.  Any other
absoluteURI value indicates that the DAV:response XML Element for Multi-Status Responses

As described in Sections 4.5 collection is ordered, and 4.6,
identifies the DAV:location property and semantics of the
DAV:reftype property ordering.

6.6 Position Request Header

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

The Position header may be returned in the DAV:response element of used with any method that adds a
207 Multi-Status response, to allow clients binding to resubmit their requests a

collection with a client-maintained ordering, to tell the target resource of a redirect reference.

As described server where
in Section 4.13, the DAV:reftype and DAV:reftarget
properties may be returned in collection ordering to position the DAV:response element of a 207 Multi-
Status response, new binding being added to indicate that a problem
the collection.

If the Generic-Coded-url 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 relative URL, it is interpreted relative
to the href collection 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 new binding is being added.

The server MUST insert the DAV:response XML element changes to new binding into the following:

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

10 Capability Discovery

10.1 Using OPTIONS

Since referencing and ordering are independent capabilities, at the location
specified in the Position header, if one is present (and if the
collection has a resource
MAY support either or both.  A resource that provides referencing MUST
support redirect references, and MAY client-maintained ordering).

The "First" keyword indicates the new binding is put in addition support direct
references.  A response to an OPTIONS request MUST indicate which of
these capabilities the resource supports.

This specification defines two beginning
position in the collection's ordering, while "Last" indicates the new methods: MKREF
binding is put in support of
referencing, and ORDERPATCH the final position in support of the collection's ordering.  The response MUST
indicate which of these methods
"Before" keyword indicates the resource allows.  In addition, new binding is added to the
response MUST include collection's
ordering immediately prior to the DAV header, as described in Sections 9.1 and
15 position of [WebDAV].  Three the binding identified in
the Generic-Coded-url. Likewise, the "After" keyword indicates the new compliance classes are defined here for use
with
binding is added to the DAV header: basicref, directref, and orderedcoll.

When responding to collection's ordering immediately following the
position of the binding identified in the Generic-Coded-url.

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

If the Position request header is not used when adding a binding to a
collection or with a null
resource can include orderedcoll in client-maintained ordering, then:

o If the value of request is replacing an existing resource, the DAV header.  By
including orderedcoll, server MUST
  preserve 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 present ordering.

o If the request is adding a new binding to an OPTIONS request, any type the collection, the server
  MUST append the new binding to the end of resource can include
basicref the ordering.

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

7 Status Codes

7.1 506 Loop Detected

The 506 (Loop Detected) status code indicates that the server permits detected
an infinite loop while processing a redirect reference at the request URI.  Including directref with "Depth: infinity".

7.2 425 Unordered Collection

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

8 Properties

8.1 reftarget Property

Name:	    reftarget
Namespace:  DAV:
Purpose:    A property of redirect references that provides an efficient
            way for clients to discover 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 URI of the resource /somecollection/ is level 1
and level 2 compliant, as defined in [WebDAV].  In addition,
/somecollection/ supports ordering and target resource.
            This is in a part of the server
namespace that allows creation of redirect and direct references.  (In
light of read-only property, whose value can only be set by
            using the semantics Ref-Target header with a MKREF request.
Value: 	    URI of MKREF, the resource currently at
/somecollection/ would have to target resource.  This value MAY 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 relative
            URI.  The reftarget property can occur in the entity bodies
            of which WebDAV applications need responses to be aware.

All PROPFIND requests.

<!ELEMENT reftarget (#PCDATA)>

8.2 location Property

Name:       location
Namespace:  DAV:
Purpose:    For use with 302 (Moved Temporarily) response codes in
            Multi-Status responses.  It contains the absolute URI of the security considerations
            temporary location of HTTP/1.1 and the base WebDAV
protocol also apply to WebDAV collections. resource.  In addition, referential
resources and ordered collections introduce several new security
concerns and increase the risk context of some existing threats.  These issues
are detailed below.

12.1 Privacy Concerns

By creating references on a trusted server, it
            redirect references, this value is possible for a hostile
agent to induce users to send private information to a the absolute URI of the
            target on a
different server.   This risk resource.  It is mitigated somewhat for redirect

references, since clients are required analogous to notify the user of the
redirection for any request other than GET or HEAD. (See [HTTP], Location header in
            HTTP 302 responses defined in [HTTP] Section 10.3.3 "302
            Moved Temporarily.)  For direct references, clients can determine Temporarily."  Including the resource type, reference type, and target location before sending property in a
request, but are not required
            Multi-Status response requires an extension to notify users if the target 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
another server.

12.2 Redirect Loops

Although redirect loops were already possible the reference. It is modeled as a property
            only so that it can be returned inside a DAV:prop element in HTTP 1.1,
            a Multi-Status response.
Value:      href containing the
introduction absolute URI 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 resource.

<!ELEMENT location href >

8.3 bindings Property

Name:	    bindings
Namespace:  DAV:
Purpose:    Enables clients to detect MKREF requests that would create loops. See also [HTTP],
Section 10.3 "Redirection 3xx."

12.3 References discover, for any resource, what bindings
            point to it and Denial what collections contain those bindings.
            This is an optional property.  If present, it is a read-only
            property, maintained by the server.
Value:	    List of Service

Denial href / segment pairs for all of service attacks were already possible by posting URLs the bindings that
were intended for limited use at heavily used Web sites.
            associate URI segments with the resource.  The
introduction of referential resources creates a new avenue href is an
            absolute URI for similar
denial one URI mapping of service attacks.  Clients can now create references at heavily
used sites the collection
            containing the binding.  The segment is the URI segment that
            identifies the binding within that collection. If a binding
            belongs to target locations a collection that were not designed has multiple URI mappings, only
            one URI mapping for heavy usage.

12.4 References May Reveal Private Locations

There are several ways that collection should be reported.

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

8.4 orderingtype Property

Name:	    orderingtype
Namespace:  DAV:

Purpose:    Indicates whether the referencing mechanisms described here
may reveal information about directory structures.  First, collection is ordered and, if so,
            uniquely identifies the
DAV:reftarget property semantics of every reference contains the URI ordering being
            used.  May also point to an explanation of the target
resource.  Anyone semantics in
            human and / or machine-readable form.  At a minimum, this
            allows human users who has access add members to the reference can discover collection to
            understand where to position them in the
directory path ordering.
Value:	    unordered for an unordered collection, or a URI that leads to
            uniquely identifies the target resource.   The owner semantics 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 collection's
            ordering.  The value custom indicates that the DAV:reftarget property.  (The Ref-Target header, which collection is
returned in most responses to requests on direct references, reveals
            ordered, but the
same information, however.)  In some environments, semantics are not being advertised.

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

9 XML Elements

9.1 redirectref XML Element

Name: 	    redirectref
Namespace:  DAV:
Purpose:    Used as the owner value of a
resource might be able to use access control to prevent others from
creating references the DAV:resourcetype property to
            specify 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 the resource type is moved, there is the risk a redirect reference.

<!ELEMENT redirectref EMPTY >

9.2 segment XML Element

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

<!ELEMENT segment (#PCDATA)>

9.3 unordered XML Element

Name:	    unordered
Namespace:  DAV:
Purpose:    A value of 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, DAV:orderingtype property that indicates that
            the
owners of references face these same risks.  The directory structures
where references are located are revealed to anyone who has access to collection is not ordered.  That is, the DAV:references property on a target resource.  Moving a reference
may reveal its new location to anyone with access to DAV:references client cannot
            depend on
its target resource.

12.5 DAV:references and Denial the repeatability of Service

If the server maintains ordering of results from
            a PROPFIND request.

<!ELEMENT unordered EMPTY >

9.4 custom XML Element

Name: 	    custom
Namespace:  DAV:
Purpose:    A value of the DAV:references DAV:orderingtype property in response to
references created in other administrative domains, it that indicates that
            the collection is exposed to
hostile attempts to make it devote resources to adding references to ordered, but the
list.

12.6 DAV:references and Malicious Deletion semantics of Resources

Servers that support the DAV:references property should insure that
clients cannot create editable properties ordering
            are not being advertised.

<!ELEMENT custom EMPTY >

9.5 order XML Element

Name: 	    order
Namespace:  DAV:
Purpose:    For use with the name DAV:references.
An editable DAV:references property would constitute new ORDERPATCH method.  Describes a security risk on
servers that enforce referential integrity by deleting references when
their target is deleted.  These servers could change
            to be tricked into deleting a
resource by listing it made in the DAV:references property of some target
resource.

12.7 Denial of Service and DAV:orderingtype

There may be some risk of denial a collection ordering.
Value:      A description of service at sites that are advertised
in the DAV:orderingtype property new positions 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] bindings a
            collection contains in encoding all
human-readable content using its ordering.

<!ELEMENT order (ordermember+) >

9.6 ordermember XML [XML] and Element

Name: 	    ordermember
Namespace:  DAV:
Purpose:    Occurs 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, order XML Element, and describes the language tagging functionality new
            position of a single binding in the XML
specification.  This constraint ensures that the human-readable content collection's ordering.
Value: 	    An href containing a binding's path segment, and a
            description of this specification complies with [Alvestrand].

As its new position in [WebDAV}, names the ordering.  The href
            XML element is defined in this specification fall into three categories:
names of protocol elements such as methods and headers, names of [WebDAV], Section 11.3.

<!ELEMENT ordermember (href, position) >

9.7 position XML
elements, and names Element

Name: 	    position
Namespace:  DAV:
Purpose:    Occurs in the ordermember XML element.  Describes the new
            position in a collection's ordering of properties.  Naming one of protocol elements follows the precedent of HTTP, using English names encoded in USASCII for
methods and headers. bindings
            it contains.
Value: 	    The names of XML elements used new position can be described as first in this
specification are English names encoded the
            collection's ordering, last 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 collection's ordering,
            immediately before some other binding, or immediately after
            some other binding.

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

9.8 first XML Element

Name: 	    first
Namespace:  DAV:
Purpose:    Occurs in the code (e.g., 423 Locked).  Internationalized applications will ignore
this message, and display an appropriate message position XML element.  Specifies that the
            binding should be placed first 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 collection's ordering.

<!ELEMENT first EMPTY >

9.9 last XML Element

Name: 	    last
Namespace:  DAV:
Purpose:    Occurs in the namespaces defined by [WebDAV] for properties and position XML elements.  All other IANA considerations mentioned element.  Specifies that the
            binding should be placed last in [WebDAV] also
apply to this document.

15 Copyright

To the collection's ordering.

<!ELEMENT last EMPTY >

9.10 before XML Element

Name: 	    before
Namespace:  DAV:
Purpose:    Occurs in the position XML element.  Specifies that the
            binding should be supplied.

16 Intellectual Property

To placed immediately before the binding in
            the enclosed href XML element in the collection's ordering.
Value: 	    href of the member it precedes in the ordering

<!ELEMENT before href >

9.11 after XML Element

Name: 	    after
Namespace:  DAV:
Purpose:    Occurs in the position XML element.  Specifies that the
            binding should be 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 placed immediately after the binding in RFCs
            the enclosed href XML element in the collection's ordering.
Value:      href of the member it follows in the ordering

<!ELEMENT after href >

9.12 options XML Element

Name:       options
Namespace:  DAV:
Purpose:    Used in OPTIONS requests to 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 ask 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 more detailed
            information about capabilities than can be provided in WebDAV." Draft-ietf-webdav-collection-reqts-02.

Internet Draft, work the
            DAV: response header.  Used 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

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

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

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

20 Appendices

20.1 Appendix 1: Extensions OPTIONS responses to provide
            that information.
Value:      List of elements identifying or providing 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) > additional
            information desired.

<!ELEMENT position (first | last | before options (orderingoptions | after)>
<!ELEMENT first EMPTY >
<!ELEMENT last EMPTY >
<!ELEMENT before href >
<!ELEMENT after href ANY)+ >
<!--============= 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

9.13 orderingoptions XML Element from Section 9 ====-->
<!ELEMENT response (href, ((href*, status, prop?) | (propstat+)),
responsedescription?) >

20.2 Appendix 2: Summary of Referencing Headers Required

Name:       orderingoptions
Namespace:  DAV:
Purpose:    Used in Responses

This section summarizes OPTIONS requests to ask for the rules list of server-
            maintained orderings that determine which referencing
headers are included can be supported at the request-
            URI.  Used in OPTIONS responses to requests on references.  The
normative statements provide that are summarized here information.
            These values 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 used 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 the Ordered header or the
            DAV:orderingtype property to a request on a reference includes the Ref-Type
  header, so that a particular
            server-maintained ordering be applied to the client knows that it was operating collection.
Value:      EMPTY on a
  reference, and can understand requests.  On responses, it is the behavior list of server-
            maintained orderings available for the reference.

o Since [HTTP] requires responses to GET and HEAD request-URI.

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

10 Extensions to include all entity
  headers, Ref-Target is included the DAV:response XML Element for Multi-Status Responses

As described in all responses to GET Sections 4.6 and HEAD
  requests on references with the No-Passthrough header.

o For all other requests with 4.9, the No-Passthrough header, DAV:location property and the client is
  aware that it is operating on
DAV:reftype property may be returned in 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 DAV:response element of a direct
  reference,
207 Multi-Status response, to allow clients to resubmit their requests

to 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 redirect reference.

Whenever these properties are included in a direct
  reference, Multi-Status response, they
are placed in most cases the response is a 302 DAV:prop element associated with the Location
  header.  The Location header contains 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 URI definition of the target resource.
  Consequently, DAV:response XML element changes to
the Ref-Target header is following:

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

11 Capability Discovery

11.1 Compliance Classes

This specification defines OPTIONAL in the response.
  COPY, LOCK, DELETE, extensions to [WebDAV].  Since
resource sharing and MOVE do not return ordering are independent capabilities, a 302 response, but
  instead operate on the reference.  For resource
MAY support either, both, or neither of these methods, a Ref-Target
  header is REQUIRED in the response.  This allows the client to locate
  the target capabilities.  A resource in case it wants
that provides resource sharing MUST support both bindings and redirect
references.  A response to resubmit the an OPTIONS request to MUST indicate which of
these capabilities the
  target.

Requests on collections with Depth header greater than 0 typically get
Multi-Status responses.  Consequently, information about any references resource supports.

This specification defines three new methods: BIND and MKREF in the collection cannot be returned support
of shared resources, and ORDERPATCH in headers.  Instead, support of ordering.  The
response MUST indicate which of these methods the
corresponding DAV properties are returned in resource allows.  In
addition, the DAV:response elements
for response MUST include the references.

20.3  Appendix 3: Summary DAV header, as described in
Sections 9.1 and 15 of Method Semantics [WebDAV].  Two new compliance classes are defined
here for References

This section summarizes use with the semantics of each HTTP DAV header: sharing and WebDAV method
when the request-URI identifies a reference.  The normative statements
that are summarized here can be found in Sections 4.3 - 4.10.

For each method, there are four cases orderedcoll.

When responding to consider:

o Request-URI identifies an OPTIONS request, only a redirect reference, and the No-Passthrough
  header is not used
o Request-URI identifies collection or a redirect reference, and null
resource can include orderedcoll in the No-Passthrough
  header is present
o Request-URI identifies a direct reference, and value of the No-Passthrough
  header is not used
o Request-URI identifies a direct reference, and DAV header.  By
including orderedcoll, the No-Passthrough
  header is present resource indicates that its bindings can be
ordered.  It implies nothing about whether any collections identified by
its internal member URIs can be ordered.

When the No-Passthrough header is used, the situation is simple.  For
all methods, the request is applied responding to an OPTIONS request, any type of resource can include
sharing in the reference, not to its target
resource.

The following table summarizes behavior for value of the cases where DAV header.  Including sharing indicates
that 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
--------------------------------------------------------------------- server permits a redirect reference or a binding at the request
URI.

11.2 Example: Discovery of Compliance Classes

>> Request:

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 /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, BIND, ORDERPATCH
Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL,
PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKREF, ORDERPATCH
DAV: 1, 2, sharing, orderedcoll

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

11.3 Additional Advanced Collections Capabilities

Clients may need detailed information about specific areas of advanced
collections functionality.  This information can be requested by sending
an OPTIONS request with 302 status code | Apply method to target
=====================================================================
DELETE    | Apply method to reference    | Apply method an XML body that includes a DAV:options element.
The DAV:options element contains a list of empty elements identifying
the information the client needs.

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

11.4 Example: Discovery of Ordering Options

>> Request:

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

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

>> Response:

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

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

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

12 Security Considerations

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

All of the security considerations of HTTP/1.1 and the WebDAV
Distributed Authoring Protocol specification also apply to WebDAV
collections.  In addition, resource sharing and ordered collections
introduce several new security concerns and increase the risk of some
existing threats.  These issues are detailed below.

12.1 Privacy Concerns

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

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

12.2 Redirect Loops

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

12.3 Redirect References, Bindings, and Denial of Service

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

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

12.4 Private Locations May Be Revealed

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

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

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

12.5 DAV:bindings and Denial of Service

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

12.6 Denial of Service and DAV:orderingtype

There may be some risk of denial of service at sites that are advertised
in the DAV:orderingtype property of collections.  However, it is
anticipated that widely-deployed applications will use hard-coded values
for frequently-used ordering semantics rather than looking up the
semantics at the location specified by DAV:orderingtype.  In addition,
Section 5.2 discourages clients from looking up the semantics at that
location.

13 Internationalization Considerations

This specification follows the practices of [WebDAV] in encoding all
human-readable content using XML [XML] and in the treatment of names.
Consequently, this specification complies with the IETF Character Set
Policy [Alvestrand].

WebDAV applications MUST support the character set tagging, character
set encoding, and the language tagging functionality of the XML

specification.  This constraint ensures that the human-readable content
of this specification complies with [Alvestrand].

As in [WebDAV}, names in this specification fall into three categories:
names of protocol elements such as methods and headers, names of XML
elements, and names of properties.  Naming of protocol elements follows
the precedent of HTTP, using English names encoded in USASCII for
methods and headers.  The names of XML elements used in this
specification are English names encoded in UTF-8.

For error reporting, [WebDAV] follows the convention of HTTP/1.1 status
codes, including with each status code a short, English description of
the code (e.g., 423 Locked).  Internationalized applications will ignore
this message, and display an appropriate message in the user's language
and character set.

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

14 IANA Considerations

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

15 Copyright

To be supplied by the RFC Editor.

16 Intellectual Property

To be supplied by the RFC Editor.

17 Acknowledgements

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

18 References

18.1 Normative References

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

[RFC2119] S. Bradner, "Key words for use in RFCs to reference
---------------------------------------------------------------------
MOVE      | Apply method 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

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

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

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

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

J. Crawford

IBM
Email: ccjason@us.ibm.com

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

20 Appendices

20.1 Appendix 1: Extensions to reference the WebDAV Document Type Definition

<!--============= XML Elements from Section 8 ================-->
<!ELEMENT redirectref EMPTY >
<!ELEMENT segment (#PCDATA)>
<!ELEMENT unordered EMPTY >
<!ELEMENT custom EMPTY >
<!ELEMENT order (ordermember+) >
<!ELEMENT ordermember (href, position) >
<!ELEMENT position (first | Apply method to reference
=====================================================================
COPY last | Apply method to reference before | Apply method to target
---------------------------------------------------------------------
LOCK after)>
<!ELEMENT first EMPTY >
<!ELEMENT last EMPTY >
<!ELEMENT before href >
<!ELEMENT after href >
<!ELEMENT options (refintegrityoptions | Apply method to reference orderingoptions)+ >
<!ELEMENT orderingoptions ( (#PCDATA)+ | Apply method to target
---------------------------------------------------------------------
UNLOCK EMPTY) >
<!--============= Property Elements from Section 7 ==================-->
<!ELEMENT reftarget (#PCDATA)>
<!ELEMENT location href>
<!ELEMENT bindings ((href, segment)*)>
<!ELEMENT orderingtype (arbitrary | Apply method to reference custom | Apply method to target

PROPFIND, DELETE, MOVE, COPY, LOCK, and UNLOCK can be applied href) >
<!--====== Changes 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. DAV:response Element from Section 9 ====-->
<!ELEMENT response (href, ((href*, status, prop?) | (propstat+)),
responsedescription?) >

Expires August 26, December 18, 1999