draft-ietf-webdav-collection-protocol-01.txt   draft-ietf-webdav-collection-protocol-02.txt 
WEBDAV Working Group J. Slein, Xerox WEBDAV Working Group J. Slein, Xerox
INTERNET DRAFT J. Davis, Xerox INTERNET DRAFT J. Davis, Xerox
<draft-ietf-webdav-collection-protocol-01> A. Babich, FileNet <draft-ietf-webdav-collection-protocol-02> A. Babich, FileNet
E.J. Whitehead Jr., UC Irvine E.J. Whitehead Jr., UC Irvine
July 31, 1998 November 10, 1998
Expires January 31, 1999 Expires May 10, 1999
WebDAV Advanced Collections Protocol WebDAV Advanced Collections Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its areas, and
areas, and its working groups. Note that other groups may also its working groups. Note that other groups may also distribute working
distribute working documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or made obsolete by other and may be updated, replaced, or made obsolete by other documents at any
documents at any time. It is inappropriate to use Internet-Drafts time. It is inappropriate to use Internet-Drafts as reference material
as reference material or to cite them other than as "work in or to cite them other than as "work in progress".
progress".
To view the entire list of current Internet-Drafts, please check To view the entire list of current Internet-Drafts, please check the
the "1id-abstracts.txt" listing contained in the Internet-Drafts "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
(Northern Europe), ftp.nis.garr.it (Southern Europe),munnari.oz.au ftp.nis.garr.it (Southern Europe),munnari.oz.au (Pacific Rim),
(Pacific Rim), ftp.ietf.org (US EastCoast), or ftp.isi.edu (US West ftp.ietf.org (US EastCoast), or ftp.isi.edu (US West Coast).
Coast).
Distribution of this document is unlimited. Please send comments Distribution of this document is unlimited. Please send comments to the
to the Distributed Authoring and Versioning (WebDAV) working group Distributed Authoring and Versioning (WebDAV) working group at <w3c-
at <w3c-dist-auth@w3.org>, which may be joined by sending a dist-auth@w3.org>, which may be joined by sending a message with subject
message with subject "subscribe" to <w3c-dist-auth- "subscribe" to <w3c-dist-auth-request@w3.org>.
request@w3.org>.
Discussions of the WEBDAV working group are archived at URL: Discussions of the WEBDAV working group are archived at URL:
<http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth>. <http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth>.
Abstract Abstract
The base WebDAV protocol [WebDAV] provides basic support for The base WebDAV protocol [WebDAV] provides basic support for
collections. It defines a MKCOL method for creating collections collections. It defines a MKCOL method for creating collections and
and specifies how other HTTP and WebDAV methods interact with specifies how other HTTP and WebDAV methods interact with collections.
collections. It supports internal members of collections, which it It supports internal members of collections, which it defines as members
defines as members whose URIs are immediately relative to the URI whose URIs are immediately relative to the URI of the collection.
of the collection.
Many applications, however, need more powerful collections. There Many applications, however, need more powerful collections. There are
are two areas in particular where more powerful functionality is two areas in particular where more powerful functionality is often
often needed: referential resources and ordering. needed: referential resources and ordering.
This draft specifies extensions to the base WebDAV protocol to This draft specifies extensions to the base WebDAV protocol to support
support these more powerful collections. these more powerful collections.
Table of Contents Table of Contents
1 Terminology 3 1 Terminology ............................................... 3
2 Introduction 4 2 Introduction .............................................. 4
3 Referential Resources 4 3 Referential Resources ..................................... 4
3.1 Scope 4 3.1 Scope ..................................................... 4
3.2 Overview 6 3.2 Overview .................................................. 5
3.3 Creating Referential Resources 6
3.3.1 The MKREF Method 6 3.3 Creating Referential Resources ............................ 7
3.3.2 Status Codes 7 3.3.1 The MKREF Method .......................................... 7
3.3.3 Example 8 3.3.2 Status Codes .............................................. 8
3.4 Deleting Referential Resources 8 3.3.3 Example ................................................... 8
3.4.1 The DELREF Method 8 3.4 Deleting, Copying, and Moving Referential Resources ....... 9
3.4.2 Status Codes 8 3.5 Listing Referential Members of a Collection ............... 9
3.4.3 Example 8 3.6 Other WebDAV Operations on Redirect Referential Resources . 9
3.4.4 Design Rationale 8 3.7 Other WebDAV Operations on Direct Referential Resources .. 10
3.5 Listing Referential Members of a Collection 9 3.8 HTTP Operations on Redirect Referential Resources ........ 10
3.6 Other WebDAV Operations on Indirect References 9 3.9 HTTP Operations on Direct Referential Resources .......... 11
3.7 HTTP Operations on Indirect References 10 3.10 Operations on Targets of Referential Resources ........... 12
3.8 Operations on Targets of References 11 3.11 Discovering a Targetís References ........................ 12
4 Ordered Collections 11 3.12 Behavior of Dangling Direct References ................... 13
4.1 Overview 11 3.13 Summary of Referencing Headers Required in Responses ..... 16
4.2 Creating an Ordered Collection 11 4 Ordered Collections ...................................... 16
4.2.1 Overview 11 4.1 Overview ................................................. 16
4.2.2 Status Codes 12 4.2 Creating an Ordered Collection ........................... 16
4.2.3 Example 12 4.2.1 Overview ................................................. 16
4.3 Setting the Position of a Collection Member 12 4.2.2 Status Codes ............................................. 17
4.3.1 Overview 12 4.2.3 Example .................................................. 17
4.3.2 Status Codes 13 4.3 Setting the Position of a Collection Member .............. 17
4.3.3 Examples 13 4.3.1 Overview ................................................. 18
4.4 Changing the Semantics of a Collection Ordering 14 4.3.2 Status Codes ............................................. 18
4.5 Changing the Position of a Collection Member 14 4.3.3 Examples ................................................. 18
4.5.1 The ORDERPATCH Method 14 4.4 Changing the Semantics of a Collection Ordering .......... 19
4.5.2 Status Codes 14 4.5 Changing the Position of a Collection Member ............. 19
4.5.3 Example 14 4.5.1 The ORDERPATCH Method .................................... 19
4.5.4 Design Rationale 15 4.5.2 Status Codes ............................................. 19
5 New Headers 16 4.5.3 Example .................................................. 19
5.1 Ref-Target Request Header 16 4.5.4 Design Rationale ......................................... 21
5.2 Ref-Integrity Request Header 16 5 New Headers .............................................. 21
5.3 Pass-Through Request Header 17 5.1 Ref-Target Entity Header ................................. 21
5.4 Resource-Type Response Header 17 5.2 Ref-Type Entity Header ................................... 22
5.5 Ordered Request Header 17 5.3 Ref-Integrity Entity Header .............................. 22
5.6 Position Request Header 18 5.4 Re-Direct Request Header ................................. 23
6 New Properties 18 5.5 Hide-Target Entity Header ................................ 23
6.1 reftarget Property 18 5.6 Resource-Type Entity Header .............................. 23
6.2 refintegrity Property 18 5.7 Ordered Entity Header .................................... 23
6.3 passthrough Property 19 5.8 Position Request Header .................................. 24
6.4 orderingtype Property 19 5.9 DAV-Collections Entity Header ............................ 24
7 New XML Elements 20 6 New Properties ........................................... 24
7.1 reference XML Element 20 6.1 reftarget Property ....................................... 25
7.2 weak XML Element 20 6.2 refintegrity Property .................................... 25
7.3 arbitrary XML Element 20 6.3 reftype Property ......................................... 25
7.4 order XML Element 20 6.4 references Property ...................................... 25
7.5 member XML Element 20 6.5 orderingtype Property .................................... 26
7.6 position XML Element 21 7 New XML Elements ......................................... 26
7.7 first XML Element 21 7.1 reference XML Element .................................... 26
7.8 last XML Element 21 7.2 direct XML Element ....................................... 26
7.9 before XML Element 21 7.3 redirect XML Element ..................................... 26
7.10 after XML Element 22 7.4 weak XML Element ......................................... 26
8 Compliance 22 7.5 unordered XML Element .................................... 27
8.1 Class 3 22 7.6 custom XML Element ....................................... 27
8.2 Class 4 22 7.7 order XML Element ........................................ 27
9 Dependencies on Other Specifications 22 7.8 ordermember XML Element .................................. 27
10 Security Considerations 22
10.1 Redirect Loops 23 7.9 position XML Element ..................................... 28
10.2 References and Denial of Service 23 7.10 first XML Element ........................................ 28
10.3 Malicious Modifications of Ordering 23 7.11 last XML Element ......................................... 28
10.4 Denial of Service and DAV:orderingtype 23 7.12 before XML Element ....................................... 28
11 Internationalization Considerations 23 7.13 after XML Element ........................................ 28
12 IANA Considerations 24 8 Extensions to the DAV:multistatus XML Element ............ 29
13 Copyright 24 9 Capability Discovery ..................................... 29
14 Intellectual Property 24 9.1 Using OPTIONS ............................................ 29
15 Acknowledgements 24 9.2 Example .................................................. 29
16 References 24 10 Dependencies on Other Specifications ..................... 30
17 Authors' Addresses 25 11 Security Considerations .................................. 30
11.1 Redirect Loops ........................................... 30
11.2 References and Denial of Service ......................... 30
11.3 Maintaining Referential Integrity May Reveal Private Locations30
11.4 DAV:references and Denial of Service ..................... 30
11.5 DAV:references and Malicious Deletion of Resources ....... 31
11.6 Malicious Modifications of Ordering ...................... 31
11.7 Denial of Service and DAV:orderingtype ................... 31
12 Internationalization Considerations ...................... 31
13 IANA Considerations ...................................... 31
14 Copyright ................................................ 32
15 Intellectual Property .................................... 32
16 Acknowledgements ......................................... 32
17 References ............................................... 32
18 Authors' Addresses ....................................... 32
19 Appendices ............................................... 33
19.1 Appendix 1 - Extensions to the WebDAV Document Type Definition33
1 Terminology 1 Terminology
The terminology used here follows and extends that in the base The terminology used here follows and extends that in the base WebDAV
WebDAV protocol specification [WebDAV]. protocol specification [WebDAV].
Collection Collection
A resource that contains member resources A resource that contains member resources
Member Resource Member Resource
A resource contained by a collection A resource contained by a collection
Referential Resource (or Reference) Referential Resource (or Reference)
A resource that has no content of its own, but rather is A resource that has no content of its own, but rather is a
a reference to another resource reference to another resource
Ordinary Resource Ordinary Resource
A member resource that is not a reference to another resource A resource that is not a reference to another resource
Target Resource Target Resource
The resource referenced by a referential member of a collection The resource referenced by a referential resource
Direct Reference Direct Reference
A reference that has the property that operations on it are A reference that is resolved by the server, giving the client the
passed through to its target illusion that it is operating directly on the target resource
Indirect Reference Redirect Reference
A reference that has the property that operations on it do A reference that must be resolved by the client
not affect its target
Strong Reference Strong Reference
A reference whose referential integrity is guaranteed by the A reference whose referential integrity is guaranteed by the
server server
Weak Reference Weak Reference
A reference whose referential integrity is not guaranteed by the A reference whose referential integrity is not guaranteed by the
server server
Referential Integrity Referential Integrity
A server guarantees the integrity of a reference if it ensures A server guarantees the integrity of a reference if it ensures
that the reference will not be broken, or enables the that the reference will not be broken, or enables the reference's
reference's owner to ensure that the reference will not be owner to ensure that the reference will not be broken.
broken.
2 Introduction 2 Introduction
The simple collections that the base WebDAV specification supports The simple collections that the base WebDAV specification supports are
are powerful enough to be widely useful. They provide for the powerful enough to be widely useful. They provide for the hierarchical
hierarchical organization of resources, with mechanisms for organization of resources, with mechanisms for creating and deleting
creating and deleting collections, copying and moving them, collections, copying and moving them, locking them, adding resources to
locking them, adding resources to them and deleting resources from them and deleting resources from them, and getting listings of their
them, and getting listings of their members. Delete, copy, move, members. Delete, copy, move, list, and lock operations can be applied
list, and lock operations can be applied recursively, so that a recursively, so that a client can operate on whole hierarchies with a
client can operate on whole hierarchies with a single request. single request.
Many applications, however, need more powerful collections. There Many applications, however, need more powerful collections. There are
are two areas in particular where more powerful functionality is two areas in particular where more powerful functionality is often
often needed: referential resources and ordering. needed: references and ordering.
Referential resources make it possible for many collections, on the References make it possible for many collections, on the same or
same or different servers, to share the same resource. Because different servers, to share the same resource. Because the collections
the collections share the resource by referencing it, only one share the resource by referencing it, only one physical copy of the
physical copy of the resource need exist, and any changes made in resource need exist, and any changes made in the resource are visible
the resource are visible from all the collections that reference from all the collections that reference it.
it.
It is useful for many applications to be able to impose an It is useful for many applications to be able to impose an ordering on a
ordering on a collection. Orderings may be based on property collection. Orderings may be based on property values, but they may be
values, but they may be completely independent of any properties completely independent of any properties on the collectionís member
on the collection's member resources. Orderings based on resources. Orderings based on properties can be obtained using a search
properties can be obtained using a search protocol [DASL], but protocol [DASL], but orderings not based on properties need some other
orderings not based on properties need some other mechanism. mechanism.
Since these two areas are independent of each other, servers may Since these two areas are independent of each other, servers may elect
elect to comply with the Referential Resources section of this to comply with the Referential Resources section of this specification
specification or with the Ordered Collections section or both. or with the Ordered Collections section or both. A server that supports
A server MUST advertise its compliance through its response to referencing MUST support redirect references, and MAY support direct
an OPTIONS request, as specified in [WebDAV]. New values for the references. A server MUST advertise its compliance with particular
DAV header are defined in Section 8 below to support this parts of this specification through its response to an OPTIONS request,
requirement. as specified in Section 9 below.
3 Referential Resources 3 Referential Resources
3.1 Scope 3.1 Scope
[WebDAVReq] distinguishes between "weak" references and "strong" [WebDAVReq] distinguishes between "weak" references and "strong"
references, and also between "indirect" references and "direct" references, and also between "redirect" references and "direct"
references. This specification supports only weak references and references. This specification supports weak references, direct
indirect references, but is designed so that it can be extended references, and redirect references, and is designed so that it can be
to support strong references and direct references in the future. extended to support strong references in the future.
Strong references are references whose integrity is guaranteed by Strong references are references whose integrity is guaranteed by the
the server; weak references are those whose integrity is not server; weak references are those whose integrity is not guaranteed.
guaranteed. Strong references and weak references are both useful Strong references and weak references are both useful in different
in different contexts. Some applications cannot tolerate broken contexts. Some applications cannot tolerate broken links. A software
links. A software development application, for example, must be development application, for example, must be able to rely on the
able to rely on the integrity of references to component modules. integrity of references to component modules. Such applications must be
Such applications must be able to request strong references. Other able to request strong references. Other applications may want to
applications may want to reference target resources on multiple reference target resources on multiple servers, where referential
servers, where referential integrity cannot be guaranteed, and may integrity cannot be guaranteed, and may be less concerned about possible
be less concerned about possible broken references. broken references.
Several considerations led to the decision not to support strong Several considerations led to the decision not to support strong
references in the current specification. First, there are many references in the current specification. First, there are many possible
possible policies that applications and services might use to policies that applications and services might use to enforce referential
enforce referential integrity. integrity.
o Delete strong references when their targets are deleted. o Delete strong references when their targets are deleted.
o Decline to delete targets of strong references. o Decline to delete targets of strong references.
o Notify strong references when their targets have been deleted.
o Let owners of resources decide whether strong references to them are
allowed.
o Notify strong references when their targets have been There appears to be no common practice in this area. Moreover, some of
deleted. the policies have significant security risks.
o Let owners of resources decide whether strong references to
them are allowed.
There appears to be no common practice in this area. Moreover, o Moving a target of strong references could be a security risk to the
some of the policies have significant security risks. owner of the target by revealing secret locations on the target's
server.
o A strong reference could be a security risk to the owner of the
reference by revealing secret locations on his server.
o The presence of strong references to resources on a server could make
it impossible to reclaim space on that server by moving or deleting
those target resources.
o Moving a target of strong references could be a security These considerations together led to the decision not to support strong
risk to the owner of the target by revealing secret references in the short term.
locations on the target's server.
o A strong reference could be a security risk to the owner of 3.2 Overview
the reference by revealing secret locations on his server.
o The presence of strong references to resources on a server A referential resource is a resource that has no content of its own, but
could make it impossible to reclaim space on that server instead references another resource. The resource it references may be
by moving or deleting those target resources. in the same collection as the reference, or in any other collection.
This target resource may be a collection or a simple resource or another
reference, or any other sort of resource that may be defined in the
future. A resource may be the target of any number of referential
resources. To make it possible to distinguish references from ordinary
resources, a new value of the DAV:resourcetype property is defined here.
The DAV:resourcetype property of all references MUST have the value
DAV:reference.
These considerations together led to the decision not to support Redirect references are references that must be resolved by the client.
strong references in the short term. They are simple for servers to implement, straightforward for clients to
use, and have only limited security implications. Any server that
complies with WebDAV referencing MUST provide redirect references.
Operations on indirect references do not affect their target To resolve a redirect reference, the client retrieves the DAV:reftarget
resources, whereas operations on direct references are passed property, whose value is the URI of the target resource. Every
through to their targets. Both indirect and direct references may reference, direct or redirect, MUST have the DAV:reftarget property. If
be useful. Each of these types of references is implemented in a client wishes to operate on the target resource of a redirect
existing systems. Existing HTTP servers are capable of supporting reference, it resolves the reference, and then invokes the operation on
both types of references. In effect, indirect references give the target resource.
clients access to the reference itself, and allow the reference to
bear properties. Direct references, once created, simplify access
to the target resource by hiding from clients the fact that there
is a reference mediating between the client and the target
resource. They also make access to the target more efficient,
eliminating a round trip required by indirect references to get the
URI of the target resource.
Again, it was believed that supporting direct references would be The redirect reference appears to the client as an independent resource
too difficult in the short term. Although convenient, they add no with its own properties. Operations with the URI of the redirect
functionality beyond what is available through indirect references. reference as their request-URI affect the reference, not its target
Existing systems often implement hybrids of direct and indirect resource.
references, for which some operations are passed through to the
target while others are not. This fact muddies the issue of what
exactly WebDAV should support. It also suggests that the
definition of direct references as those for which operations are
passed through to their targets may not really capture a class of
references that are useful. [what else?]
Consequently, it was decided not to support direct references in Direct references, in contrast, are resolved by the server. They give
the short term. the client the illusion that it is operating directly on the target
resource. These references are more complex for the server to
implement, and raise additional security issues. Consequently, servers
are not required to provide direct references in order to be compliant
with WebDAV referencing.
3.2 Overview The default behavior of a direct reference is to apply most operations
directly to its target, so that the client is not aware that a reference
is mediating between it and the target resource. The exceptions are
operations that affect membership in a collection rather than the state
of the target resource. At present, the operations that fall into this
category are DELETE, MOVE, and COPY. These operations are applied to
the reference itself rather than to its target, so that only the
collection containing the reference is affected.
A referential resource is a resource that has no content of its The Re-Direct request header is also provided, to force an operation to
own, but instead references another resource. The resource it be applied to the direct reference itself rather than its target. In
references may be in the same collection or anywhere else. This effect, it makes the reference behave like a redirect reference for that
target resource may be a collection or a simple resource or another request. This header is particularly useful with PROPFIND, to allow
reference, or any other sort of resource that may be defined in the clients to view the referenceís own properties.
future. A resource may be the target of any number of referential
resources.
Since a referential resource is a resource, it can have properties To distinguish between direct and redirect references, a new DAV:reftype
just like any other resource. These properties are completely property is defined, with the values DAV:direct and DAV:redirect. Every
independent of the properties on its target resource. A new reference MUST have the DAV:reftype property. The DAV:reftype property
DAV:reftarget property of referential resources has as its value of a direct reference MUST have the value DAV:direct. The DAV:reftype
the URI of the target resource. property of a redirect reference MUST have the value DAV:redirect.
To make it possible to distinguish referential resources from Although strong references are not currently supported, a new
ordinary resources, a new value of the DAV:resourcetype property DAV:refintegrity property is defined in anticipation of future support
is defined here. The DAV:resourcetype property of all referential for strong references. DAV:refintegrity will allow clients to
resources MUST have the value reference. distinguish between weak and strong references. All references MUST
have this property. Although the only value currently defined for
DAV:refintegrity is DAV:weak, other values may be defined in the future.
Although only weak, indirect references are currently supported, ***** If a server wants to enforce referential integrity outside this
two new DAV properties are defined in anticipation of future protocol, a value of DAV:weak is misleading.
support for strong references and direct references. These
properties, DAV:refintegrity and DAV:passthrough, will allow
clients to distinguish between weak and strong references, and
between indirect and direct references. All referential resources
MUST have these properties. Although the only value currently
defined for DAV:refintegrity is weak, other values may be defined
in the future. Although the only value currently defined for
DAV:passthrough is none, other values may be defined in the future.
3.3 Creating Referential Resources 3.3 Creating Referential Resources
3.3.1 The MKREF Method 3.3.1 The MKREF Method
Referential resources are created using the MKREF method. The Referential resources are created using the MKREF method. The request-
request-URI of the MKREF request identifies the resource to be URI of the MKREF request identifies the resource to be created. The
created. The required Ref-Target header contains the URI of the required Ref-Target header contains the URI of the target resource.
target resource.
An optional Ref-Integrity request header is defined below,
primarily for future support for strong references. The only value
currently defined for this header is "DAV:weak",although other
values may be used by private agreement. "DAV:weak" is the default
value if the header is not present.
An optional Pass-Through request header is defined below, primarily An optional Ref-Integrity general header is defined below, primarily for
for future support for direct references. Currently, its value is future support for strong references. The only value currently defined
always empty, although other values may be used by private for this header is "DAV:weak", although other values may be used by
agreement. The default value is empty if the header is not private agreement. "DAV:weak" is the default value if the header is not
present. present.
***** Does Ref-Integrity = DAV:weak mean that the server need not
enforce referential integrity, or that it must not enforce referential
integrity for the new resource? We have a requirement that there be
some way to request the server not to enforce referential integrity for
a particular reference. You might also want to change from donít-
enforce to enforce at different times in the life of the reference.
An optional Ref-Type general header is defined below, with values
"DAV:direct" and "DAV:redirect". The default value is "DAV:redirect" if
the header is not present.
The optional Hide-Target request header is defined below, to enable the
creator of a direct reference to specify that the DAV:reftarget property
be hidden from clients. If the Hide-Target header is not present, the
server MUST assume that the DAV:reftarget property is not to be hidden.
If the Hide-Target header is used with Ref-Type header set to
DAV:redirect, the server MUST ignore the Hide-Target header. The Ref-
Target header MUST never be returned in response to any request for a
direct reference created with the Hide-Target header.
***** How useful is this really? Isnít it the owner of the target (not
of the reference) who wants to control whether the location of the
target is hidden? True, we have a scenario where the person creating
the reference wants to hide the location of the target, but thatís
because the owner of the reference and the owner of the target are the
same person in that example.
An optional Position request header supports ordered collections by An optional Position request header supports ordered collections by
allowing the client to specify where the new referential member is allowing the client creating a reference to specify where the new member
to be placed in the collection's ordering. (This header can also is to be placed in the collection's ordering. (This header can also be
be used with PUT to create an ordinary collection member at a used with PUT to create an ordinary resource at a specific position in
specific position in the ordering.) the collection ordering.)
When a server processes a MKREF request, it MUST set the When a server processes a MKREF request, it MUST set the
DAV:resourcetype property (defined in [WebDAV]) of the new resource DAV:resourcetype property (defined in [WebDAV]) of the new resource to
to be DAV:reference. be DAV:reference.
When a server processes a MKREF request, it MUST set the When a server processes a MKREF request, it MUST set the DAV:reftarget
DAV:reftarget property to the URI of the target resource. property to the URI of the target resource.
When a server processes a MKREF request, it MUST set the When a server processes a MKREF request, it MUST set the
DAV:refintegrity property and the DAV:passthrough property. DAV:refintegrity property and the DAV:reftype property based on the
values of the Ref-Integrity and Ref-Type headers.
The client MUST NOT send any content with the MKREF request, and so The client MUST NOT send any content with the MKREF request, and so MUST
MUST NOT use the Content-Length or Transfer-Encoding headers. (See NOT use the Content-Length or Transfer-Encoding headers. (See [HTTP].)
[HTTP].)
If a MKREF request is submitted for an existing resource, the If a MKREF request is submitted for an existing resource, the existing
existing resource's content and headers will be overwritten. This resource's content and headers will be overwritten. This behavior is
behavior is analogous to the behavior of the HTTP PUT method. Live analogous to the behavior of the HTTP PUT method. Live properties may
properties may get new values at the server's discretion; dead get new values at the server's discretion; dead properties will retain
properties will retain their existing values. If the Position their existing values. If the Position header is absent in this case
header is absent in this case and the collection is ordered, the and the collection is ordered, the server MUST leave the member at its
server MUST leave the member at its previous position in the previous position in the collection ordering. If the Position header is
collection ordering. If the Position header is present and the present and the collection is ordered, the server MUST remove the member
collection is ordered, the server MUST remove it from its previous from its previous position, and then insert it at the requested
position, and then insert it at the requested position. position.
3.3.2 Status Codes 3.3.2 Status Codes
201 Created 201 (Created): The reference was successfully created.
200 OK: modified an existing resource
409 Conflict: no resource at Ref-Target 200 (OK): The reference was successfully created, replacing an existing
unrecognized / unsupported value for Ref-Integrity resource at the same location.
unrecognized / unsupported value for Pass-Through
400 Bad Request: content not allowed 400 (Bad Request): The client attempted to send content with the
409 Conflict: Position Before / After a URI that is not in this request, or set an invalid value for the Ref-Target, Ref-Integrity, Ref-
collection Type, or Position header.
400 Bad Request: Position Before / After self
409 Conflict: Position header, but not an ordered collection 409 (Conflict): Several conditions may produce this response. There may
425 Insufficient Space on Resource be no resource at the location specified in Ref-Target, on a server that
409 Conflict: Parent collection does not exist prohibits dangling references. The request may be attempting to create
the reference in a collection that does not exist. The request may be
attempting to position the reference before or after a resource that is
not in the collection, or before or after itself. The request may be
attempting to position the reference in an unordered collection.
***** These are not conflicts with the state of the resource at the
request-URI, but conflicts with the state of the parent collection or
the target resource. Is it still appropriate to use 409?
507 (Insufficient Storage): There is not enough space on the server to
complete the request.
3.3.3 Example 3.3.3 Example
Request: Request:
MKREF /~whitehead/dav/spec08.ref HTTP/1.1 MKREF /~whitehead/dav/spec08.ref HTTP/1.1
HOST: www.ics.uci.edu HOST: www.ics.uci.edu
Ref-Target: <http://www.ics.uci.edu/i-d/draft-webdav-protocol- 08.txt> Ref-Target: <http://www.ics.uci.edu/i-d/draft-webdav-protocol- 08.txt>
Response: Response:
HTTP/1.1 201 Created HTTP/1.1 201 Created
This request resulted in the creation of a new referential resource This request resulted in the creation of a new referential resource at
at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the resource
resource identified by the Ref-Target header. Its DAV:resourcetype identified by the Ref-Target header. Its DAV:resourcetype property is
property is set to DAV:reference. Its DAV:reftarget property is set to DAV:reference. Its DAV:reftarget property is set to the URI of
set to the URI of its target resource. Its DAV:refintegrity its target resource. Its DAV:refintegrity property is set to the
property is set to the default value of DAV:weak. Its default value of DAV:weak. Its DAV:reftype property is set to the
DAV:passthrough property is set to the default value of EMPTY. default value of DAV:redirect.
3.4 Deleting Referential Resources 3.4 Deleting, Copying, and Moving Referential Resources
3.4.1 The DELREF Method The DELETE method should be used to delete referential resources. For
both direct and redirect references, DELETE affects the reference
itself, and not its target.
The new DELREF method is used to delete referential resources. A MOVE operation on a referential resource moves the referential
DELREF on a referential resource has no effect on its target resource to a different location, but has no effect on the location of
resource. its target. The DAV:reftarget property is unchanged after a MOVE unless
the Ref-Target header is used to change it.
3.4.2 Status Codes A COPY operation on a referential resource copies the referential
resource, not its target resource, to another location. The
DAV:reftarget property of the destination resource is the same as the
DAV:reftarget of the source resource, unless the Ref-Target header is
used to change it.
200 OK 3.5 Listing Referential Members of a Collection
405 Method Not Allowed: Request-URI is not a reference
404 Not Found: No resource at Request-URI
3.4.3 Example Since a referential member of a collection is just a resource in the
collection, a listing of members of the collection shows referential
members along with ordinary members. That is, a WebDAV PROPFIND request
on a collection resource with Depth = 1 or infinity MUST return a
response XML element for each ordinary member and for each referential
member.
Request: For a redirect reference, the properties returned by the PROPFIND are
the properties of the reference itself. If Depth = infinity in the
PROPFIND request, the server MUST NOT follow redirect references into
any collections to which they may refer.
DELREF /~whitehead/dav/spec08.ref HTTP/1.1 For a direct reference, the properties returned by the PROPFIND are the
HOST: www.ics.uci.edu properties of its target resource. If Depth = infinity in the PROPFIND
request, the server MUST follow direct references into any collections
to which they may refer. That is, if the target resource is a
collection, the server MUST list the members of that collection. If the
Re-Direct header is used with PROPFIND, the server MUST treat any direct
references like redirect references, as described in the previous
paragraph.
Response: 3.6 Other WebDAV Operations on Redirect Referential Resources
HTTP/1.1 200 OK Operations on a redirect reference affect only the reference, and not
its target resource.
The referential resource /~whitehead/dav/spec08.ref has been A LOCK operation on a redirect reference locks the reference, not its
deleted, but its target resource still exists.
3.4.4 Design Rationale target. A LOCK on the collection with Depth = 1 or infinity locks any
redirect references that are members of the collection. It does not
lock the targets of those redirect references.
The HTTP DELETE method can be used to delete indirect references, A PROPPATCH on a redirect reference modifies the properties of the
since by definition these references do not pass operations through reference, not the properties of its target resource.
to their targets.
If direct references are supported in the future, however, a method A PROPFIND on a redirect reference returns the properties of the
distinct from the HTTP DELETE method will be needed for deleting reference, not the properties of its target resource.
the reference itself. Since direct references do pass operations
through to their targets, DELETE would delete the target resource
rather than the reference itself.
DELREF is being introduced now in anticipation of future needs, 3.7 Other WebDAV Operations on Direct Referential Resources
and can be used in all cases where a reference is to be deleted.
3.5 Listing Referential Members of a Collection With the exception of DELETE, MOVE, and COPY, which were discussed
above, operations on direct references affect the target resource, not
the reference, unless the Re-Direct header is used.
Since a referential member of a collection is just a resource in Unless the Re-Direct header is used, a LOCK operation on a direct
the collection, a listing of members of the collection shows reference locks the target. A lock on a direct reference to a
referential members along with ordinary members. That is, a WebDAV collection locks the target collection. A lock on a collection with
PROPFIND request on a collection resource with Depth = 1 or Depth = 1 or infinity locks the targets of the direct references in the
infinity MUST return a response XML element for each ordinary collection.
member and for each referential member.
If Depth = infinity in the PROPFIND request, the server MUST NOT Unless the Re-Direct header is used, a PROPPATCH on a direct reference
follow indirect references into any collections to which they may modifies the properties of its target resource, not the properties of
refer. the reference itself.
3.6 Other WebDAV Operations on Indirect Referential Resources Unless the Re-Direct header is used, a PROPFIND on a direct reference
returns the properties of its target resource, not the properties of the
reference itself.
By definition, operations on an indirect reference affect only the If the Re-Direct header is used with a LOCK, PROPPATCH, or PROPFIND
reference, and not its target resource. Since only indirect request on a direct reference, it behaves as if it were being applied to
references are supported by this specification, WebDAV operations a redirect reference, as specified in Section 3.6.
that are applied to them affect only the referential resource, not
its target resource.
A LOCK operation on an indirect reference locks the referential 3.8 HTTP Operations on Redirect Referential Resources
resource, not its target. A LOCK on the collection with
Depth = 1 or infinity locks the referential members along with all
the other members of the collection, but not the targets of the
indirect referential members.
A PROPPATCH on an indirect referential resource modifies the Although existing HTTP clients cannot create referential resources, they
properties of the referential resource, not the properties of its should be able to read collections created by reference-aware WebDAV
target resource. clients. They should be able to follow any references in those
collections to their targets. To make this possible, a server that
receives a GET or HEAD on a redirect reference MUST return a 302(Moved
Temporarily) status code. The server MUST follow [HTTP] Section 10.3.3
"302 Moved Temporarily," but with these additional rules:
A PROPFIND on an indirect referential resource returns the o The Location header MUST contain the target URI of the reference.
properties of the referential resource, not the properties of its
target resource.
A MOVE operation on an indirect referential resource moves the o The response MUST include all referencing entity headers that make
referential resource to a different location, but has no effect on sense for redirect references: Ref-Type, Ref-Target, and Ref-
the location of its target. The DAV:reftarget property is unchanged Integrity.
after a MOVE unless the Ref-Target header is used to change it.
A COPY operation on an indirect referential resource copies the o The response MUST also include those HTTP headers that make sense for
referential resource, not its target resource, to another location. referential resources, at a minimum: Cache-Control, Age, ETag,
The DAV:reftarget property of the destination resource is the same Expires, and Last-Modified.
as the DAV:reftarget of the source resource, unless the Ref-Target
header is used to change it.
3.7 HTTP Operations on Indirect Referential Resources The second and third of these rules preserve normal GET and HEAD
Although existing HTTP clients cannot create referential resources, behavior for reference-aware WebDAV clients.
they should be able to read collections created by Class 3 WebDAV
clients. They should be able to follow any references in those
collections to their targets. To make this possible, a server that
receives a GET or HEAD on an indirect reference MUST return a 302
(Moved Temporarily) status code. The server MUST follow [HTTP]
Section 10.3.3 "302 Moved Temporarily," but with these additional
rules:
o The Location header MUST contain the target URI of the POST cannot be applied to a redirect reference. A reference cannot
accept another entity as its subordinate. Depending upon the nature of
the target resource, however, it might make sense to apply POST to the
target. A server that receives a POST request on a redirect reference
MUST return a 302 (Moved Temporarily). The rules for constructing and
using the response are the same as for GET and HEAD, except that there
is no requirement to return any headers other than Ref-Type. This header
allows reference-aware WebDAV clients to recognize the resource as a
reference and understand the reason for the redirection.
PUT cannot be applied to a redirect reference. To replace one redirect
reference with another, MKREF MUST be used. To replace a redirect
reference with an ordinary resource, the reference MUST first be deleted
with DELREF, after which a PUT MUST be used to create the ordinary
resource.
Existing HTTP clients that do not understand referential resources need
to be accommodated, however. To enable these clients to operate
reasonably on redirect references, a server that receives a PUT request
on a redirect reference MUST return a 302 (Moved Temporarily). The
client and server MUST follow [HTTP] Section 10.3.3 "302 Moved
Temporarily," but with these additional rules:
o The Location response header MUST contain the target URI of the
reference. reference.
o The response MUST include a Resource-Type header with the o The response MUST include the Ref-Type header. This header allows
value "Reference". This header allows Class 3 WebDAV clients reference-aware WebDAV clients to recognize the resource as a
to recognize the resource as a reference and understand the reference and understand the reason for the redirection.
reason for the redirection.
o The response MUST also include those HTTP headers that make o The response MUST include an entity body for display to users. The
sense for referential resources, at a minimum: Cache-Control, entity body explains that the requested resource is a reference to
Age, ETag, Expires, and Last-Modified. another resource, and allows the user to choose whether to replace
the target resource or to replace the reference.
POST cannot be applied to an indirect reference. A reference This last rule is needed for PUT, but not for GET, HEAD, or POST. Only
cannot accept another entity as its subordinate. Depending upon for PUT does it make sense for the user to confirm that the operation is
the nature of the target resource, however, it might make sense to to be performed at the request-URI. GET or HEAD will already have
apply POST to the target. A server that receives a POST request returned all useful information about the request-URI. POST makes no
on an indirect reference MUST return a 302 (Moved Temporarily). sense for the redirect reference at the request-URI. But the user might
The rules for constructing and using the response are the same as really want to replace the redirect reference with the entity in the PUT
for GET and HEAD, except that there is no requirement to return request.
Cache-Control, Age, ETag, Expires, or Last-Modified.
PUT cannot be applied to an indirect reference. To replace one To enable existing HTTP clients to retrieve the capabilities of the
indirect reference with another, MKREF MUST be used. To replace an target resource, a server that receives an OPTIONS request on a redirect
indirect reference with an ordinary resource, the reference MUST reference MUST return a 302 (Moved Temporarily). At the same time,
first be deleted with DELREF, after which a PUT MUST be used to reference-aware WebDAV clients may need to retrieve the capabilities of
create the ordinary resource. the reference itself. Consequently, the server MUST provide a choice as
to whether the method should be applied to the reference or its target.
Consequently, the same rules apply for OPTIONS as for PUT above.
Existing HTTP clients that do not understand referential resources 3.9 HTTP Operations on Direct Referential Resources
need to be accommodated, however. To enable these clients to
operate reasonably on indirect references, a server that receives a
PUT request on an indirect reference MUST return a 302 (Moved
Temporarily). The client and server MUST follow [HTTP] Section
10.3.3 "302 Moved Temporarily," but with these additional rules:
o The Location response header MUST contain the target URI of GET, HEAD, PUT, POST, and OPTIONS on direct references are passed
the reference. through to their target resources. GET returns the content and headers
of the target resource, HEAD returns the headers of the target resource,
PUT replaces the content of the target resource, POST performs the
expected function at the target resource, and OPTIONS reports the
communication options available at the target resource.
o The response MUST include a Resource-Type header, defined in The Re-Direct request header may be used with GET, HEAD, or OPTIONS to
Section 5.n below, with the value "Reference". This header view the headers or capabilities of the reference, rather than its
allows Class 3 WebDAV clients to recognize the resource as a target. If the Re-Direct header is used, the methodís behavior is as
reference and understand the reason for the redirection. described in Section 3.8.
o The response MUST include an entity body for display to users. The Re-Direct request header must not be used with PUT or POST, which
The entity body explains that the requested resource is a cannot be applied to references. If a server receives a PUT or POST
reference to another resource, and allows the user to choose request on a direct reference with the Re-Direct header, it MUST respond
whether to replace the target resource or to replace the with a 400 (Bad Request).
reference.
This last rule is needed for PUT, but not for GET, HEAD, or ***** Confirm behavior for PUT / POST with Re-Direct.
POST. Only for PUT does it make sense for the user to confirm
that the operation is to be performed at the request-URI. GET or
HEAD will already have returned all useful information about the
request-URI. POST makes no sense for the indirect reference at the
request-URI. But the user might really want to replace the
indirect reference with the entity in the PUT request.
Although the new DELREF method has been defined for deleting 3.10 Operations on Targets of Referential Resources
references, DELETE can be used to delete an indirect reference.
Since by definition operations on an indirect reference affect the
reference, and not its target, DELETE will delete the indirect
reference and leave its target untouched.
3.8 Operations on Targets of Referential Resources In general, operations on targets of weak referential resources have no
effect on the referential resource. However, servers that choose to
maintain the integrity of references are free to make changes to the
state of references when moving or deleting their targets.
Operations on targets of weak, indirect referential resources have When moving a target resource, a server MAY insert an optional step into
no effect on the referential resource. the semantics of MOVE as defined in [WebDAV] for the purpose of
maintaining referential integrity. Between the copy step and the delete
step of a MOVE, the server MAY perform an update step, which changes the
DAV:reftarget property of any references to the target to reflect its
new location.
When deleting a target resource, a server MAY perform any internal
operations necessary to implement its policy on preserving referential
integrity. For example, it might delete any references to the deleted
target, or it might flag them as having a deleted target, or it might
replace references with copies of the target.
3.11 Discovering a Targetís References
An optional DAV:references property on the target resource provides a
list of referential resources whose DAV:reftarget property points to
that target resource. If present, DAV:references is a read-only
property, maintained by the server. By retrieving this property, a
client can discover the URIs of the references that point to the target,
and so can also discover the collections of which those URIs are
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 be supported mainly by
Document Management Systems (DMSs) and other servers that will maintain
the property only for references within their own domain. It is not in
general possible for a server to maintain the property for references on
other servers. If a reference on a different server points to the
target, the server where the target is located is unlikely to know about
that reference. This protocol provides no mechanism for one server to
notify another of the creation of a reference to one of its resources.
Consequently, the list of references in DAV:reftarget may be incomplete.
Rationale: A number of scenarios require clients to navigate from a
target resource to the references that point to it, and to the
collections that contain 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 the DMS, what collections it belongs to. It is also important
in other contexts. For example, some servers enforce referential
integrity by refusing to delete any resource that is referenced by other
resources. In such an environment, the client must be able to discover
the references in order to delete them before attempting to delete the
target.
Once a search capability [DASL] is available, it may be possible for a
client to discover the references that point to a given target by
searching for resources with DAV:reftarget equal to the URI of the
target resource. However, it will be much more efficient for the client
to retrieve a list of references from the target resource.
***** Only if DASL provides search of structured properties or we define
DAV:reftarget as a string value, not an href.
Risks: When deciding whether to support the DAV:references property,
server implementors / administrators should balance the efficiencies it
provides in discovering references against the cost of maintaining the
property and the security risks enumerated in Sections 11.4 and 11.5.
3.12 Behavior of Dangling Direct References
***** Think about chains of direct references.
GET and HEAD respond with 404 (Not Found), but the Ref-Type and Ref-
Target headers are included in the response, so that the client can tell
that it is the target, and not the reference, that was not found. (If
the Hide-Target header was used when creating the reference, then Ref-
Target is not included.)
PUT, MKCOL, and MKREF succeed, creating a new resource at the location
specified by the referenceís DAV:reftarget property.
POST fails with 404 (Not Found), since a nonexistent resource cannot
accept another resource as its subordinate. The Ref-Type and Ref-Target
headers are included in the response, so that the client can tell that
it is the target, and not the reference, that was not found. (If the
Hide-Target header was used when creating the reference, then Ref-Target
is not included.)
OPTIONS fails with 404 (Not Found). The Ref-Type and Ref-Target headers
are included in the response, so that the client can tell that it is the
target, and not the reference, that was not found. (If the Hide-Target
header was used when creating the reference, then Ref-Target is not
included.)
PROPFIND responds with a 207 Multistatus, including a 404 (Not Found) as
the status for the target resource. The DAV:reftype and DAV:reftarget
properties of the references are included in the response. (If the
Hide-Target header was used when creating the reference, then
DAV:reftarget is not included.) Their presence informs the client that
it is the target, not the reference, that was not found. These two
elements are extensions to the DAV:multistatus element as defined in
{WEBDAV].
For example,
Request:
PROPFIND /collection1/directref7 HTTP/1.1
Host: www.somehost.com
Content-Type: text/xml
Content-Length: xxxx
<?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:">
<D:prop xmlns:X="http://www.somehost.com/schemas/x">
<X:author/>
<X:title/>
</D:prop>
</D:propfind>
Response:
HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxxx
<?xml version="1.0" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.somehost.com/collection1/directref7</D:href>
<D:status>HTTP/1.1 404 Not Found</D:status>
<D:reftype><D:direct/></D:reftype>
<D:reftarget>
<D:href>http://www.somehost.com/collection2/file19</D:href>
</D:reftarget>
</D:response>
<D:responsedescription>Target resource not
found.</D:responsedescription>
</D:multistatus>
PROPPATCH responds with a 207 Multistatus, including a 404 (Not Found)
as the status for the target resource. The DAV:reftype and
DAV:reftarget properties of the references are included in the response.
(If the Hide-Target header was used when creating the reference, then
DAV:reftarget is not included.) Their presence informs the client that
it is the target, not the reference, that was not found. These two
elements are extensions to the DAV:multistatus element as defined in
{WEBDAV].
***** Is a response to a PROPPATCH required to be a 207 (Multi-Status),
or could it just be a 404 (Not Found)?
For example,
Request:
PROPPATCH /collection1/directref7 HTTP/1.1
Host: www.somehost.com
Content-Type: text/xml
Content-Length: xxxx
<?xml version="1.0" ?>
<D:propertyupdate xmlns:D="DAV:">
<D:set>
<D:prop xmlns:X="http://www.somehost.com/schemas/x">
<X:author>Pauloosie Padluq</X:author>
<X:title>South Baffin Carvers</X:title>
</D:prop>
</D:set>
</D:propertyupdate>
Response:
HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxxx
<?xml version="1.0" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.somehost.com/collection1/directref7</D:href>
<D:status>HTTP/1.1 404 Not Found</D:status>
<D:reftype><D:direct/></D:reftype>
<D:reftarget>
<D:href>http://www.somehost.com/collection2/file19</D:href>
</D:reftarget>
</D:response>
<D:responsedescription>Target resource not
found.</D:responsedescription>
</D:multistatus>
MOVE, COPY, and DELETE succeed. For MOVE and COPY, the reference at the
destination will be broken, just as the reference at the source was.
If a single resource is being LOCKed or UNLOCKed, the response is a 404
(Not Found). The Ref-Type and Ref-Target headers are included in the
response. (If the Hide-Target header was used when creating the
reference, then Ref-Target is not included.) Their presence informs the
client that it is the target, not the reference, that was not found.
If the dangling reference is a member of a collection that is being
LOCKed or UNLOCKed, the response is a 207 (Multi-Status). The
DAV:status element for the dangling reference is a 404 (Not Found). The
DAV:reftype and DAV:reftarget properties of the references are included
in the response. (If the Hide-Target header was used when creating the
reference, then DAV:reftarget is not included.) Their presence informs
the client that it is the target, not the reference, that was not found.
These two elements are extensions to the DAV:multistatus element as
defined in {WEBDAV].
3.13 Summary of Referencing Headers Required in Responses
This section summarizes the rules that determine which referencing
headers must be included in responses to requests on references.
o Every response to a request on a reference MUST include the Ref-Type
header, so that the client knows that it was operating on a
reference, and whether the operation was applied to the reference
itself or to its target.
o Every response to a request on a direct reference MUST include the
Ref-Target header, unless the reference was created with the Hide-
Target header. This allows the client to tell what resource was
affected by the operation. A request that includes the Re-Direct
header is treated as if it were a request on a redirect reference,
and so the response NEED NOT include the Ref-Target header.
o Every response to a GET or HEAD request on a redirect reference (or
on a direct reference with the Re-Direct header) MUST include all the
referencing entity headers that make sense for redirect references:
Ref-Type, Ref-Target, and Ref-Integrity.
4 Ordered Collections 4 Ordered Collections
4.1 Overview 4.1 Overview
Collections on a compliant server may be ordered, but need not be. Collections on a compliant server may be ordered, but need not be. It
It is up to the client to decide whether a given collection is is up to the client to decide whether a given collection is ordered and,
ordered and, if so, to specify the semantics to be used for if so, to specify the semantics to be used for ordering its members. If
ordering its members. If a collection is ordered, each of its a collection is ordered, each of its members must be in the ordering
members must be in the ordering exactly once, and the ordering must exactly once, and the ordering must not include any resource that is not
not include any resource that is not a member of the collection. a member of the collection. Only one ordering can be attached to any
Only one ordering can be attached to any collection. Multiple collection. Multiple orderings of the same resources can be achieved by
orderings of the same resources can be achieved by creating creating multiple collections referencing those resources, and attaching
multiple collections referencing those resources, and attaching a a different ordering to each collection.
different ordering to each collection.
The server is responsible for enforcing these constraints on The server is responsible for enforcing these constraints on orderings.
orderings. The server MUST remove a resource from the ordering The server MUST remove a resource from the ordering when it is removed
when it is removed from the collection. The server MUST add a from the collection. The server MUST add a resource to the ordering when
resource to the ordering when it is added to the collection. it is added to the collection.
When responding to a PROPFIND on a collection, the server MUST When responding to a PROPFIND on a collection, the server MUST order the
order the response elements according to the ordering defined response elements according to the ordering defined on the collection.
on the collection.
4.2 Creating an Ordered Collection 4.2 Creating an Ordered Collection
4.2.1 Overview 4.2.1 Overview
When a collection is created, the client can request that it be When a collection is created, the client can request that it be ordered
ordered and specify the semantics of the ordering by using the and specify the semantics of the ordering by using the new Ordered
new Ordered header in the MKCOL request, setting its value to the header in the MKCOL request, setting its value to the URI of the
URI of the semantics to be used. If the client does not want the semantics to be used. If the client does not want the collection to be
collection to be ordered, it may omit the Ordered header, or use ordered, it may omit the Ordered header, or use it with the value
it with the value "DAV:arbitrary". "DAV:unordered".
Every collection MUST have the new DAV:orderingtype property, Every collection MUST have the new DAV:orderingtype property, which
which indicates whether the collection is ordered and, if so, indicates whether the collection is ordered and, if so, identifies the
identifies the semantics of the ordering. A value of DAV:arbitrary semantics of the ordering. A value of DAV:unordered indicates that that
indicates that that collection is not ordered. That is, the client collection is not ordered. That is, the client cannot depend on the
cannot depend on the repeatability of the ordering of results from repeatability of the ordering of results from a PROPFIND request. For
a PROPFIND request. Otherwise the value of DAV:orderingtype is an collections that are ordered, DAV:orderingtype SHOULD be set to an href
href that SHOULD point to a resource that contains a definition of that identifies the semantics of the ordering, allowing a human user or
the semantics of the ordering, allowing a human user or software software package to insert new collection members into the ordering
package to insert new collection members into the ordering intelligently. Although the href MAY point to a resource that contains
intelligently. 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 that the collection is to be ordered, but the semantics of the
ordering is not being advertised.
If the Ordered header is present on a MKCOL request, the server If the Ordered header is present on a MKCOL request, the server MUST set
MUST set the collection's DAV:orderingtype property to the value of the collection's DAV:orderingtype property to the value of the Ordered
the Ordered header. If the Ordered header is not present, the header. If the Ordered header is not present, the server MUST treat the
server MUST treat the request as if it had an Ordered header with request as if it had an Ordered header with the value "DAV:unordered",
the value "DAV:arbitrary", meaning that the collection is not meaning that the collection is not ordered. If the collection is
ordered. If the collection is ordered, the server MUST respond to ordered, the server MUST respond to PROPFIND requests on the collection
PROPFIND requests on the collection using the specified ordering. using the specified ordering.
4.2.2 Status Codes 4.2.2 Status Codes
No new error conditions are introduced. No new error conditions are introduced.
4.2.3 Example 4.2.3 Example
Request: Request:
MKCOL /theNorth/ HTTP/1.1 MKCOL /theNorth/ HTTP/1.1
Host: www.server.org Host: www.server.org
Ordered: <http://www.server.org/orderings/compass.html> Ordered: <http://www.server.org/orderings/compass.html>
Response: Response:
HTTP/1.1 201 Created HTTP/1.1 201 Created
In this example, a new, ordered collection was created. Its In this example, a new, ordered collection was created. Its
DAV:orderingtype property has as its value the URI from the DAV:orderingtype property has as its value the URI from the Ordered
Ordered header. In this case, the URI points to a description of header. In this case, the URI points to a description of the semantics
the semantics governing the ordering. As new members are added to governing the ordering. As new members are added to the collection,
the collection, clients or end users can consult the semantics to clients or end users can use the semantics to determine where to
determine how to position the new members in the ordering. position the new members in the ordering.
4.3 Setting the Position of a Collection Member 4.3 Setting the Position of a Collection Member
4.3.1 Overview 4.3.1 Overview
When a new member is added to a collection with MKREF, PUT, COPY, When a new member is added to a collection with MKREF, PUT, COPY, MOVE,
or MOVE, its position in the ordering can be set with the new or LOCK, its position in the ordering can be set with the new Position
Position header. The Position header allows the client to specify header. The Position header allows the client to specify that the
that the member should be first in the collection's ordering, last member should be first in the collection's ordering, last in the
in the collection's ordering, before some other collection member collection's ordering, before some other collection member in the
in the collection's ordering, or after some other collection member collection's ordering, or after some other collection member in the
in the collection's ordering. collection's ordering.
The server MUST insert the new member into the ordering at the The server MUST insert the new member into the ordering at the location
location specified in the Position header, if one is present (and specified in the Position header, if one is present (and if the
if the collection is ordered); otherwise, it MUST append the new collection is ordered); otherwise, it MUST append the new member to the
member to the end of the ordering (if the collection is ordered). end of the ordering (if the collection is ordered). If a PUT or MKREF
If a PUT or MKREF causes an existing resource to be replaced, and causes an existing resource to be replaced, and if the Position header
if the Position header is absent, the server MUST leave the member is absent, the server MUST leave the member at its previous position in
at its previous position in the collection ordering. If the thee collection ordering. If the Position header is present, the server
Position header is present, the server MUST remove the member from MUST remove the member from its previous position, and then insert it at
its previous position, and then insert it at the requested the requested position.
position.
4.3.2 Status Codes 4.3.2 Status Codes
201 Created 201 (Created): The resource was successfully created.
409 Conflict: Before / After a URI that is not in this collection
400 Bad Request: Before / After self 409 (Conflict): The request may be attempting to position the resource
405 Method Not Allowed: Not an ordered collection before or after a resource that is not in the collection, or before or
after itself, or it may be attempting to position the resource in an
unordered collection.
4.3.3 Examples 4.3.3 Examples
Request: Request:
MKREF /~whitehead/dav/spec08.ref HTTP/1.1 MKREF /~whitehead/dav/spec08.ref HTTP/1.1
HOST: www.ics.uci.edu HOST: www.ics.uci.edu
Ref-Target: <http://www.ics.uci.edu/i-d/draft-webdav-protocol-08.txt> Ref-Target: <http://www.ics.uci.edu/i-d/draft-webdav-protocol-08.txt>
Position: After <requirements.html> Position: After <requirements.html>
Response: Response:
HTTP/1.1 201 Created HTTP/1.1 201 Created
This request resulted in the creation of a new referential resource This request resulted in the creation of a new referential resource at
at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to the resource
resource identified by the Ref-Target header. The Position header identified by the Ref-Target header. The Position header in this
in this example caused the server to set its position in the example caused the server to set its position in the ordering of the
ordering of the /~whitehead/dav/ collection immediately after the /~whitehead/dav/ collection immediately after the requirements.html
requirements.html resource. resource.
Request: Request:
MOVE /i-d/draft-webdav-protocol-08.txt HTTP/1.1 MOVE /i-d/draft-webdav-protocol-08.txt HTTP/1.1
Host: www.ics.uci.edu Host: www.ics.uci.edu
Destination: </~whitehead/dav/draft-webdav-protocol-08.txt> Destination: </~whitehead/dav/draft-webdav-protocol-08.txt>
Position: First Position: First
Response: Response:
HTTP/1.1 409 Conflict HTTP/1.1 409 Conflict
In this case, the server returned a 409 Conflict status code In this case, the server returned a 409 Conflict status code because the
because the /~whitehead/dav/ collection is an unordered collection. /~whitehead/dav/ collection is an unordered collection. Consequently,
the server was unable to satisfy the Position header.
Consequently, the server was unable to satisfy the Position
header.
4.4 Changing the Semantics of a Collection Ordering 4.4 Changing the Semantics of a Collection Ordering
After a collection has been created, a client can change its After a collection has been created, a client can change its ordering
ordering semantics, or change an ordered collection to an unordered semantics, or change an ordered collection to an unordered collection or
collection or vice versa, by using PROPPATCH to change the value of vice versa, by using PROPPATCH to change the value of its
its DAV:orderingtype property. The client is then responsible for DAV:orderingtype property. The client is then responsible for updating
updating the ordering of the collection members according to the the ordering of the collection members according to the new semantics.
new semantics. PROPPATCH is defined in [WebDAV], Section 7.2. PROPPATCH is defined in [WebDAV], Section 7.2.
4.5 Changing the Position of a Collection Member 4.5 Changing the Position of a Collection Member
4.5.1 The ORDERPATCH Method 4.5.1 The ORDERPATCH Method
To change the position of a collection member in the collection's To change the positions of collection members in the collection's
ordering, the client MUST use an ORDERPATCH request with a request ordering, the client MUST use an ORDERPATCH request with a request body
body containing an order XML element. The request-URI of an containing an order XML element. The request-URI of an ORDERPATCH
ORDERPATCH request is the URI of the collection whose ordering is request is the URI of the collection whose ordering is to be updated.
to be updated. The order XML element identifies the member The order XML element identifies the member resources whose positions
resource whose position is to be changed, and describes its new are to be changed, and describes their new positions in the ordering.
position in the ordering. The new position can be specified as Each new position can be specified as first in the ordering, last in the
first in the ordering, last in the ordering, before some other ordering, before some other collection member in the ordering, or after
collection member in the ordering, or after some other collection some other collection member in the ordering. The server MUST apply the
member in the ordering. changes in the order they appear in the order element.
4.5.2 Status Codes 4.5.2 Status Codes
Although the protocol currently allows only a single change to be Since multiple changes can be requested in a single ORDERPATCH request,
requested with ORDERPATCH, it is anticipated that this may change the server MUST return a 207 Multi-Status response, as defined in
in the future. Consequently, the server MUST return a 207 [WebDAV].
Multi-Status response, as defined in [WebDAV].
Within the 207 Multi-Status response, the following status codes Within the 207 Multi-Status response, the following status codes are
are possible: possible:
200 OK 200 (OK): The change in ordering was successfully made.
409 Conflict: Before / After a URI that is not in this collection
409 Conflict: href doesn't point to a member of this collection 409 (Conflict): An attempt was made to position the resource before or
400 Bad Request: only one change allowed after a resource that is not in the collection, or before or after
400 Bad Request: Before / After self itself, or an attempt was made to position the resource in an unordered
405 Method Not Allowed: Not an ordered collection collection.
405 Method Not Allowed: Not a collection
(It's ok to reposition to the same position) A request to reposition a collection member to the same place in the
ordering is not an error.
4.5.3 Example 4.5.3 Example
Consider a collection /coll-1/ with members ordered as follows: Consider a collection /coll-1/ with members ordered as follows:
nunavut.map nunavut.map
nunavut.img nunavut.img
baffin.map baffin.map
baffin.desc baffin.desc
baffin.img baffin.img
iqaluit.map iqaluit.map
nunavut.desc nunavut.desc
iqaluit.desc
iqaluit.img iqaluit.img
iqaluit.desc
Request: Request:
ORDERPATCH /coll-1/ HTTP/1.1 ORDERPATCH /coll-1/ HTTP/1.1
Host: www.nunanet.com Host: www.nunanet.com
Content-Type: text/xml Content-Type: text/xml
Content-Length: xxx Content-Length: xxx
<?xml version="1.0" ?> <?xml version="1.0" ?>
<?xml:namespace ns="DAV:" prefix="d" ?> <d:order xmlns:d="DAV:">
<d:order> <d:ordermember>
<d:member>
<d:href>nunavut.desc</d:href> <d:href>nunavut.desc</d:href>
<d:position> <d:position>
<d:after> <d:after>
<d:href>nunavut.map</d:href> <d:href>nunavut.map</d:href>
</d:after> </d:after>
</d:position> </d:position>
</d:member> </d:ordermember>
<d:ordermember>
<d:href>iqaluit.img</d:href>
<d:position>
<d:last/>
</d:position>
</d:ordermember>
</d:order> </d:order>
Response: Response:
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: text/xml Content-Type: text/xml
Content-Length: xxx Content-Length: xxx
<?xml version="1.0" ?> <?xml version="1.0" ?>
<?xml:namespace ns="DAV:" prefix="d" ?> <d:multistatus xmlns:d="DAV:">
<d:multistatus>
<d:response> <d:response>
<d:href>http://www.nunanet.com/coll-1/nunavut.desc</d:href> <d:href>http://www.nunanet.com/coll-1/nunavut.desc</d:href>
<d:status>HTTP/1.1 200 OK</d:status> <d:status>HTTP/1.1 200 OK</d:status>
</d:response> </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> </d:multistatus>
In this example, after the request has been processed, the In this example, after the request has been processed, the collection's
map of nunavut is the first member in the collection's ordering: ordering is as follows:
nunavut.map nunavut.map
nunavut.desc nunavut.desc
nunavut.img nunavut.img
baffin.map baffin.map
baffin.desc baffin.desc
baffin.img baffin.img
iqaluit.map iqaluit.map
iqaluit.desc iqaluit.desc
iqaluit.img iqaluit.img
skipping to change at line 828 skipping to change at line 1125
nunavut.desc nunavut.desc
nunavut.img nunavut.img
baffin.map baffin.map
baffin.desc baffin.desc
baffin.img baffin.img
iqaluit.map iqaluit.map
iqaluit.desc iqaluit.desc
iqaluit.img iqaluit.img
4.5.4 Design Rationale 4.5.4 Design Rationale
The decision to introduce the new ORDERPATCH method was made after The decision to introduce the new ORDERPATCH method was made after
investigating the possibility of using the existing MOVE method investigating the possibility of using the existing MOVE method with a
with a Position header. The use of MOVE initially looked Position header. The use of MOVE initially looked appealingly simple:
appealingly simple:
MOVE /root/coll-1/foo HTTP/1.1 MOVE /root/coll-1/foo HTTP/1.1
Host: www.somehost.com Host: www.somehost.com
Destination: </root/coll-1/foo> Destination: </root/coll-1/foo>
Position: First Position: First
Unfortunately, several features of the semantics of MOVE make it Unfortunately, several features of the semantics of MOVE make it
unsuitable for changing the position of a collection member in the unsuitable for changing the position of a collection member in the
collection's ordering. First, [WebDAV] defines MOVE as logically collection's ordering. First, [WebDAV] defines MOVE as logically
equivalent to a copy followed by a delete of the source resource. equivalent to a copy followed by a delete of the source resource. This
This definition makes it impossible to MOVE a resource to a definition makes it impossible to MOVE a resource to a destination URL
destination URL that is the same as the source URL. The resource that is the same as the source URL. The resource would be deleted
would be deleted rather than moved. Second, [WebDAV] states that rather than moved. Second, [WebDAV] states that when moving a resource
when moving a resource to a destination where a resource already to a destination where a resource already exists, the Overwrite header
exists, the Overwrite header must be "T", and in this case the must be "T", and in this case the server must DELETE the resource at the
server must DELETE the resource at the destination before destination before performing the MOVE. Again, this makes it impossible
performing the MOVE. Again, this makes it impossible to MOVE to MOVE a resource to the same location. Finally, [WebDAV] states that
a resource to the same location. Finally, [WebDAV] states that
locks are lost on a MOVE, an outcome that seems undesirable in this locks are lost on a MOVE, an outcome that seems undesirable in this
case. case.
The decision to allow only a single change to be described in a
PROPPATCH request was made in order to accommodate many existing
systems that do not allow multiple changes to be requested at once.
However, the protocol design is extensible to support multiple
requests in the future.
In particular, the decision to define a new order XML element for
ORDERPATCH was made for the sake of extensibility. Although the
current definition of the order XML element allows only a single
change in the ordering per ORDERPATCH request, using an XML element
keeps open the option of later allowing multiple changes to be
described in a single ORDERPATCH request. Similarly, a
Multi-Status response is used in order to keep open the option of
multiple changes in a single request in the future.
5 New Headers 5 New Headers
5.1 Ref-Target Request Header ***** Decide which headers intended for MKREF also can be used with
MOVE, COPY, LOCK. Is it possible to create a referential resource by
invoking LOCK? If so, Ref-Type, Ref-Target, and Ref-Integrity would all
have to be usable with LOCK. We might need a Resource-Type header to
say that it is a reference we are creating. What about MOVE and COPY?
At the moment, weíre saying you can change Ref-Type, Ref-Target, and
Ref-Integrity on a MOVE or COPY. It would be pretty weird to change
Resource-Type. What about Hide-Target?
5.1 Ref-Target Entity Header
Ref-Target = "Ref-Target" ":" Coded-url Ref-Target = "Ref-Target" ":" Coded-url
Coded-url is defined in [WebDAV], Section 8.4. Coded-url is defined in [WebDAV], Section 8.4.
The Ref-Target request header is used with the MKREF method to The Ref-Target header is used with the MKREF method to identify the
identify the target resource of the new referential resource being target resource of the new referential resource being created. It is a
created. It is a required header in MKREF requests. This header required header in MKREF requests. This header may also be used with
may also be used with COPY and MOVE requests to change the target COPY and MOVE requests to change the target of the destination
of the destination reference. reference.
Servers MUST include the Ref-Target header in the following responses
unless the Hide-Target header was used when the reference was created,
in which case the Ref-Target header MUST NOT be included in responses:
o Responses to GET and HEAD requests on redirect references
o Responses to all requests on direct references, unless the request
included the Re-Direct header
5.2 Ref-Type Entity Header
Ref-Type = "Ref-Type" ":" ("DAV:direct" | "DAV:redirect")
The Ref-Type header is defined to distinguish between direct and
redirect references. The possible values of this header are DAV:direct
and DAV:redirect. If the header is not present on a MKREF request, the
server MUST treat the request as if it has a Ref-Type header with the
value DAV:redirect. This header may also be used with a COPY or MOVE
request on a reference. If this header is not present on a COPY or MOVE
request, the DAV:reftype property MUST be treated like any other live
property, as specified in [WebDAV] sections 7.8.2 and 7.9.1.
Servers MUST include the Ref-Target header in the following responses:
o Responses to all requests on both direct and redirect references
5.3 Ref-Integrity Entity Header
5.2 Ref-Integrity Request Header
Ref-Integrity = "Ref-Integrity" ":" ("DAV:weak") Ref-Integrity = "Ref-Integrity" ":" ("DAV:weak")
The Ref-Integrity header is defined to allow future support for The Ref-Integrity header is defined to allow future support for strong
strong references. It specifies whether the server should references. It specifies whether the server should enforce referential
enforce referential integrity for a referential resource being integrity for a referential resource being created with MKREF. The only
created with MKREF. The only value currently defined for the value currently defined for the Ref-Integrity header is "DAV:weak",
Ref-Integrity header is "DAV:weak", which means that the server which means that the server need not enforce referential integrity for
need not [should not? must not?] enforce referential integrity for
the newly created reference. Other values may be used by private the newly created reference. Other values may be used by private
agreement between the client and server. If the header is not agreement between the client and server. If the header is not present
present on a MKREF request, the server MUST treat the request as on a MKREF request, the server MUST treat the request as if it has a
if it has a Ref-Integrity header set to "DAV:weak". This header Ref-Integrity header set to "DAV:weak". This header may also be used
may also be used with COPY and MOVE requests. If this header is with COPY and MOVE requests. If this header is not present on a COPY or
not present on a COPY or MOVE request, the DAV:refintegrity MOVE request, the DAV:refintegrity property MUST be treated like any
property MUST be treated like any other live property, as other live property, as specified in [WebDAV] sections 7.8.2 and 7.9.1.
specified in [WebDAV] sections 7.8.2 and 7.9.1.
5.3 Pass-Through Request Header ***** Again, does DAV:weak mean that the server need not maintain
referential integrity, or that it must not?
Pass-Through = "Pass-Through" ":" "" Servers MUST include the Ref-Integrity header in the following
responses:
The Pass-Through header is defined to allow future support for o Responses to GET and HEAD requests on redirect references (or on
direct references. Indirect references do not pass operations direct references if the request included the Re-Direct header)
through to their target resources, so for them the value of
the Pass-Through header is empty. Direct references pass all
operations through to their target resources. Other types of
references may pass certain operations through, while others may
affect the reference itself. Since only indirect references are
supported today, the only value currently defined for Pass-Through
is empty. Other values may be used by private agreement between
the client and server. If the header is not present on a MKREF
request, the server MUST treat the request as if it has a
Pass-Through header with the value empty. This header may also be
used with a COPY or MOVE request on a reference. If this header is
not present on a COPY or MOVE request, the DAV:passthrough
property MUST be treated like any other live property, as
specified in [WebDAV] sections 7.8.2 and 7.9.1.
5.4 Resource-Type Response Header 5.4 Re-Direct Request Header
Resource-Type = "Resource-Type" ":" ["DAV:collection" | Re-Direct = "Re-Direct" ":"
"DAV:reference" | ""]
The Resource-Type response header contains the value of the The optional Re-Direct header can be used on any request to a direct
DAV:resourcetype property. It is used with 302 responses to PUT, reference except PUT or POST. It forces the reference to behave like a
POST, GET, or HEAD requests on referential resources to indicate to redirect reference for that request. The operation will be applied to
the client that the reason for the redirection is that the the reference itself, not to its target. If the Re-Direct header is
request-URI pointed to a referential resource. used on a request to any other sort of resource besides a direct
reference, the server SHOULD ignore it. If the Re-Direct header is used
with a PUT or POST request on a direct reference, the server MUST
respond with a 400 (Bad Request).
5.5 Ordered Request Header ***** Confirm behavior for exception cases.
Ordered = "Ordered" ":" ("DAV:arbitrary" | Coded-url) ***** What if there is a chain of direct references? Suppose I want to
see the properties of the second reference in the chain - how would I do
that?
The Ordered request header may be used with MKCOL to request that 5.5 Hide-Target Entity Header
the new collection be ordered and to specify its ordering
semantics. A value of "DAV:arbitrary" indicates that the
collection is not ordered. That is, the client cannot depend on
the repeatability of the ordering of results from a PROPFIND
request. A Coded-url value indicates that the collection is
ordered, and identifies the semantics of the ordering. The
Coded-url SHOULD point to a resource that contains a definition of
the semantics of the ordering, allowing a human user or software
package to insert new collection members into the ordering
intelligently.
If the Ordered header is not present on a MKCOL request, the Hide-Target = "Hide-Target" ":"
server MUST treat the request as if it had an Ordered header with
the value "DAV:arbitrary".
5.6 Position Request Header The optional Hide-Target header is for use when creating a new direct
reference. It specifies that the URI of the target resource is to be
hidden. If this header is used when creating a direct reference, the
server MUST NOT include the Ref-Target header in any response to a
request on the reference. If the Hide-Target header is not present, the
server MUST assume that the DAV:reftarget property is not to be hidden.
If the Hide-Target header is used in a request with Ref-Type =
DAV:redirect, the server MUST ignore the Hide-Target header.
***** If we want to let clients change their minds about Hide-Target
after a reference has been created, we need a DAV:hidetarget property to
allow that.
5.6 Resource-Type Entity Header
Resource-Type = "Resource-Type" ":" ["DAV:collection" | "DAV:reference"
|""]
The Resource-Type header contains the value of the DAV:resourcetype
property. It is used with LOCK, MOVE, or COPY to set or change the
resource type.
***** Not needed unless you can create a reference with LOCK, or change
resource type with MOVE or COPY.
5.7 Ordered Entity Header
Ordered = "Ordered" ":" ("DAV:unordered" | "DAV:custom" | Coded-url)
The Ordered header may be used with MKCOL to request that the new
collection be ordered and to specify its ordering semantics. A value of
"DAV:unordered" indicates that the collection is not ordered. That is,
the client cannot depend on the repeatability of the ordering of results
from a PROPFIND request. A Coded-url value indicates that the collection
is ordered, and identifies the semantics of the ordering, allowing a
human user or software package to insert new collection members into the
ordering intelligently. The Coded-url MAY point to a resource that
contains a definition of the semantics of the ordering. A value of
"DAV:custom" indicates that the collection is to be ordered, but the
semantics of the ordering is not being advertised.
If the Ordered header is not present on a MKCOL request, the server MUST
treat the request as if it had an Ordered header with the value
"DAV:unordered".
5.8 Position Request Header
Position = "Position" ":" ("First" | "Last" | Position = "Position" ":" ("First" | "Last" |
(("Before" | "After") Coded-url)) (("Before" | "After") Coded-url))
The Position header may be used with MKREF, PUT, COPY, or MOVE to The Position header may be used with MKREF, PUT, COPY, MOVE, or LOCK to
tell the server where in the collection ordering to position the tell the server where in the collection ordering to position the
resource being added to the collection. It may be used for both resource being added to the collection. It may be used for both
ordinary and referential members. ordinary and referential members.
If the Coded-url is a relative URL, it is interpreted relative to If the Coded-url is a relative URL, it is interpreted relative to the
the collection in which the resource is being created. collection in which the resource is being created.
If the Position request header is not used, then: If the Position request header is not used, then:
If the request is replacing an existing resource, the server If the request is replacing an existing resource, the server MUST
MUST preserve the present ordering. preserve the present ordering.
If the request is adding a new member to the collection, the If the request is adding a new member to the collection, the server MUST
server MUST append the new member to the end of the ordering append the new member to the end of the ordering (if the collection is
(if the collection is ordered). ordered).
5.9 DAV-Collections Entity Header
DAV-Collections = "DAV-Collections" ":" 1#collection-capability
collection-capability = "DAV:basicref" | "DAV:directref" |
"DAV:orderedcoll"
The DAV-Collections header is used in responses to OPTIONS requests, to
enumerate the collection-related capabilities of the resource. A value
of "DAV:basicref" indicates that the resource provides basic referencing
(redirect references). A value of "DAV:directref" indicates that the
resource provides direct references. If a resource provides direct
references, it MUST also provide redirect references. A value of
"DAV:orderedcoll" indicates that the resource provides ordered
collections.
6 New Properties 6 New Properties
6.1 reftarget Property 6.1 reftarget Property
Name: reftarget Name: reftarget
Namespace: DAV: Namespace: DAV:
Purpose: A required property of referential resources that Purpose: A required property of referential resources that provides
provides an efficient way for clients to discover an efficient way for clients to discover the URI of the
the URI of the target resource. This is a readonly target resource. This is a read-only property, whose value
property, whose value can only be set by using the can only be set by using the Ref-Target header with a MKREF,
Ref-Target header with a MKREF, COPY, or MOVE COPY, or MOVE request.
request.
Value: URI of the target resource. Value: URI of the target resource.
<!ELEMENT reftarget href> <!ELEMENT reftarget href>
6.2 refintegrity Property 6.2 refintegrity Property
Name: refintegrity Name: refintegrity
Namespace: DAV: Namespace: DAV:
Purpose: A required property of a referential resource that Purpose: A required property of a referential resource that indicates
indicates whether the server guarantees referential whether the server guarantees referential integrity for that
integrity for that reference. The refintegrity reference. The refintegrity property is defined to allow
property is defined to allow future support for future support for strong references. The only value
strong references. The only value currently currently defined for refintegrity is weak, which means that
defined for refintegrity is weak, which means that
the server need not [does not?] enforce referential the server need not [does not?] enforce referential
integrity for the reference. Other values may be integrity for the reference. Other values may be used by
used by private agreement between the client and private agreement between the client and server. This is a
server. This is a readonly property, whose value readonly property, whose value can only be set by using the
can only be set by using the Ref-Integrity header Ref-Integrity header with a MKREF, COPY, or MOVE request.
with a MKREF, COPY, or MOVE request.
Value: weak Value: weak
<!ELEMENT refintegrity (weak)> <!ELEMENT refintegrity (weak)>
6.3 passthrough Property 6.3 reftype Property
Name: passthrough Name: reftype
Namespace: DAV Namespace: DAV
Purpose: A required property of a referential resource that Purpose: A required property of a referential resource that
indicates what operations are passed through to its identifies the reference as direct or redirect. This is a
target resource. The passthrough property is read-only property, whose value can only be set by using
defined to allow future support for direct the Ref-Type header with a MKREF, COPY, or MOVE request.
references, which pass all operations through to Value: direct | redirect
their targets. This specification currently
supports only indirect references, which do not
pass any operations through to their targets. The
only value currently defined for passthrough is
EMPTY. Other values may be used by private
agreement between the client and server. This is
a read-only property, whose value can only be set
by using the Pass-Through header with a MKREF,
COPY, or MOVE request.
Value: EMPTY
<!ELEMENT passthrough EMPTY> <!ELEMENT reftype (direct | redirect)>
6.4 orderingtype Property 6.4 references Property
Name: references
Namespace: DAV:
Purpose: Enables clients to discover, for any target resource, what
references point to it and what collections contain it by
reference. This is an optional property. If present, it is
a read-only property, maintained by the server.
Value: List of the URIs of the references that point to the target
resource.
<!ELEMENT references (href*)>
6.5 orderingtype Property
Name: orderingtype Name: orderingtype
Namespace: DAV: Namespace: DAV:
Purpose: Indicates whether the collection is ordered and, if Purpose: Indicates whether the collection is ordered and, if so,
so, uniquely identifies the semantics of the uniquely identifies the semantics of the ordering being
ordering being used. SHOULD also provide an used. May also point to an explanation of the semantics in
explanation of the semantics in human and / or human and / or machine-readable form. At a minimum, this
machine-readable form. At a minimum, this allows allows human users who add members to the collection to
human users who add members to the collection to
understand where to position them in the ordering. understand where to position them in the ordering.
Value: arbitrary for an unordered collection, or a URI Value: unordered for an unordered collection, or a URI that
that uniquely identifies the semantics of the uniquely identifies the semantics of the collection's
collection's ordering. The URI SHOULD point to ordering. The URI MAY point to a definition of the ordering
a definition of the ordering semantics. semantics. The value custom may be used for a collection
that is to be ordered, but for which the semantics are not
being advertised.
<!ELEMENT orderingtype (arbitrary | href) > <!ELEMENT orderingtype (arbitrary | custom | href) >
7 New XML Elements 7 New XML Elements
7.1 reference XML Element 7.1 reference XML Element
Name: reference Name: reference
Namespace: DAV: Namespace: DAV:
Purpose: A new value of the DAV:resourcetype property that Purpose: A new value of the DAV:resourcetype property that identifies
identifies its resource as a referential resource. its resource as a referential resource. The
The DAV:resourcetype property of a referential DAV:resourcetype property of a referential resource MUST
resource MUST have this value. have this value.
Value: EMPTY Value: EMPTY
<!ELEMENT reference EMPTY > <!ELEMENT reference EMPTY >
7.2 weak XML Element 7.2 direct XML Element
Name: direct
Namespace: DAV:
Purpose: A value for the DAV:reftype property that identifies its
resource as a direct reference.
Value: EMPTY
<!ELEMENT direct EMPTY >
7.3 redirect XML Element
Name: redirect
Namespace: DAV:
Purpose: A value for the DAV:reftype property that identifies its
resource as a redirect reference.
Value: EMPTY
<!ELEMENT redirect EMPTY >
7.4 weak XML Element
Name: weak Name: weak
Namespace: DAV: Namespace: DAV:
Purpose: The only value currently defined for the Purpose: The only value currently defined for the DAV:refintegrity
DAV:refintegrity property. It means that the property. It means that the server need not [does not?]
server need not [does not?] enforce referential enforce referential integrity for the reference to which the
integrity for the reference to which the property property belongs.
belongs.
Value: EMPTY Value: EMPTY
<!ELEMENT weak EMPTY > <!ELEMENT weak EMPTY >
7.3 arbitrary XML Element 7.5 unordered XML Element
Name: arbitrary Name: unordered
Namespace: DAV: Namespace: DAV:
Purpose: A value of the DAV:orderingtype property that Purpose: A value of the DAV:orderingtype property that indicates that
indicates that the collection is not ordered. That the collection is not ordered. That is, the client cannot
is, the client cannot depend on the repeatability depend on the repeatability of the ordering of results from
of the ordering of results from a PROPFIND request. a PROPFIND request.
Value: EMPTY Value: EMPTY
<!ELEMENT arbitrary EMPTY > <!ELEMENT unordered EMPTY >
7.4 order XML Element 7.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 >
7.7 order XML Element
Name: order Name: order
Namespace: DAV Namespace: DAV:
Purpose: For use with the new ORDERPATCH method. Describes Purpose: For use with the new ORDERPATCH method. Describes a change
a change to be made in a collection ordering. to be made in a collection ordering.
Value: A description of the new position of a collection Value: A description of the new positions of collection members in
member in the collection's ordering. the collection's ordering.
<!ELEMENT order member > <!ELEMENT order (member+) >
7.5 member XML Element 7.8 ordermember XML Element
Name: member
Namespace: DAV
Purpose: Occurs in the order XML Element, and describes the
new position of a single collection member in the
collection's ordering.
Value: An href containing the relative URI of the
collection member, and a description of its new
position in the ordering. The href XML element is
defined in [WebDAV], Section 11.3.
<!ELEMENT member (href, position) > Name: ordermember
Namespace: DAV:
Purpose: Occurs in the order XML Element, and describes the new
position of a single collection member in the collection's
ordering.
Value: An href containing the relative URI of the collection
member, and a description of its new position in the
ordering. The href XML element is defined in [WebDAV],
Section 11.3.
7.6 position XML Element <!ELEMENT ordermember (href, position) >
7.9 position XML Element
Name: position Name: position
Namespace: DAV Namespace: DAV:
Purpose: Occurs in the member XML element. Describes the Purpose: Occurs in the member XML element. Describes the new
new position in a collection's ordering of one of position in a collection's ordering of one of the
the collection's members. collection's members.
Value: The new position can be described as first in the Value: The new position can be described as first in the
collection's ordering, last in the collection's collection's ordering, last in the collection's ordering,
ordering, before some other member of the before some other member of the collection, or after some
collection, or after some other member of the other member of the collection.
collection.
<!ELEMENT position (first | last | before | after)> <!ELEMENT position (first | last | before | after)>
7.7 first XML Element 7.10 first XML Element
Name: first Name: first
Namespace: DAV Namespace: DAV:
Purpose: Occurs in the position XML element. Describes the Purpose: Occurs in the position XML element. Describes the
collection member's position as first in the collection member's position as first in the collection's
collection's ordering. ordering.
Value: EMPTY Value: EMPTY
<!ELEMENT first EMPTY > <!ELEMENT first EMPTY >
7.8 last XML Element 7.11 last XML Element
Name: last Name: last
Namespace: DAV Namespace: DAV:
Purpose: Occurs in the position XML element. Describes the Purpose: Occurs in the position XML element. Describes the
collection member's position as last in the collection member's position as last in the collection's
collection's ordering. ordering.
Value: EMPTY Value: EMPTY
<!ELEMENT last EMPTY > <!ELEMENT last EMPTY >
7.9 before XML Element 7.12 before XML Element
Name: before Name: before
Namespace: DAV Namespace: DAV:
Purpose: Occurs in the position XML element. Describes the Purpose: Occurs in the position XML element. Describes the
collection member's position as coming before some collection member's position as coming before some other
other collection member in the collection's collection member in the collection's ordering.
ordering.
Value: href of the member it precedes in the ordering Value: href of the member it precedes in the ordering
<!ELEMENT before href > <!ELEMENT before href >
7.10 after XML Element 7.13 after XML Element
Name: after Name: after
Namespace: DAV Namespace: DAV:
Purpose: Occurs in the position XML element. Describes the Purpose: Occurs in the position XML element. Describes the
collection member's position as coming after some collection member's position as coming after some other
other collection member in the collection's collection member in the collection's ordering.
ordering.
Value: href of the member it follows in the ordering Value: href of the member it follows in the ordering
<!ELEMENT after href > <!ELEMENT after href >
8 Compliance 8 Extensions to the DAV:multistatus XML Element
Section 14 of [Goland et al, 1998] defined a DAV header for use As described in Section 3.12, the DAV:reftype property and the
when responding to OPTIONS requests. This header provides a way DAV:reftarget property may be returned in the DAV:response element of a
for clients to discover which parts of WebDAV a resource supports. 207 Multi-Status response, to indicate that a problem is not with a
The WebDAV specifications define numbered compliance classes direct reference, but with its target resource.
corresponding to collections of related functions that resources
may support. When the server receives an OPTIONS request, it lists
the classes that the request-URI supports in the DAV response
header.
Since this specification defines two independent sets of Consequently, the definition of the DAV:response XML element changes to
functionality, it defines two new compliance classes. A WebDAV the following:
server may support neither, one or the other, or both for any
resource.
8.1 Class 3 <!ELEMENT response (href, ((href*, status, reftype?, reftarget?) |
(propstat+)), responsedescription?) >
This new compliance class indicates compliance with Section 3 9 Capability Discovery
"Referential Resources" of this specification. Servers that comply
with Section 3 MUST list this class in the DAV response header
when they respond to an OPTIONS request.
8.2 Class 4 9.1 Using OPTIONS
This new compliance class indicates compliance with Section 4 Since referencing and ordering are independent capabilities, a resource
"Ordered Collections" of this specification. Servers that comply MAY support either or both. A resource that provides referencing MUST
with Section 4 MUST list this class in the DAV response header support redirect references, and MAY in addition support direct
when they respond to an OPTIONS request. references. A response to an OPTIONS request MUST indicate which of
these capabilities the resource supports.
9 Dependencies on Other Specifications This specification defines two new methods: MKREF in support of
referencing, and ORDERPATCH in support of ordering. The response MUST
indicate which of these methods the resource allows. In addition, the
response MUST include the DAV-Collections header, listing those of the
three collection-related capabilities the resource provides. Possible
values for the DAV-Collections header are DAV:basicref, DAV:directref,
and DAV:orderedcoll.
9.2 Example
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-Collections: DAV:basicref, DAV:directref, DAV:orderedcoll
This response indicates that the resource /somecollection/ provides
basic referencing, direct references, and ordered collections.
10 Dependencies on Other Specifications
TBD TBD
10 Security Considerations 11 Security Considerations
This section is provided to detail issues concerning security This section is provided to detail issues concerning security
implications of which WebDAV applications need to be aware. implications of which WebDAV applications need to be aware.
All of the security considerations of HTTP/1.1 and the base WebDAV All of the security considerations of HTTP/1.1 and the base WebDAV
protocol also apply to WebDAV collections. In addition, protocol also apply to WebDAV collections. In addition, referential
referential resources and ordered collections introduce several resources and ordered collections introduce several new security
new security concerns and increase the risk of some existing concerns and increase the risk of some existing threats. These issues
threats. These issues are detailed below. are detailed below.
10.1 Redirect Loops 11.1 Redirect Loops
Although redirect loops were already possible in HTTP 1.1, the Although redirect loops were already possible in HTTP 1.1, the
introduction of referential resources creates a new avenue for introduction of referential resources creates a new avenue for clients
clients to create loops accidentally or maliciously. If the to create loops accidentally or maliciously. If the referential
referential resource and its target are on the same server, the resource and its target are on the same server, the server may be able
server may be able to detect MKREF requests that would create to detect MKREF requests that would create loops. See also [HTTP],
loops. See also [HTTP], Section 10.3 "Redirection 3xx." Section 10.3 "Redirection 3xx."
10.2 References and Denial of Service 11.2 References and Denial of Service
The introduction of referential resources creates a new avenue The introduction of referential resources creates a new avenue for
for denial of service attacks. Clients can create heavily used denial of service attacks. Clients can create heavily used references to
references to target locations that were not designed for heavy target locations that were not designed for heavy usage.
usage.
10.3 Malicious Modifications of Ordering 11.3 Maintaining Referential Integrity May Reveal Private Locations
Particularly in large collections, moving a collection member to Although this specification does not require servers to maintain
a different position in the ordering can make it very difficult referential integrity, it does not prevent them from doing so. If a
for users to find. server updates a referenceís DAV:reftarget property when its target
resource is moved, there is the risk that a private location will be
revealed in the new value of DAV:reftarget. Clients can avoid this risk
by doing a COPY followed by a DELETE rather than a MOVE.
10.4 Denial of Service and DAV:orderingtype If the owner of the target also owns the direct reference to it, the
Hide-Target header can be used when creating the direct reference to
prevent others from discovering the location of the target through that
reference.
There may be some risk of denial of service at sites that are 11.4 DAV:references and Denial of Service
advertised in the DAV:orderingtype property of collections.
However, it is anticipated that widely-deployed applications will
use hard-coded values for frequently-used ordering semantics
rather than looking up the semantics at the location specified by
DAV:orderingtype.
11 Internationalization Considerations If the server maintains the DAV:references property in response to
references created in other administrative domains, it is exposed to
hostile attempts to make it devote resources to adding references to the
list.
This specification follows the practices of [WebDAV] in encoding 11.5 DAV:references and Malicious Deletion of Resources
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, Servers that support the DAV:references property should insure that
character set encoding, and the language tagging functionality of clients cannot create editable properties with the name DAV:references.
the XML specification. This constraint ensures that the human- An editable DAV:references property would constitute a security risk on
readable content of this specification complies with [Alvestrand]. servers that enforce referential integrity by deleting references when
their target is deleted. These servers could be tricked into deleting a
resource by listing it in the DAV:references property of some target
resource.
As in [WebDAV}, names in this specification fall into three 11.6 Malicious Modifications of Ordering
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 Particularly in large collections, moving a collection member to a
status codes, including with each status code a short, English different position in the ordering can make it very difficult for users
description of the code (e.g., 423 Locked). Internationalized to find.
applications will ignore this message, and display an appropriate
message in the user's language and character set. 11.7 Denial of Service and DAV:orderingtype
There may be some risk of denial of service at sites that are advertised
in the DAV:orderingtype property of collections. However, it is
anticipated that widely-deployed applications will use hard-coded values
for frequently-used ordering semantics rather than looking up the
semantics at the location specified by DAV:orderingtype.
12 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 For rationales for these decisions and advice for application
implementors, see [WebDAV]. implementors, see [WebDAV].
12 IANA Considerations 13 IANA Considerations
TBD TBD
13 Copyright 14 Copyright
14 Intellectual Property 15 Intellectual Property
15 Acknowledgements 16 Acknowledgements
This draft has benefited from thoughtful discussion by This draft has benefited from thoughtful discussion by Steve Carter,
Steve Carter, Ellis Cohen, Spencer Dawkins, Rajiv Dulepet, Geoffrey Clemm, Ellis Cohen, Bruce Cragun, Spencer Dawkins, Rajiv
Chuck Fay, Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, Dulepet, David Durand, Chuck Fay, Roy Fielding, Yaron Goland, Fred Hitt,
Marcus Jager, Rohit Khare, Daniel LaLiberte, Steve Martin, Alex Hopmann, Marcus Jager, Chris Kaler, Rohit Khare, Daniel LaLiberte,
Surendra Koduru Reddy, Sam Ruby, Bradley Sergeant, Nick Shelness, Steve Martin, Surendra Koduru Reddy, Sam Ruby, Bradley Sergeant, Nick
John Stracke, John Tigue, John Turner, and others. Shelness, John Stracke, John Tigue, John Turner, and others.
16 References 17 References
[WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. [WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D.
Faizi, S. R. Carter, D. Jensen, "Extensions for Distributed Jensen, "HTTP Extensions for Distributed Authoring - WebDAV." Draft-
Authoring on the World Wide Web - WebDAV." Draft-ietf-webdav- ietf-webdav-protocol-09. Internet Draft, work in progress. Microsoft,
protocol-08. Internet Draft, work in progress. Microsoft, U.C. Irvine, Netscape, Novell. November, 1998.
U.C. Irvine, Netscape, Novell. April, 1998.
[DASL] Saveen Reddy, D. Jensen, Surendra Reddy, [DASL] Saveen Reddy, D. Jensen, Surendra Reddy, R. Henderson, J. Davis,
R. Henderson, J. Davis, A. Babich, "DAV Searching & Locating." A. Babich, "DAV Searching & Locating." Draft-reddy-dasl-protocol-03.
Draft-reddy-dasl-protocol-02. Internet Draft, work in progress. Internet Draft, work in progress. Microsoft, Novell, Oracle, Netscape,
Microsoft, Novell, Oracle, Netscape, Xerox, Filenet. June, 1998. Xerox, Filenet. November, 1998.
[WebDAVReq] J. Slein, J. Davis, "Requirements for Advanced [WebDAVReq] J. Slein, J. Davis, "Requirements for Advanced Collection
Collection Functionality in WebDAV." Draft-ietf-webdav-collection- Functionality in WebDAV." Draft-ietf-webdav-collection-reqts-02.
reqts-02. Internet Draft, work in progress. Xerox, 1998. Internet Draft, work in progress. Xerox, 1998.
[HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, [HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." "Hypertext Transfer Protocol -- HTTP/1.1." RFC 2068. UC Irvine, DEC,
RFC 2068. UC Irvine, DEC, MIT/LCS. January, 1997. MIT/LCS. January, 1997.
[XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup [XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup
Language (XML)." World Wide Web Consortium Recommendation Language (XML)." World Wide Web Consortium Recommendation REC-xml-
REC-xml-19980210. http://www.w3.org/TR/1998/REC-xml-19980210. 19980210. http://www.w3.org/TR/1998/REC-xml-19980210.
17 Authors' Addresses 18 Authors' Addresses
J. Slein J. Slein
Xerox Corporation Xerox Corporation
800 Phillips Road, 105-50C 800 Phillips Road, 105-50C
Webster, NY 14580 Webster, NY 14580
Email: slein@wrc.xerox.com Email: jslein@crt.xerox.com
J. Davis J. Davis
Xerox Corporation Xerox Corporation
3333 Coyote Hill Road 3333 Coyote Hill Road
Palo Alto, CA 94304 Palo Alto, CA 94304
Email: jdavis@parc.xerox.com Email: jdavis@parc.xerox.com
A. Babich A. Babich
FileNet Corporation FileNet Corporation
3565 Harbor Boulevard 3565 Harbor Boulevard
Costa Mesa, CA 92626-1420 Costa Mesa, CA 92626-1420
Email: ababich@filenet.com Email: ababich@filenet.com
E.J. Whitehead Jr. E.J. Whitehead Jr.
Dept. of Information and Computer Science Dept. of Information and Computer Science
University of California, Irvine University of California, Irvine
Irvine, CA 92697-3425 Irvine, CA 92697-3425
Email: ejw@ics.uci.edu Email: ejw@ics.uci.edu
skipping to change at line 1346 skipping to change at line 1784
3565 Harbor Boulevard 3565 Harbor Boulevard
Costa Mesa, CA 92626-1420 Costa Mesa, CA 92626-1420
Email: ababich@filenet.com Email: ababich@filenet.com
E.J. Whitehead Jr. E.J. Whitehead Jr.
Dept. of Information and Computer Science Dept. of Information and Computer Science
University of California, Irvine University of California, Irvine
Irvine, CA 92697-3425 Irvine, CA 92697-3425
Email: ejw@ics.uci.edu Email: ejw@ics.uci.edu
Expires January 31, 1999 19 Appendices
19.1 Appendix 1 - Extensions to the WebDAV Document Type Definition
<!--============= XML Elements from Section 7 =======================-->
<!ELEMENT reference EMPTY >
<!ELEMENT direct EMPTY >
<!ELEMENT redirect EMPTY >
<!ELEMENT weak EMPTY >
<!ELEMENT unordered EMPTY >
<!ELEMENT custom EMPTY >
<!ELEMENT order (member+) >
<!ELEMENT ordermember (href, position) >
<!ELEMENT position (first | last | before | after)>
<!ELEMENT first EMPTY >
<!ELEMENT last EMPTY >
<!ELEMENT before href >
<!ELEMENT after href >
<!--============= Property Elements from Section 6 ==================-->
<!ELEMENT reftarget href>
<!ELEMENT refintegrity (weak)>
<!ELEMENT reftype (direct | redirect)>
<!ELEMENT references (href*)>
<!ELEMENT orderingtype (arbitrary | custom | href) >
<!--======== Changes to the DAV:multistatus Element from Section 8 ==-->
<!ELEMENT response (href, ((href*, status, reftype?, reftarget?) |
(propstat+)), responsedescription?) >
Expires May 10, 1999
 End of changes. 

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