WDIFF

draft-ietf-webdav-protocol-04.txt --> draft-ietf-webdav-protocol-05.txt

INTERNET DRAFT E.J. Whitehead, Jr., U.C. UC Irvine
<draft-ietf-webdav-protocol-04>
<draft-ietf-webdav-protocol-05> A. Faizi, Netscape
S. R
S.R. Carter, Novell
D. Jensen, Novell
Expires April 20, April, 1998 October 12, November 19, 1997

Extensions for Distributed Authoring and Versioning on the World Wide Web -- WEBDAV

Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

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

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

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

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

Abstract

This Document document specifies a set of methods methods, headers, and content-types
ancillary to HTTP/1.1 for the management of resource properties,
simple name space
creation and management of resource collections, namespace
manipulation, simple resource locking (collision avoidance) avoidance), and efficient
transmission of resource version control.

Table changes.

Changes

1.1. Changes since draft-ietf-webdav-protocol-04.txt

[Editor's note: This section will not appear in the final form of Contents
Abstract
1 Terminology
2 Data Model and Methods
this document. Its purpose is to provide a concise list of changes
from the previous revision of the draft for DAV Properties
2.1 Introduction
2.1.1 The DAV Property
2.1.2 Existing Metadata Proposals
2.1.3 Properties and HTTP Headers
2.2 A Property Model use by reviewers.]

Added this change section.
INTERNET-DRAFT WebDAV November 19, 1997

Removed scoping for HTTP Resources
2.2.1 Overview
2.2.2 Property Namespace
2.3 Schemas
2.3.1 PropSchema XML Element
2.3.2 DTD XML Element
2.3.3 DefinedProps XML Element

2.3.4 PropEntries XML Element
2.3.5 Live XML Element
2.4 DAV Schema
2.4.1 namespaces so the namespace for
every element is explicitly stated.

Changed the syntax from <?XML:Namespace.../> to <?namespace...?>.

Removed propfindresult, this was left over from the old search
format.

Changed all the DAV Property
2.4.2 Level XML Element
2.4.3 Prop XML element
2.4.4 PropLoc XML Attribute
2.4.5 Example
2.5 Property Identifiers
2.5.1 Problem Definition
2.6 Link XML Element
2.6.1 Problem Description
2.6.2 Solution Requirements
2.6.3 Link XML Element
2.6.4 Src XML Element
2.6.5 Dst XML Element
2.6.6 Example
2.7 Multi-Status Response
2.7.1 Problem Definition
2.7.2 Solution Requirements
2.7.3 Multi-Status Response
2.8 Properties names to lower case.

Changed the property format to use Name and Methods
2.8.1 DELETE
2.8.2 GET
2.8.3 PROPPATCH
2.8.4 PUT
2.8.5 PROPFIND
3 A Proposal for Collections of Web Resources Namespace rather than
name and Name Space
Operations
3.1 Observations schema.

Removed proploc attribute and removed section on GETting, DELETEing,
and PUTing properties since we do not provide a mechanism for
getting a URI for properties. Also removed the requirement that
properties be URI addressable.

Removed quoted string choice from owner header, it is just XML.

Made all the HTTP Object Model
3.1.1 Collection Resources
3.1.2 Creation and Retrieval of Collection
Resources
3.1.3 Source Resources and Output Resources
3.2 MKCOL Method
3.2.1 Problem Description
3.2.2 Solution Requirements
3.2.3 Request
3.2.4 Response
3.2.5 Example
3.3 Standard DAV Properties
3.3.1 IsCollection Property
3.3.2 DisplayName Property
3.3.3 CreationDate Property
3.3.4 GETentity Property
3.3.5 INDEXentity Property
3.3.6 Content-Type XML Element
3.3.7 Content-Length XML Element
3.3.8 Content-Language XML Element
3.3.9 Last-Modified XML Element
3.3.10 Etag XML Element
3.4 INDEX Method
3.4.1 Problem Description
3.4.2 Solution Requirements
3.4.3 The Request
3.4.4 The Response
3.4.5 ResInfo XML Element
3.4.6 Members XML Element
3.4.7 Href XML Element
3.4.8 Example
3.5 Behavior of RFC 2068 Methods on Collections
3.5.1 GET, HEAD for Collections
3.5.2 POST for Collections
3.5.3 PUT for Collections
3.5.4 DELETE for Collections

3.5.5 DELETE Method for Non-Collection
Resources
3.6 COPY Method
3.6.1 Problem Description
3.6.2 Solution Requirements
3.6.3 The Request
3.6.4 The Response
3.6.5 Examples
3.7 MOVE Method
3.7.1 Problem Description
3.7.2 Solution Requirements
3.7.3 The Request
3.7.4 The Response
3.7.5 Examples
3.8 ADDREF Method
3.8.1 Problem Definition
3.8.2 Solution Requirements
3.8.3 The Request
3.8.4 Example
3.9 DELREF Method
3.9.1 Problem Definition
3.9.2 Solution Requirements
3.9.3 The Request
3.9.4 Example
3.10 PATCH Method
3.10.1 Problem Definition
3.10.2 Solution Requirements
3.10.3 The Request
3.10.4 text/xml elements for PATCH
3.10.5 The Response
3.10.6 Examples
3.11 Headers
3.11.1 Destination Header
3.11.2 Enforce-Live-Properties Header
3.11.3 Overwrite Header
3.11.4 Destroy Header
3.11.5 Collection-Member Header
3.12 Links
3.12.1 Source Link Property Type
4 State Tokens
4.1 Overview
4.1.1 Problem Description
4.1.2 Solution Requirements
4.2 State Token Syntax
4.3 State Token Conditional Headers
4.3.1 If-State-Match
4.3.2 If-None-State-Match
4.4 State Token Header
4.5 E-Tag
5 Locking
5.1 Locking: Introduction
5.1.1 Exclusive Vs. Shared Locks
5.1.2 Required Support
5.2 LOCK Method
5.2.1 Operation
5.2.2 The Effect of Locks on Properties and
Containers
5.2.3 Locking Replicated Resources
5.2.4 Locking Multiple Resources
5.2.5 Interaction with other Methods
5.2.6 Lock Compatibility Table
5.2.7 Status Codes
5.2.8 Lock-Info Request Header
5.2.9 Owner Request Header
5.2.10 Time-Out Header
5.2.11 Lock Response

5.2.12 Example - Simple Lock Request
5.2.13 Example - Multi-Resource Lock Request
5.3 Write Lock
5.3.1 Methods Restricted by Write Locks
5.3.2 Write Locks and Properties
5.3.3 Write Locks and Null Resources
5.3.4 Write Locks and Collections
5.3.5 Write Locks and COPY/MOVE
5.3.6 Re-issuing Write Locks
5.3.7 Write Locks and The State-Token Header
5.4 Lock Tokens
5.4.1 Problem Description
5.4.2 Lock Token Introduction
5.4.3 Generic Lock Tokens
5.4.4 OpaqueLockToken Lock Token
5.5 UNLOCK Method
5.5.1 Problem Definition
5.5.2 Example
5.6 Discovery Mechanisms
5.6.1 Lock Capability Discovery
5.6.2 Active Lock Discovery
6 Version Control
7 Internationalization Support
8 Security Considerations
9 Copyright
10 Acknowledgements
11 References
12 Authors' Addresses

1 Terminology

Collection - A resource that contains member resources.

Member Resource - a resource referred to by a collection. There
are two types of member resources: external and internal.

Internal Member Resource - the name given to a member resource of
a collection whose URI is relative to the URI of the collection.

External Member Resource - a member resource with an absolute URI
that is not relative to its parent’s URI.

Properties - A set of name/value pairs that contain descriptive
information about a resource.

Live Properties - Properties whose semantics and syntax are
enforced by the server. For example, a live "read-only" property
that is enforced by the server would disallow PUTs to the
associated resource.

Dead properties - Properties whose semantics and syntax are not
enforced by the server. A dead "read-only" property would not be
enforced by the server and thus would not be used by the server
as a reason to disallow a PUT on the associated resource.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119 [Bradner, 1997].

2 Data Model and Methods for DAV Properties

2.1 Introduction

2.1.1 The DAV Property

Properties are pieces of data that describe the state of a
resource. Properties are data about data. The term property is
used within this specification to disambiguate the concept from
the overloaded terms "metadata" and "attribute".

Properties are used within distributed authoring environments to
provide for efficient discovery and management of resources. For
example, a 'subject' property might allow for the indexing of all
resources by their subject, and an 'author' property might allow
for the discovery of what authors have written which documents.

2.1.2 Existing Metadata Proposals

Properties have a long played an essential role in the
maintenance of large document repositories, and many current
proposals contain some notion of a property. These include PICS
[Miller et al., 1996], PICS-NG, the Rel/Rev draft [Maloney,
1996], Web Collections, XML [Bray, Sperberg-McQueen, 1997],
several proposals on representing relationships within HTML,
digital signature manifests (DCMF), and a position paper on Web
metadata architecture [Berners-Lee, 1997].

Some proposals come from a digital library perspective. These
include the Dublin Core [Weibel et al., 1995] metadata set and
the Warwick Framework [Lagoze, 1996], a container architecture
for different metadata schemas. The literature includes many
examples of metadata, including MARC [MARC, 1994], a
bibliographic metadata format, RFC 1807 [Lasher, Cohen, 1995], a
technical report bibliographic format employed by the Dienst
system, and the proceedings from the first IEEE Metadata
conference describe many community-specific metadata sets.

Participants of the 1996 Metadata II Workshop in Warwick, UK
[Lagoze, 1996], noted that, "new metadata sets will develop as
the networked infrastructure matures" and "different communities
will propose, design, and be responsible for different types of
metadata." These observations can be corroborated by noting that
many community-specific sets of metadata already exist, and there
is significant motivation for the development of new forms of
metadata as many communities increasingly make their data
available in digital form, requiring a metadata format to assist
data location and cataloging.

2.1.3 Properties and HTTP Headers

Properties already exist, in a limited sense, within HTTP through
the use of message headers. However, in distributed authoring
environments a relatively large number of properties are needed
to describe the state of a resource, and setting/returning them
all through HTTP headers is inefficient. Thus a mechanism is
needed which allows a principal to identify a set of properties
in which the principal is interested and to then set or retrieve
just those properties.

2.2 A Property Model for HTTP Resources

2.2.1 Overview

The DAV property model is based on name/value doubles. The name
of a property identifies the property's syntax and semantics, and
provides an address with which to refer to a property. The name
and value of a property is expressed as a well-formed XML
element, where the name of the property is the name of the XML
element, and the value of the property MUST be either blank, or a
well-formed XML element value.

2.2.2 Property Namespace

2.2.2.1 Problem Definition

The requirement is to be able to associate a value with a
property name on a resource. It must be possible to associate a
URL with the property name.

2.2.2.2 Solution Requirement

Ideally a property namespace should work well with extant
property implementations as well as database systems. The DAV
property namespace has been specified with the following two
facts in mind:
· Namespaces associated with flat file systems are ubiquitous.
· The majority of databases use a fixed schema mechanism.
The last point makes efficient implementation of hierarchical
properties difficult. Specifically, each property has a random
set of children; the best a relational database can do is provide
a table with name and value, where the value is a series of
indexes into other tables and each index represents a specific
value. However most RDBS do not provide for table pointers, only
index values. Such a system would have to be jury-rigged to
handle table pointers. In addition, indexing systems are
optimized for a small set of relatively large tables;
hierarchical property systems tend toward many properties, each
with different numbers and types of children, thus potentially
requiring a table for each child.

It would seem best to implement a flat property namespace,
inducing a natural isomorphism between DAV and most native file
systems. Adopting such a model will not restrict RDBS from taking
full advantage of their search facilities.

However, it seems that future trends might be toward hierarchical
properties. Therefore, DAV requirements [Slein et al.] stipulate
that the design of the flat property system MUST be such that it
will be possible to add true hierarchical properties later
without breaking downlevel clients. Specifically, a flat client
MUST be able to speak to a hierarchical server and a hierarchical
client MUST be able to speak to a flat server. Worst case either
way MUST be that the request fails.

2.2.2.3 Property Names

A property name identifies both the syntax and semantics of the
property's value. It is critical that property names do not
collide, e.g., two principals defining the same property name
with two different meanings.

The URI framework provides a mechanism to prevent namespace

collision and for varying degrees of administrative control.
Rather than reinvent these desirable features, DAV properties
make use of them by requiring that all DAV property names MUST be
URIs. Since a property is also an XML element, the name of the
XML element is a URI.

The property namespace is flat, that is, it is not possible to
string together a series of property names in order to refer to a
hierarchy of properties. Thus it is possible to refer to a
property B but not a property A/B, where A is also a property
defined on the resource.

Finally, it is not possible to define the same property twice as
this would cause a collision in the resource's property
namespace.

2.3 Schemas

A schema is a group of property names and XML elements.

Schema discovery is used to determine if a system supports a
group of properties or XML elements. A property does not
necessarily contain sufficient information to identify any
schema(s) to which it may belong.

As with property names, schemas MUST use URIs as their names.

A resource declares its support for a schema by defining a
property whose name is the same as the schema's. The property
SHOULD contain the PropSchema XML element.

2.3.1 PropSchema XML Element

Name: http://www.ietf.org/standards/dav/PropSchema
Purpose: To provide information about properties
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Values= [DTD] [DefinedProps]
Description:This property contains the definition of the schema.
This definition consists of two parts. A DTD element that
contains a DTD that declares all XML elements and DefinedProps
that defines any properties associated with the schema. As with
all XML it is possible to add extra XML elements. Therefore
schemas may define extra XML elements which are to be included
with their values.

2.3.2 DTD XML Element

Name: http://www.ietf.org/standards/dav/DTD
Purpose: To contain the DTD for XML elements associated with the
schema.
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Values: XML Declaration statements

2.3.3 DefinedProps XML Element

Name: http://www.ietf.org/standards/dav/DefinedProps
Purpose: To contain a list of properties defined by the schema.
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Values= 1*PropEntries

2.3.4 PropEntries XML Element

Name: http://www.ietf.org/standards/dav/PropEntries
Purpose: To contain the name of a defined property, the DTD of
its value, and its live/dead status.
Schema: http://www.ietf.org/standards/dav/
Parent: DefinedProps
Values= Prop [DTD] [Live]
Description:Prop contains the name of the property. The DTD
contains the DTD of the property's value. Live, if defined,
indicates that the property has semantics and syntax that are
enforced by the server.

2.3.5 Live XML Element

Name: http://www.ietf.org/standards/dav/Live
Purpose: If present this indicates the server MUST enforce the
syntax and semantics of the property.
Schema: http://www.ietf.org/standards/dav/
Parent: PropEntries

2.4 DAV Schema

The DAV Schema is specified as
http://www.ietf.org/standards/dav/. This schema is used to
indicate support for
· properties that may be defined on a resource and
· XML elements that may be returned in responses.

2.4.1 DAV Property

Name: http://www.ietf.org/standards/dav
Purpose: Defines support for the DAV schema and protocol.
Schema: http://www.ietf.org/standards/dav/
Values= PropSchema Level
Description:This property indicates that the resource supports
the DAV schema and protocol to the level indicated. THE VALUE IN
PROPSCHEMA IS TBD, WE NEED TO PROVIDE IT IN AN APPENDIX.

2.4.2 Level XML Element

Name: http://www.ietf.org/standards/dav/level
Purpose: To indicate the level of DAV compliance the resource
meets.
Schema: http://www.ietf.org/standards/dav/
Parent: DAV
Values= "1" | "2" | "3"
Description:A value of 1 for level indicates that the resource
supports the property and namespace sections of the DAV
specification. Level 2 indicates that the resource supports level
1 and the lock section of the specification, with a minimum
locking capability of the write lock. Level 3 indicates support
for levels 1 and 2 as well as support for the versioning section
of the DAV specification.

2.4.3 Prop XML element

Name: http://www.ietf.org/standards/dav/prop

Purpose: Contains properties related to a resource.
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Values: XML Elements
Description:The Prop XML element is a generic container for
properties defined on resources. All elements inside Prop MUST
define properties related to the resource. No other elements may
be used inside of a Prop element.

2.4.4 PropLoc XML Attribute

Name: http://www.ietf.org/standards/dav/PropLoc
Purpose: To specify the location of the associated property.
Schema: http://www.ietf.org/standards/dav/
Values= URL
Description:This attribute is used with elements inside of Props
contained in responses to specify the URL of the property on the
associated resource. The PropLoc attribute MUST NOT be used in
requests.

2.4.5 Example

<?XML:Namespace href="http://www.ietf.org/standards/dav/"
AS="D"/>
<?XML:Namespace href="AIIM:Dublin:" AS="A"/>
<D:Prop>
<A:Author
D:PropLoc="http://www.foo.com/resource/props/Author">
Larry Masinter
</A:Author>
</D:Prop>

The previous specifies that the property author exists on some
unspecified resource and that the property can be directly
referenced at http://www.foo.com/resource/props/Author. The
resource upon which the property is defined must be determined
from context.

2.5 Property Identifiers

2.5.1 Problem Definition

DAV properties are resources and thus may have a URI where the
value of an instance of the property may be retrieved. This URI
is separate from the URI name of the property, which identifies
the syntax and semantics of the property, but which does not give
information on how to access the value of an instance of the
property.

A server is free to assign whatever URI it chooses to identify an
instance of a property defined on a resource. In fact, a server
is free not to reveal the URI of an instance of a particular
resource and instead require that the client access the property
through PROPFIND and PROPPATCH. However, many servers will want
to allow clients to directly manipulate properties. On these
servers, a client can discover the URI of an instance of a
property by performing a PROPFIND and examining the PropLoc
attribute, if returned, of each property.

2.6 Link XML Element

2.6.1 Problem Description

A mechanism is needed to associate resources with other
resources. These associations, known as links, consist of three
values, a type describing the nature of the association, the
source of the link, and the destination of the link. In the case
of annotation, neither the source nor the destination of a link
need be the resource upon which the link is recorded.

2.6.2 Solution Requirements

The association mechanism MUST make use error codes use the same format.

Changed the name of the DAV property
mechanism create element in order PROPPATCH to make the existence of set, the associations
searchable.

2.6.3 Link XML Element

Name: http://www.ietf.org/standards/dav/link
Purpose: To identify a property as a link and new
name seems to contain cause less confusion.

Moved all headers in the
source and destination of that link.
Schema: http://www.ietf.org/standards/dav/
Values= 1*Src 1*Dst
Description:Link is used draft to provide the sources and destinations
of a link. The type single section.

Deleted the state token section of the property containing draft and moved the Link XML
element provides state
token headers to the type header section of the link. Link is a multi-valued
element, so multiple Links may be used together to indicate
multiple links with the same type.

2.6.4 Src XML Element

Name: http://www.ietf.org/standards/dav/src
Purpose: To indicate draft. Removed the source of a link.
Schema: http://www.ietf.org/standards/dav/
Parent: http://www.ietf.org/standards/dav/link
Values= URI

2.6.5 Dst XML Element

Name: http://www.ietf.org/standards/dav/Dst
Purpose: To indicate state
token header.

Changed the destination of write lock section to state that a link
Schema: http://www.ietf.org/standards/dav/
Parent: http://www.ietf.org/standards/dav/link
Values= URI

2.6.6 Example

<?XML:Namespace
href = "http://www.ietf.org/standards/dav/" AS = "D"/>
<?XML:Namespace
href = "http://www.foocorp.com/Project/" AS = "F"/>
<D:Prop>
<Source>
<Link>
<F:ProjFiles>Source</F:ProjFiles>
<src>http://foo.bar/program</src>
<dst>http://foo.bar/src/main.c</dst>
</Link>
<Link>
<F:ProjFiles>Library</F:ProjFiles>

<src>http://foo.bar/program</src>
<dst>http://foo.bar/src/main.lib</dst>
</Link>
<Link>
<F:ProjFiles>Makefile</F:ProjFiles>
<src>http://foo.bar/program</src>
<dst>http://foo.bar/src/makefile</dst>
<Link>
</Source>
</D:Prop>

In this example the resource http://foo.bar/program has Lock-Token request
header, not a source
property defined which contains three links. Each link contains
three elements, two of which, src and dst, are part of the DAV
schema defined in this document, and one which state-token request header, is defined by the
schema http://www.foocorp.com/project/ (Source, Library, and
Makefile). A client which only implements the elements in the DAV
spec will not understand the foocorp elements and will ignore
them, thus seeing to be submitted on
request for write locked resources.

Created a "generic" XML element section for XML elements that get
repeatedly re-used throughout the expected source spec. I moved LINK XML element to
this section.

Made multistatus and destination links. An
enhanced client may know about Schema discovery their own level one sections.

Collected all the foocorp elements and be able properties together.

Removed all references to present the user with additional information about the links.

2.7 Multi-Status Response

2.7.1 Problem Definition

Some methods effect more than one resource. The effect possibility of properties have their
own URIs. This includes removing the
method property identifier section.

Separated the section on each of web collections and namespaces into two
separate sections.

Collected all the scoped resources may be different, as such
a return format that can specify new response codes together into their own
section.
INTERNET-DRAFT WebDAV November 19, 1997

Changed the effect XML multiresponse element name to multistatus.

Added a stand alone section on levels of the DAV compliance. I also went
method on each
resource is needed.

2.7.2 Solution Requirements

The solution must:
- communicate by method, property by property, to specify compliance
requirements.

Added an introduction.

Changed all the status code "True" and reason
- give "False" to "T" and "F".

Altered the URI first two paragraphs of the resource on which Property Names section to
make the method was invoked relationship between a property's name and its schema a
little clearer. I also added some text in the same section defining
a property name as a namespace and element.

Added a second paragraph to property model for http resources - be consistent
overview. This paragraph clarifies why XML was chosen.

Added a 409 Conflict error to move to cover attempts to move a
collection with other return body formats

2.7.3 Multi-Status Response

The default multi-status response body is an text/xml HTTP entity
that contains members.

Changed the collection requirement to read the collections SHOULD
end with "/". Also added a single XML element called multiresponse, which
contains SHOULD about returning a set of XML elements called response, one for each 200,
300, 400, and 500 series status code generated during location header
if the method
invocation. 100 series status codes MUST NOT be recorded in client submits a
response XML element.

2.7.3.1 MultiResponse

Name: http://www.ietf.org/standards/dav/multiresponse
Purpose: Contains multiple response messages.
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Value: 1*Response [ResponseDescription]
Description:The ResponseDescription at URL for a collection without a trailing "/".

Moved the top level owner header into the body due to size concerns.

Replaced the iscollection xml element with resourcetype.

Moved the DAV property to the DAV header that is used returned with
OPTIONS.

Folded the tree draft into this draft. Changed the DELETE, COPY,
and MOVE sections to
provide include their effect on collections as taken
from the tree draft. Created a Depth header section and put in the
general message describing rules that were in the over arching nature of introduction to the response. If this value is available an application MAY use
it instead of presenting tree draft. I
also added the individual 102 response descriptions
contain within and response-status header.

Removed the responses.

2.7.3.2 Response

Name: http://www.ietf.org/standards/dav/response
Purpose: Holds versioning section.

Put all the methods into a single response
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Value: (Prop | HREF) Status [ResponseDescription]
Description: Prop MUST contain one or more empty XML elements
representing section.

Replaced the name of properties. Multiple properties may be
included if PROPFIND request body with a propfind header. Now the same
response applies to them all. If HREF can be cached just using vary.

Nuked resinfo for INDEX and combined it with multistatus which is
now used then for both INDEX and PROPFIND. Stripped down INDEX as
agreed.

Removed the response refers problem definition and proposed solution sections. We
can always cut and paste them together from the older version if we
feel we need them but this draft is supposed to be a dry run for
INTERNET-DRAFT WebDAV November 19, 1997

last call and last call documents do not have problem with
definition/proposed solution sections.

Killed the referenced
resource, not a property.

2.7.3.3 Status

Name: http://www.ietf.org/standards/dav/status
Purpose: Holds a single HTTP status-line
Schema: http://www.ietf.org/standards/dav/
Parent: Response
Value: status-line ;status-line defined in [Fielding et al.,
1997]

2.7.3.4 ResponseDescription

Name:
http://www.ietf.org/standards/dav/ResponseDescription
Purpose: Contains a message that can section on schema discovery, it is controversial and we
aren't going to be displayed able to require it. We should specify it in a
different spec.

Added a section on notational conventions used within the user
explaining document.

Moved the nature terminology section to the end of the response.
Schema: http://www.ietf.org/standards/dav/
Parent: Multiresponse and/or Response
Value: Any
Description: This XML element provides information suitable document to
be presented provide
better flow from the high-level introduction to a user.

2.8 Properties and Methods

2.8.1 DELETE

As properties are resources, the deletion specific
introduction sections.

Increased the numeric value of a property causes the same result as 4xx status codes introduced in
this specification to avoid conflicts with the deletion new revision of any resource. It is worth
pointing out that the deletion
HTTP/1.1 specification, which introduces two new 4xx status codes.

Wrote internationalization concerns section.

Added XML version number to all examples.
INTERNET-DRAFT WebDAV November 19, 1997

Contents

STATUS OF THIS MEMO...................................................1
ABSTRACT..............................................................1
CHANGES...............................................................1

1.1. Changes since draft-ietf-webdav-protocol-04.txt..................1
CONTENTS..............................................................5
2. INTRODUCTION.......................................................8
3. DATA MODEL FOR RESOURCE PROPERTIES.................................9
3.1. The Resource Property Model......................................9
3.2. Existing Metadata Proposals.....................................10
3.3. Properties and HTTP Headers.....................................10
3.4. Property Values.................................................10

3.5. Property Names..................................................11
4. COLLECTIONS OF WEB RESOURCES......................................11
4.1. Collection Resources............................................11
4.2. Creation and Retrieval of a property effects both direct
manipulation, that is Collection Resources..................12
4.3. HTTP URL Namespace Model........................................13
4.4. Source Resources and Output Resources...........................13
5. LOCKING...........................................................14

5.1. Exclusive Vs. Shared Locks......................................14
5.2. Required Support................................................15
5.3. Lock Tokens.....................................................16
5.4. opaquelocktoken Lock Token URI Scheme...........................16
5.5. Lock Capability Discovery.......................................16
5.6. Active Lock Discovery...........................................17
6. WRITE LOCK........................................................17
6.1. Methods Restricted by the property's URL, as well as indirect
discovery Write Locks...............................17

6.2. Write Locks and manipulation, that is PROPPATCH Properties......................................17
6.3. Write Locks and PROPFIND.

2.8.2 GET

A GET with a Request-URI that identifies a property returns Null Resources..................................17
6.4. Write Locks and Collections.....................................18
6.5. Write Locks and COPY/MOVE.......................................18
6.6. Re-issuing Write Locks..........................................18
6.7. Write Locks and The Lock-Token Request Header...................18
7. NOTATIONAL CONVENTIONS............................................19

8. HTTP METHODS FOR DISTRIBUTED AUTHORING............................19
8.1. PROPFIND........................................................19
8.2. PROPPATCH.......................................................23
8.3. MKCOL Method....................................................25
8.4. INDEX Method....................................................26
8.5. DELREF Method...................................................28
8.6. ADDREF Method...................................................28
8.7. GET, HEAD for Collections.......................................29

8.8. POST for Collections............................................29
8.9. DELETE..........................................................29
8.10. PUT............................................................31
INTERNET-DRAFT WebDAV November 19, 1997

8.11. COPY Method....................................................31
8.12. MOVE Method....................................................35
8.13. LOCK Method....................................................38

8.14. UNLOCK Method..................................................42
8.15. PATCH Method...................................................43
9. DAV HEADERS.......................................................47
9.1. Collection-Member Header........................................47
9.2. DAV Header......................................................47
9.3. Depth Header....................................................47
9.4. Destination Header..............................................48
9.5. Destroy Header..................................................48

9.6. Enforce-Live-Properties Header..................................49
9.7. If-None-State-Match.............................................49
9.8. If-State-Match..................................................50
9.9. Lock-Info Request Header........................................50
9.10. Lock-Token Request Header......................................51
9.11. Lock-Token Response Header.....................................51
9.12. Overwrite Header...............................................52

9.13. Propfind Request Header........................................52
9.14. Status-URI Response Header.....................................52
9.15. Timeout Header.................................................52
10. RESPONSE CODE EXTENSIONS TO RFC 2068.............................54
10.1. 102 Processing.................................................54
10.2. 207 Multi-Status...............................................54
10.3. 418 Unprocessable Entity.......................................54
10.4. 419 Insufficient Space on Resource.............................54

10.5. 420 Method Failure.............................................54
11. MULTI-STATUS RESPONSE............................................54
11.1. multistatus XML Element........................................55
11.2. response XML Element...........................................55
11.3. status XML Element.............................................55
11.4. responsedescription XML Element................................55
12. GENERIC DAV XML ELEMENTS.........................................55

12.1. href XML Element...............................................56
12.2. link XML Element...............................................56
12.3. prop XML element...............................................57
13. DAV PROPERTIES...................................................57
13.1. creationdate Property..........................................57
13.2. displayname Property...........................................57
13.3. get-content-language Property..................................58
13.4. get-content-length Property....................................58

13.5. get-content-type Property......................................58
13.6. get-etag Property..............................................58
13.7. get-last-modified Property.....................................59
13.8. index-content-language Property................................59
INTERNET-DRAFT WebDAV November 19, 1997

13.9. index-content-length Property..................................59
13.10. index-content-type Property...................................59
13.11. index-etag Property...........................................59

13.12. index-last-modified Property..................................60
13.13. lockdiscovery Property........................................60
13.14. resourcetype Property.........................................62
13.15. Source Link Property Type.....................................62
13.16. supportedlock Property........................................63
14. DAV COMPLIANCE LEVELS............................................64
14.1. Level 1........................................................64
14.2. Level 2........................................................64

15. INTERNATIONALIZATION SUPPORT.....................................65
16. SECURITY CONSIDERATIONS..........................................66
17. TERMINOLOGY......................................................66
18. COPYRIGHT........................................................66
19. ACKNOWLEDGEMENTS.................................................67
20. REFERENCES.......................................................69
21. AUTHORS' ADDRESSES...............................................71
INTERNET-DRAFT WebDAV November 19, 1997

2. Introduction

This document describes an extension to the
name and value of HTTP/1.1 protocol that property. Accept types may be used
allows clients to
specify the format of the return value, but all DAV compliant
servers MUST at minimum support perform remote web content authoring operations.
This extension provides a return type coherent set of text/xml. If
text/xml is used as the response format then it MUST return the
name methods, headers, request
entity body formats, and value of the property using the Prop XML element.

2.8.2.1 Example

The following example assumes response entity body formats that the property's URL, originally
generated by the server, was discovered by examining the proploc
XML attribute returned on a result from a FINDPROP.

GET /bar.html;prop=z39.50_authors HTTP/1.1
Host: foo.com

HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: xxxx
E-tag: "1234"
Last-Modified: xxxx

<?XML:Namespace
href = "http://www.ietf.org/standards/dav/" AS = "D"/>
<?XML:Namespace
href = "http://www.w3.com/standards/z39.50/"AS = "Z"/>
<D:prop>
<Z:Authors>
<Z:Author>Jane Doe</Z:Author>
<Z:Author>Joe Doe</Z:Author>
<Z:Author>Lots o'Doe</Z:Author>
</Z:Authors>
</D:prop>

2.8.3 PROPPATCH provide
operations for:

Properties: The PROPPATCH method processes instructions specified in the
request body ability to create and/or remove properties defined on the
resource identified by Request-URI.

All DAV compliant servers MUST process instructions which are
specified using the PropertyUpdate, Create, create, remove, and Remove XML
elements of query information
about Web pages, such as its author, creation date, etc. Also, the DAV schema.
ability to link pages of any media type to related pages.

Collections: The request message body MUST
contain at least one PropertyUpdate XML element. Instruction
processing MUST occur in the order instructions are received
(i.e., from top ability to bottom), create sets of related documents, and MUST be performed atomically.

2.8.3.1 PropertyUpdate XML element

Name: http://www.ietf.org/standards/dav/PropertyUpdate
Purpose: To contain a request to alter the properties on
receive a
resource.
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Values= *(Create | Remove)
Description:This XML element is listing of pages at a container for the information
required particular hierarchy level (like a
directory listing in a file system).

Locking: The ability to modify the properties keep more than one person from working on a
document at the resource. same time. This XML
element is multi-valued.

2.8.3.2 Create XML element

Name: http://www.ietf.org/standards/dav/create
Purpose: To create prevents the DAV properties specified inside "lost update problem"
in which modifications are lost as first one author, then another
writes their changes without merging the
Create XML element.
Schema: http://www.ietf.org/standards/dav/
Parent: http://www.ietf.org/standards/dav/PropertyUpdate
Values= Prop
Description:This XML element MUST contain only a Prop XML
element. other author's changes

Namespace Operations: The elements contained by Prop specify the name ability to copy and
value move Web resources

Efficient Update: The ability to send changes which are proportional
to the size of properties that the change rather than retransmitting the entire
resource.

Requirements and rationale for these operations are created on Request-URI. If described in a
property already exists then its value is replaced. The Prop XML
element MUST NOT contain
companion document, "Requirements for a PropLoc XML attribute.

2.8.3.3 Remove XML element

Name: http://www.ietf.org/standards/dav/remove
Purpose: To remove Distributed Authoring and
Versioning Protocol for the DAV World Wide Web" [Slein et al., 1997].

The sections below provide a detailed introduction to resource
properties specified inside (Section 3), collections of resources (Section 4), and
locking operations (Section 5). These sections introduce the
Remove XML element.
Schema: http://www.ietf.org/standards/dav/
Parent: http://www.ietf.org/standards/dav/PropertyUpdate
Values= Prop
Description:Remove specifies that
abstractions manipulated by the properties specified WebDAV-specific HTTP methods
described in Section 8, "HTTP Methods for Distributed Authoring".

In HTTP/1.1, method parameter information was exclusively encoded in
HTTP headers. Unlike HTTP/1.1, WebDAV, encodes method parameter
information either in
Prop should be removed. Specifying the removal of a property that
does not exist is not an error. All Extensible Markup Language (XML) [Bray,
Sperberg-McQueen, 1997] request entity body, or in an HTTP header.
The use of XML to encode method parameters was motivated by the
ability to add extra XML elements to existing structures, providing
extensibility, and by XML's ability to encode information in Prop MUST be
empty, as only the names ISO
10646 character sets, providing internationalization support. As a
rule of properties to be removed thumb, parameters are
required.

2.8.3.4 Response

The response MUST encoded in XML entity bodies when they
have a response body that contains a
multiresponse identifying the results for each property.

2.8.3.5 Response Codes

200 OK - The command succeeded. As there can unbounded length, or when they may be shown to a mixture of
Create human user and Removes
hence require encoding in a body, a 201 Create seems inappropriate.
403 Forbidden - The client, for reasons the server chooses not to
specify, can not alter one of the properties.
405 Conflict - The client has provided a value whose semantics an ISO 10646 character set. Otherwise,
parameters are not appropriate for encoded within an HTTP header. Section 9 describes
the property. This includes trying new HTTP headers used with WebDAV methods.
INTERNET-DRAFT WebDAV November 19, 1997

In addition to set
read only properties.
413 Request Entity Too Long - If a particular property encoding method parameters, XML is too
long used in WebDAV to be recorded then a composite XML error will be returned
indicating
encode the offending property.
417 Insufficient Space on Resource - The resource does not have
sufficient space to record responses from methods, providing the state extensibility and
internationalization advantages of XML for method output, as well as
input. XML elements used in this specification are defined in
Section 12.

While the resource after response codes provided by HTTP/1.1 are sufficient to
describe the
execution preponderance of this method.
418 Atomicity Failure - The command was error conditions encountered by WebDAV
methods, there are some errors that do not executed because of
an atomicity failure elsewhere fall neatly into the caused
existing categories. New status codes developed for the entire command WebDAV
methods are defined in Section 10. Since some WebDAV methods may
operate over many resources, the multiresponse status type has been
introduced to
be aborted.

2.8.3.6 Example

PROPPATCH /bar.html HTTP/1.1
Host: www.foo.com
Content-Type: text/xml
Content-Length: xxxx

<?XML:Namespace
href = "http://www.ietf.org/standards/dav/" AS = "D"/>
<?XML:Namespace
href = "http://www.w3.com/standards/z39.50/" AS = "Z"/>
<D:PropertyUpdate>
<Create>
<prop>
<Z:authors>
<Z:Author>Jim Whitehead</Z:Author>
<Z:Author>Roy Fielding</Z:Author>
</Z:authors>
</Prop>
</Create>
<Remove>
<prop><Z:Copyright-Owner/></prop>
</Remove>
</D:PropertyUpdate>

HTTP/1.1 405 Conflict
Content-Type: text/xml
Content-Length: xxxxx

<?XML:Namespace
href="http://www.ietf.org/standards/dav/" AS = "D"/>
<?XML:Namespace
href="http://www.w3.com/standards/z39.50/" AS = "Z"/>
<D:MultiResponse>
<ResponseDescription> Copyright Owner can not be deleted or
altered.</ResponseDescription>
<Response>
<Prop><Z:authors/></Prop>
<Status>HTTP/1.1 418 Atomicity Failure</Status>
</Response>
<Response>
<Prop><Z:Copyright-Owner/></Prop>
<Status>HTTP/1.1 405 Conflict</Status>
</Response>
</D:MultiResponse>

2.8.4 PUT

A PUT return status information for multiple resources.
Multiresponse status is specified described in order to control what Section 11.

The properties mechanism is returned employed by WebDAV to store information
about the current state of the resource. For example, when a GET.
However a GET lock
is taken out on a property always returns resource, a predefined lock information property
containment format. Therefore PUT can not be describes
the current state of the lock. Section 13 defines the properties
used if within the Request-
URI refers WebDAV specification.

Finishing off the specification are sections on what it means to a property.

2.8.5 PROPFIND

The PROPFIND method retrieves properties defined be
compliant with this specification (Section 14), on Request-URI.
internationalization support (Section 15), and on security (Section
16).

3. Data Model for Resource Properties

3.1. The request message body is an XML document Resource Property Model

Properties are pieces of data that MUST contain
only one PropFind XML element, which specifies describe the state of a resource.
Properties are data about data.

Properties are used in distributed authoring environments to provide
for efficient discovery and management of resources. For example, a
'subject' property might allow for the indexing of all resources by
their subject, and an 'author' property might allow for the type
discovery of what authors have written which documents.

The DAV property find action to be performed. model consists of name/value pairs. The XML element contained
by PropFind specifies the type name of action to be performed:
retrieve all a
property names identifies the property's syntax and values (AllProp), retrieve only
specified property names semantics, and values (Prop), or retrieve only a
list
provides an address by which to refer to that syntax and semantics.

There are two categories of all properties: "live" and "non-live". A
live property names (Propname). When a Prop XML element
is present, it specifies a list of has its syntax and semantics enforced by the names server.
This represents the two cases of properties whose
name and a) the value are to be returned. The Prop element, when used
within of a FINDPROP request body MUST be empty.

The response property is a text/xml message body that contains a
MultiResponse XML element which describes read-
only, maintained by the results server, and b) the value of the
attempts to retrieve property is
maintained by the various properties. If a client, but server performs syntax checking on
submitted values. A non-live property was
successfully retrieved then has its syntax and semantics
enforced by the client; the server merely records the value MUST be returned of the
property verbatim.
INTERNET-DRAFT WebDAV November 19, 1997

3.2. Existing Metadata Proposals

Properties have long played an essential role in the
prop maintenance of
large document repositories, and many current proposals contain some
notion of a property, or discuss web metadata more generally. These
include PICS [Miller et al., 1996], PICS-NG, the Rel/Rev draft
[Maloney, 1996], Web Collections, XML element. In [Bray, Sperberg-McQueen,
1997], several proposals on representing relationships within HTML,
digital signature manifests (DCMF), and a position paper on Web
metadata architecture [Berners-Lee, 1997]. Work on PICS-NG and Web
Collections has been subsumed by the case Resource Definition Framework
(RDF) metadata activity of Allprop and Findprop, if a
principal does not have the right to know if World Wide Web Consortium, which
consists of a particular
property exists, network-based data model and an error MUST NOT be returned. The results of
this method SHOULD NOT be cached.

2.8.5.1 Propfind XML element

Name: http://www.ietf.org/standards/dav/Propfind
Purpose: To specify representation of
that model.

Some proposals come from a digital library perspective. These
include the Dublin Core [Weibel et al., 1995] metadata set of matching properties
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Values= (Prop | Allprop | Propname)
Description: Propfind is and the
Warwick Framework [Lagoze, 1996], a container element architecture for the exact
specification
different metadata schemas. The literature includes many examples
of metadata, including MARC [MARC, 1994], a PROPFIND request.

2.8.5.2 Allprop

Name: http://www.ietf.org/standards/dav/Allprop
Purpose: To specify that all properties are to be returned
Schema: http://www.ietf.org/standards/dav/
Parent: Propfind
Description: Its presence in bibliographic metadata
format, and RFC 1807 [Lasher, Cohen, 1995], a PROPFIND request specifies technical report
bibliographic format employed by the
name and value Dienst system. Additionally,
the proceedings from the first IEEE Metadata conference describe
many community-specific metadata sets.

Participants of all properties defined on the resource MUST 1996 Metadata II Workshop in Warwick, UK
[Lagoze, 1996], noted that, "new metadata sets will develop as the
networked infrastructure matures" and "different communities will
propose, design, and be
returned.

2.8.5.3 Propname

Name: http://www.ietf.org/standards/dav/Propname
Purpose: To specify responsible for different types of
metadata." These observations can be corroborated by noting that the names
many community-specific sets of all properties defined on metadata already exist, and there is
significant motivation for the resource are development of new forms of metadata
as many communities increasingly make their data available in
digital form, requiring a metadata format to be returned.
Schema: http://www.ietf.org/standards/dav/
Parent: Propfind
Description: Its presence assist data location
and cataloging.

3.3. Properties and HTTP Headers

Properties already exist, in a PROPFIND request specifies the
name limited sense, in HTTP message
headers. However, in distributed authoring environments a
relatively large number of all properties defined on the resource MUST be returned.

2.8.5.4 PropFindResult XML element

Name: http://www.ietf.org/standards/dav/PropFindResult
Purpose: To contain are needed to describe the results
state of a SEARCH request
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Values: Prop

2.8.5.5 Example 1 - Prop

PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml

<?XML:Namespace href =
"http://www.ietf.org/standards/dav/" AS = "G"/>
<?XML:Namespace href =
"http://www.foo.bar/boxschema/" AS = "B"/>
<G:PROPFIND>
<prop>
<B:bigbox>
<B:author>
<B:DingALing>
<B:Random>
</prop>
</G:PROPFIND>

HTTP/1.1 207 Multi-Response
Content-Type: text/xml
Content-Length: xxxxx

<?XML:Namespace
href ="http://www.ietf.org/standards/dav/" AS = "S">
<?XML:Namespace href = "http://www.foo.bar/boxschema" AS = R">
<D:MultiResponse>
<ResponseDescription> There has been an access violation
error. </ResponseDescription>
<Response>
<Prop>
<R:bigbox D:Proploc="http://prop.com/BoxType">

<BoxType>Box type A</BoxType>
</R:bigbox>
<R:author D:Proploc="http://prop.com/Author">
<Name>J.J. Dingleheimerschmidt</Name>
</R:author>
</Prop>
<Status>HTTP/1.1 200 Success</Status>
</Response>
<Response>
<Prop><R:DingALing/><R:Random/></>
<Status>HTTP/1.1 403 Forbidden</Status>
<ResponseDescription> The user does not have access to
the DingALink property. </ResponseDescription>
</Response>
</D:MultiResponse>

The result will return resource, and setting/returning them all properties on the container. In this
case only two properties were found. The through HTTP
headers is inefficient. Thus a mechanism is needed which allows a
principal did not have
sufficient access rights to see the third and fourth identify a set of properties
so an error was returned.

2.8.5.6 Example 2 - Allprop

PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml

<?XML:Namespace href =
"http://www.ietf.org/standards/dav/" AS = "G"/>
<G:PROPFIND>
<Allprop/>
</G:PROPFIND>

HTTP/1.1 200 Success
Content-Type: text/xml
Content-Length: xxxxx

<?XML:Namespace href =
"http://www.ietf.org/standards/dav/" As = "S">
<?XML:Namespace href = "http://www.foo.bar/boxschema" AS = R">
<S:MultiResponse>
<Prop>
<R:bigbox D:Proploc="http://prop.com/BigBox">
<BoxType>Box type A</BoxType>
</R:bigbox>
<R:author D:Proploc="http://prop.com/Author">
<Name>Hadrian</Name>
</R:author>
</Prop>
<Status>HTTP/1.1 200 Success</Status>
</S:MultiResponse>

This particular client only had in which the right to see two properties,
BoxType principal is
interested and Author. No error to then set or retrieve just those properties.

3.4. Property Values

The value of a property is expressed as a well-formed XML document.
INTERNET-DRAFT WebDAV November 19, 1997

XML has been chosen because it is returned a flexible, self-describing,
structured data format that supports rich schema definitions, and
because of its support for the remaining
properties, as the client does not even have sufficient rights multiple character sets. XML's self-
describing nature allows any property's value to
know be extended by
adding new elements. Older clients will not break because they exist. If the client did will
still have the right to know data specified in the original schema and will ignore
elements they
existed but did do not have the right understand. XML's support for multiple
character sets allows human-readable properties to see their value, be encoded and
read in a 207
multi-response character set familiar to the user.

3.5. Property Names

A property name is a universally unique identifier that is
associated with a multiresponse, as used in schema that provides information about the previous
example, would have been returned.

2.8.5.7 Example 3 - Propname

PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml

<?XML:Namespace
href = "http://www.ietf.org/standards/dav/" AS = "G"/>
<G:PROPFIND>
<Propname/>
</G:PROPFIND>

HTTP/1.1 200 Success
Content-Type: text/xml
Content-Length: xxxxx

<?XML:Namespace
href = "http://www.ietf.org/standards/dav/" As = "S">
<?XML:Namespace
href = "http://www.foo.bar/boxschema" AS = "R">
<S:MultiResponse>
<Prop>
<R:bigbox D:Proploc="http://prop.com/BigBox"/>
<R:author D:Proploc="http://prop.com/Author"/>
<R:DingALing/>
<R:Random/>
</Prop>
<Status>HTTP/1.1 200 Success</Status>
</S:MultiResponse>

In this case only two syntax
and semantics of the property.

Because a property's name is universally unique, clients can depend
upon consistent behavior for a particular property across multiple
resources, so long as that property is "live" on the resources in
question.

The XML namespace mechanism, which is based on URIs, is used to name
properties have direct URLs
available, while because it provides a mechanism to prevent namespace
collisions and for varying degrees of administrative control.

The property namespace is flat; that is, no hierarchy of properties
is explicitly recognized. Thus, if a property A and a property A/B
exist on a resource, there is no recognition of any relationship
between the other two properties can only properties. It is expected that a separate
specification will eventually be referenced
via PROPFIND and PROPPATCH.

3 A Proposal for produced which will address issues
relating to hierarchical properties.

Finally, it is not possible to define the same property twice on a
single resource, as this would cause a collision in the resource's
property namespace.

4. Collections of Web Resources and Name Space
Operations

3.1 Observations on the HTTP Object Model

This section provides a description of a new type of Web resource,
the collection, and discusses its interactions with the HTTP URL
namespace. This discussion The purpose of a collection resource is to model
collection-like objects (e.g., filesystem directories) within a prerequisite for
server's namespace.

All DAV compliant resources MUST support the
specification of methods that operate on collections, given later
in this document.

3.1.1 HTTP URL namespace
model specified herein.

4.1. Collection Resources

A collection is a resource whose state consists of a an unordered list
of internal members, a an unordered list of external members, and a
INTERNET-DRAFT WebDAV November 19, 1997

set of properties. An internal member resource MUST have a URI that
is immediately relative to the base URI of the collection, that is,
a relative URI in which "../" is illegal, which must MUST begin with "./"
and which MAY SHOULD contain only one other a "/" at the end of the
URI. URI if the internal
member resource is itself a collection.

An external member resource MUST be an absolute URI that is not an
internal URI. Any given internal or external URI MUST only belong
to the collection once, i.e., it is illegal to have multiple
instances of
URIs the same URI in a collection are illegal. collection. Properties defined on
collections have no special distinction, and behave exactly as do properties on non-collection
resources.

The purpose of

There is a standing convention that when a collection resource is referred to model collection-like
objects (e.g.,
by its name without a filesystem directory) within trailing slash, the trailing slash is
automatically appended. Due to this, a server's
namespace. Once these objects have been modeled with
collections, resource MAY accept a client may perform an INDEX, add and remove

external members using ADDREF and DELREF, and perform recursive
operations, such as URI
without a full hierarchy copy.

To support methods which operate on collections, trailing "/" to point to a server collection. In this case it
SHOULD
model its collection-like objects return a location header in the response pointing to the URL
ending with collection resources. the "/". For example, if a server which is implemented on top of a filesystem
SHOULD treat all filesystem directories exposed by client performs an INDEX on
http://foo.bar/blah (no trailing slash), the server resource
http://foo.bar/blah/ (trailing slash) MAY respond as
collection resources.

3.1.2 if the
operation were invoked on it, and SHOULD return a location header
with http://foo.bar/blah/ in it.

4.2. Creation and Retrieval of Collection Resources

This document specifies the MKCOL method to create new collection
resources, and rather than using the INDEX method to list their contents. existing HTTP/1.1 PUT or POST
method, for the following reasons

In HTTP/1.1, the PUT method is defined to store the request body
at request body at
the location specified by the Request-URI. While a description
format for a collection can readily be constructed for use with PUT,
the implications of sending such a description to the server are
undesirable. For example, if a description of a collection that
omitted some existing resources were PUT to a server, this might be
interpreted as a command to remove those members. This would extend
PUT to perform DELETE functionality, which is undesirable since it
changes the semantics of PUT, and makes it difficult to control
DELETE functionality with an access control scheme based on methods.

While the POST method is sufficiently open-ended that a _create a
collection_ POST command could be constructed, this is undesirable
because it would be difficult to separate access control for
collection creation from other uses of POST.

This document specifies the INDEX method for listing the contents of
a collection, rather than relying on the existing HTTP/1.1 GET
method. This is to avoid conflict with the de-facto standard
practice of redirecting a GET request on a directory to its
index.html resource.
INTERNET-DRAFT WebDAV November 19, 1997

The exact definition of the behavior of GET and PUT on collections
is defined later in this document.

4.3. HTTP URL Namespace Model

The HTTP URL Namespace is a hierarchical namespace where the
hierarchy is delimited with the "/" character. DAV compliant
resources MUST maintain the location specified by Request-URI. While consistency of the HTTP URL namespace.
Any attempt to create a description
format for resource (excepting the root member of a collection can readily be constructed
namespace) that could would not be
used with PUT, the implications internal member of sending such a description to
the server are undesirable. collection
MUST fail. For example, if the collection http://www.foo.bar.org/a/
exists, but http://www.foo.bar.org/a/b/does not exist, an attempt to
create http://www.foo.bar.org/a/b/c must fail.

4.4. Source Resources and Output Resources

For many resources, the entity returned by a description GET method exactly
matches the persistent state of the resource, for example, a
collection that omitted some existing resources were PUT to GIF
file stored on a
server, disk. For this might be interpreted as simple case, the URL at which a command to remove those
members. This would extend PUT
resource is accessed is identical to perform DELETE functionality, the URL at which is undesirable since it changes the semantics source
(the persistent state) of PUT, and
makes it difficult to control DELETE functionality with an access
control scheme based on methods.

While the POST method resource is sufficiently open-ended accessed. This is also
the case for HTML source files that are not processed by the server
prior to transmission.

However, the server can sometimes process HTML resources before they
are transmitted as a "create return entity body. For example, server-side-
include directives within an HTML file instruct a
collection" POST command could be constructed, server to replace
the directive with another value, such as the current date. In this
case, what is
undesirable because it would be difficult to separate access
control for collection creation returned by GET (HTML plus date) differs from other uses the
persistent state of POST if they
both use the same method.

While it might seem desirable resource (HTML plus directive). Typically
there is no way to have access the HTML resource containing the
unprocessed directive.

Sometimes the entity returned by GET return a listing of is the
members output of a collection, this data-
producing process that is foiled described by one or more source resources
(that may not even have a location in the existence URL namespace). A single
data-producing process may dynamically generate the state of a
potentially large number of output resources. An example of this is
a CGI script that describes a "finger" gateway process that maps
part of the
"index.html" de-facto standard namespace redirection, in which a
GET request on of a collection server into finger requests, such as
http://www.foo.bar.org/finger_gateway/user@host.

In the absence of distributed authoring capabilities, it is automatically redirected
acceptable to the
index.html resource.

The exact definition have no mapping of source resource(s) to the behavior URI
namespace. In fact, preventing access to the source resource(s) has
desirable security benefits. However, if remote editing of GET and PUT on
collections is defined later in this document.

3.1.2.1 Example

The structured resource http://foo/bar is created with a PUT. Bar the
source resource(s) is a multipart/related file with two members http://foo/bar/a and
http://foo/bar/b. If bar were deleted then both a and b would
also desired, the source resource(s) should be deleted since they are all really just one resource. If
http://foo/bar/a/c was PUT then a DELETE on http://foo/bar/a
would also delete http://foo/bar/a/c as c was created with
given a PUT location in the URI namespace. This source location should
not a MKCOL.

If http://foo/bar/b/d be one of the locations at which the generated output is
retrievable, since in general it is impossible for the server to
differentiate requests for source resources from requests for
INTERNET-DRAFT WebDAV November 19, 1997

process output resources. There is created with often a MKCOL many-to-many
relationship between source resources and
http://foo/bar/b/d/e was created then output resources.

On WebDAV compliant servers, for all output resources which have a DELETE on d would fail
because d is
single source resource (and that source resource has a collection with an internal member. However URI), the
existence URI
of the collection d is something of an illusion. If source resource SHOULD be stored in a
DELETE was executed link on http://foo/bar then everything would be
deleted, even though http://foo/bar/b/d was created the output
resource with a MKCOL.

Thus type http://www.ietf.org/standards/dav/source. Note
that by storing the effect source URIs in links on the output resources,
the burden of a MKCOL within a composite resource’s
namespace discovering the source is felt placed on its children, not its ancestors. the authoring
client.

5. Locking

The
children of d MUST be treated as members of ability to lock a collection when resource provides a
method is executed on d. But mechanism for serializing
access to that resource. Using a method executed on b or lock, an authoring client can
provide a reasonable guarantee that another principal will not
modify a resource while it is
treated as if there only existed being edited. In this way, a non-collection resource.

3.1.3 Source Resources and Output Resources

For many resources, client
can prevent the entity returned by GET exactly matches "lost update" problem.

This specification allows locks to vary over two client-specified
parameters, the persistent state number of principals involved (exclusive vs. shared)
and the resource, for example, a GIF file
stored on a disk. For type of access to be granted. Furthermore, this simple case, document
only provides the URL at which a
resource is accessed is identical to definition of locking for one lock access type,
the write lock. However, the URL at which syntax is extensible, and permits the source
(the persistent state)
eventual specification of the resource other access types.

5.1. Exclusive Vs. Shared Locks

The most basic form of lock is accessed. an exclusive lock. This is also a lock
where the case access right in question is only granted to a single
principal. The need for HTML source files that are not processed by the
server prior this arbitration results from a desire to transmission.
avoid having to constantly merge results.

However, the server can sometimes process HTML resources before
they there are transmitted as times when the goal of a return entity body. For example,
server-side-include directives within lock is not to exclude
others from exercising an HTML file instruct access right but rather to provide a
server
mechanism for principals to replace the directive with another value, such as the
current date. In indicate that they intend to exercise
their access right. Shared locks are provided for this case, what is returned by GET (HTML plus
date) differs from the persistent state of case. A
shared lock allows multiple principals to receive a lock. Hence any
principal with appropriate access can get the resource (HTML
plus directive). Typically lock.

With shared locks there are two trust sets that affect a resource.
The first trust set is no way created by access permissions. Principals
who are trusted, for example, may have permission to write the
resource. Those who are not, don't. Among those who have access
permission to write the HTML
resource containing resource, the set of principals who have
taken out a shared lock also must trust each other, creating a
(typically) smaller trust set within the unprocessed directive.

Sometimes access permission write
set.

Starting with every possible principal on the entity returned by GET is Internet, in most
situations the output vast majority of a data-
producing process that is described by one or more source
resources (that may these principals will not even have write
INTERNET-DRAFT WebDAV November 19, 1997

access to a location in the URL
namespace). A single data-producing process may dynamically
generate given resource. Of the state of a potentially large small number who do have write
access, some principals may decide to guarantee their edits are free
from overwrite conflicts by using exclusive write locks. Others may
decide they trust their collaborators will not overwrite their work
(the potential set of output
resources. An example collaborators being the set of this is principals who
have write permission) and use a CGI script shared lock, which informs their
collaborators that describes a
"finger" gateway process that maps part principal is potentially working on the
resource.

The WebDAV extensions to HTTP do not need to provide all of the namespace
communications paths necessary for principals to coordinate their
activities. When using shared locks, principals may use any out of a
server into finger requests, such as
http://www.foo.bar.org/finger_gateway/user@host.

In
band communication channel to coordinate their work (e.g., face-to-
face interaction, written notes, post-it notes on the absence screen,
telephone conversation, Email, etc.) The intent of distributed authoring capability, it a shared lock is
acceptable
to have no mapping of source resource(s) let collaborators know who else is potentially working on a
resource.

Shared locks are included because experience from web distributed
authoring systems has indicated that exclusive write locks are often
too rigid. An exclusive write lock is used to the URI
namespace, and in fact has desirable security benefits. However,
if remote enforce a particular
editing of process: take out exclusive write lock, read the source resource(s) is desired, resource,
perform edits, write the
source resource(s) should be given a location in resource, release the URI
namespace. lock. This source location should not be one of the
locations at which the generated output is retrievable, since in
general it is impossible for editing
process has the server to differentiate requests
for source resources from requests problem that locks are not always properly released,
for process output resources.
There is often example when a many-to-many relationship between source
resources and output resources.

For DAV compliant servers all output resources which have program crashes, or when a
single source resource (and that source resource has lock owner leaves
without unlocking a URI), resource. While both timeouts and
administrative action can be used to remove an offending lock,
neither mechanism may be available when needed; the
URI of timeout may be
long or the source resource SHOULD administrator may not be stored in available.

Despite their potential problems, exclusive write locks are
extremely useful, since often a single link on
the output resource with type
http://www.ietf.org/standards/dav/source. Note that by storing
the source URI in links on the output resources, the burden guarantee of
discovering the source freedom from overwrite
conflicts is placed on the authoring client.

3.2 MKCOL Method

3.2.1 Problem Description

A client must be able to create a collection.

3.2.2 Solution Requirements

The solution must ensure that a collection has been made (i.e.
that it responds to what is needed. This specification provides both
exclusive write locks and the INDEX method) as opposed less strict mechanism of shared locks.

5.2. Required Support

A WebDAV compliant server is not required to a non-

collection resource. support locking in any
form. If a collection could not be made, the server does support locking it must
indicate MAY choose to support
any combination of exclusive and shared locks for any access types.

The reason for this failure flexibility is that locking policy strikes to
the user-agent.

3.2.3 Request

MKCOL creates a new collection resource at very heart of the location specified resource management and versioning systems
employed by the Request-URI. If the Request-URI exists, then MKCOL must
fail. During MKCOL processing, a server MUST make the Request-URI
a member various storage repositories. These repositories
require control over what sort of its parent collection. If locking will be made available.
For example, some repositories only support shared write locks while
others only provide support for exclusive write locks while yet
others use no such an ancestor exists,
the method MUST fail. When locking at all. As each system is sufficiently
different to merit exclusion of certain locking features, this
specification leaves locking as the MKCOL operation creates sole axis of negotiation within
WebDAV.
INTERNET-DRAFT WebDAV November 19, 1997

5.3. Lock Tokens

A lock token is a new
collection resource, all ancestors MUST already exist, or the
method MUST fail with URI that identifies a 409 Conflict status code. For example,
if particular lock. A lock
token is returned by every successful LOCK operation in the lock-
token response header, and can also be discovered through lock
discovery on a request resource.

Lock token URIs are required to create collection /a/b/c/d/ is made, be unique across all resources for
all time. This uniqueness constraint allows lock tokens to be
submitted across resources and neither
/a/b/ nor /a/b/c/ exist, the request MUST fail.

3.2.3.1 MKCOL Without Request Body

When MKCOL is invoked servers without a request body, the newly created
collection has no members.

3.2.3.2 MKCOL With Request Body

A MKCOL request message MAY contain a message body. The behavior fear of confusion.

This specification provides a MKCOL request when lock token URI scheme called
opaquelocktoken that meets the body is present is limited uniqueness requirements. However
resources are free to
creating collections, members of a collection, bodies of members
and properties on the collections or members. If the server
receives a MKCOL request entity type it does not support or
understand return any URI scheme so long as it MUST respond with a 415 (Unsupported Media Type)
status code. meets the
uniqueness requirements.

5.4. opaquelocktoken Lock Token URI Scheme

The exact behavior of MKCOL for various request
media types opaquelocktoken URI scheme is undefined in this document, and will designed to be specified unique across all
resources for all time. Due to this uniqueness quality, a client
MAY submit an opaque lock token in separate documents.

3.2.4 Response

Responses from a MKCOL Lock-Token request are not cacheable, since MKCOL has
non-idempotent semantics.
201 (Created) - The collection or structured header and
an if-state[-not]-match header on a resource was created
in its entirety.
403 (Forbidden) - This indicates at least other than the one of two conditions:
1) The server does that
returned it.

All resources MUST recognize the opaquelocktoken scheme and, at
minimum, recognize that the lock token was not allow generated by the
resource. Note, however, that resources are not required to
generate opaquelocktokens in LOCK method responses.

In order to guarantee uniqueness across all resources for all time
the creation opaquelocktoken requires the use of collections at the
given location in its namespace, and 2) The parent collection GUID mechanism.

Opaquelocktoken generators, however, have a choice of how they
create these tokens. They can either generate a new GUID for every
lock token they create, which is potentially very expensive, or they
can create a single GUID and then add extension characters. If the Request-URI exists but cannot accept members.
409 (Conflict) - A collection cannot
second method is selected then the program generating the extensions
MUST guarantee that the same extension will never be made at used twice with
the Request-URI
until one or more intermediate collections have been created.
415 (Unsupported Media Type)- The associated GUID.

Opaque-Lock-Token = "opaquelocktoken" ":" GUID [Extension]
GUID = ; As defined in [Leach, Salz, 1997]
Extension = *urlc ;urlc is defined in [Berners-Lee et al., 1997]
(draft-fielding-url-syntax-07.txt)

5.5. Lock Capability Discovery

Since server does not lock support the
request type of the body.
417 (Insufficient Space on Resource) - The resource does not have
sufficient space is optional, a client trying to record the state of the lock a
resource after on a server can either try the
execution lock and hope for the best,
or perform some form of this method.

3.2.5 Example

This example creates a container collection called
/webdisc/xfiles/ on discovery to determine what lock
capabilities the server www.server.org.
MKCOL /webdisc/xfiles/ HTTP/1.1
Host: www.server.org

HTTP/1.1 201 Created

3.3 Standard DAV Properties

The following properties are defined on supports. This is known as lock capability
discovery. Lock capability discovery differs from discovery of
INTERNET-DRAFT WebDAV November 19, 1997

supported access control types, since there may be access control
types without corresponding lock types. A client can determine what
lock types the server supports by retrieving the supportedlock
property.

Any DAV compliant resources.
All enclosed properties are part of resource that supports the DAV Schema.

3.3.1 IsCollection Property

Name: http://www.ietf.org/standards/dav/iscollection
Purpose: This property contains LOCK method MUST
support the supportedlock property.

5.6. Active Lock Discovery

If another principal locks a Boolean value resource that a principal wishes to
access, it is set useful for the second principal to
"true" if be able to find out
who the resource first principal is. For this purpose the lockdiscovery
property is a collection
Schema: http://www.ietf.org/standards/dav/
Value: ("true" | "false")
Description: provided. This property MUST be defined on lists all outstanding locks,
describes their type, and provides their lock token.

Any DAV compliant
resources.

3.3.2 DisplayName Property

Name: http://www.ietf.org/standards/dav/displayname
Purpose: A name for the resource that is suitable for
presentation to a user.
Schema: http://www.ietf.org/standards/dav/
Value: Any valid XML character data (as defined in [Bray,
Sperberg-McQueen, 1997])
Description: supports the LOCK method MUST
support the lockdiscovery property.

6. Write Lock

This property SHOULD be defined on all DAV compliant
resources. If present, section describes the property contains a description of semantics specific to the
resource that is suitable write access
type for presentation to a user.

3.3.3 CreationDate Property

Name: http://www.ietf.org/standards/dav/creationdate
Purpose: locks. The time write lock is a specific instance of a lock
type, and date is the resource was created.
Schema: http://www.ietf.org/standards/dav/
Value: The time and date MUST be given only lock type described in ISO 8601 format
[ISO8601]
Description: This property SHOULD be defined on all this specification. A
DAV compliant
resources. If present, it contains a timestamp of the moment when
the resource was created (i.e., the moment it had non-null
state).

3.3.4 GETentity Property

Name: http://www.ietf.org/standards/dav/GETentity
Purpose: Contains MAY support the value of headers that are returned write lock.

6.1. Methods Restricted by Write Locks

A write lock prevents a
GET principal without Accept headers.
Schema: http://www.ietf.org/standards/dav/
Value: Content-Type Content-Length Content-Language Last-
Modified Etag Creation-Date
Description: This property MUST be defined the lock from successfully
executing a PUT, POST, PATCH, PROPPATCH, MOVE, DELETE, MKCOL, ADDREF
or DELREF on all DAV compliant
resources unless the locked resource. All other current methods, GET is not supported, in which case this
property MUST NOT be defined. This property MUST contain at most
one instance
particular, function independent of each element in its Value, if they are defined.

3.3.5 INDEXentity Property

Name: http://www.ietf.org/standards/dav/INDEXentity
Purpose: Contains the value of headers lock.

Note, however, that as new methods are returned by an
INDEX.
Schema: http://www.ietf.org/standards/dav/
Value: Content-Type Content-Length Content-Language Last-
Modified Etag Creation-Date

Description: This property MUST created it will be defined on all DAV compliant
resources unless INDEX is necessary
to specify how they interact with a write lock.

6.2. Write Locks and Properties

While those without a write lock may not supported, in which case this
property MUST NOT be defined. This alter a property MUST contain at most
one instance of each element in its Value, if they are defined.

3.3.6 Content-Type XML Element

Name: http://www.ietf.org/standards/dav/content-type
Purpose: The content-type of on a
resource it is still possible for the member resource.
Schema: http://www.ietf.org/standards/dav/
Parent: GETentity or INDEXentity
Value: media-type ; defined in Section 3.7 values of [Fielding et
al., 1997]
Description: If live properties to
change, even while locked, due to the parent requirements of this element their schemas.
Only dead properties and live properties defined to respect locks
are guaranteed not to change while write locked.

6.3. Write Locks and Null Resources

It is GETentity, the
value MUST be identical possible to assert a write lock on a null resource in order to
lock the content-type returned by name. Please note, however, that locking a GET on
the null resource without Accept headers. If the parent is
INDEXentity,
effectively makes the value MUST be identical to resource non-null, as the content-type
returned by an INDEX resource now has
lock related properties defined on it.
INTERNET-DRAFT WebDAV November 19, 1997

6.4. Write Locks and Collections

A write lock on a collection prevents the resource. If no content-type is
available, this element MUST NOT be defined.

3.3.7 Content-Length XML Element

Name: http://www.ietf.org/standards/dav/content-length
Purpose: Describes the default content-length addition or removal of the resource.
Schema: http://www.ietf.org/standards/dav/
Value: content-length ; see section 14.14
members of RFC 2068
Description: If the parent collection. As a consequence, when a principal
issues a request to create a new internal member of this element is GETentity, this
element MUST have a value equal collection
using PUT or POST, or to remove an existing internal member of a
collection using DELETE, this request MUST fail if the content-length header
returned by principal
does not have a GET write lock on the resource without Accept headers. If the
parent collection.

However, if a write lock request is INDEXentity, the value MUST be identical issued to a collection
containing internal member resources that are currently locked in a
manner which conflicts with the
content-length returned by an INDEX on write lock, the resource. If no
content-length is available, this element request MUST NOT be defined.

3.3.8 Content-Language XML Element

Name: http://www.ietf.org/standards/dav/content-language
Purpose: Describes the default natural language of fail
with a resource.
Schema: http://www.ietf.org/standards/dav/
Value: language-tag ;language-tag is defined in section
14.13 of RFC 2068
Description: If the parent 409 Conflict status code.

6.5. Write Locks and COPY/MOVE

The owner of this element is GETentity, this
element MUST have a value equal to the content-language header
returned by write lock MUST NOT execute a GET MOVE method on the a
resource without Accept headers. If the
parent he has locked. This specification intentionally does not
define what happens if a MOVE method request is INDEXentity, the value MUST be identical to the
content-language header returned by an INDEX made on a locked
resource by the resource. If
no content-language header is available, this element lock's owner.

A COPY method invocation MUST NOT be
defined.

3.3.9 Last-Modified XML Element

Name: http://www.ietf.org/standards/dav/last-modified
Purpose: The date the resource was last modified.
Schema: http://www.ietf.org/standards/dav/
Parent: GETentity or INDEXentity
Value: The date MUST be given in RFC 1123 format using duplicate any write locks active
on the
rfc-1123 production, defined in section 3.3.1 of [Fielding et al.,
1997].
Description: source.

6.6. Re-issuing Write Locks

If the parent of this element is GETentity, this

element MUST have a value equal to the last-modified header
returned by principal already owns a GET write lock on a resource, any future
requests for the same type of write lock, on the resource without Accept headers. If same resource,
while the
parent principal's previous write lock is INDEXentity, the value in effect, MUST be identical to result
in a successful response with the last-
modified header returned by an INDEX on same lock token as provided for
the resource. If no
last-modified header is available, this element MUST NOT currently existing lock. Two lock requests are defined to be defined.

3.3.10 Etag XML Element

Name: http://www.ietf.org/standards/dav/etag
Purpose:
identical if their Lock-Info headers are identical.

6.7. Write Locks and The entity tag of the resource.
Schema: http://www.ietf.org/standards/dav/
Parent: GETentity or INDEXentity
Value: entity-tag ; defined in Section 3.11 of [Fielding et
al., 1997]
Description: Lock-Token Request Header

If the parent of this element a user agent is GETentity, this
element MUST not required to have knowledge about a lock when
requesting an operation on a value equal to locked resource, the entity-tag header returned following scenario
might occur. Program A, run by User A, takes out a GET write lock on a
resource. Program B, also run by User A, has no knowledge of the resource without Accept headers. If
lock taken out by Program A, yet performs a PUT to the parent locked
resource. In this scenario, the PUT succeeds because locks are
associated with a principal, not a program, and thus program B,
because it is acting with principal A's credential, is INDEXentity, allowed to
perform the value MUST be identical PUT. However, had program B known about the lock, it
would not have overwritten the resource, preferring instead to
present a dialog box describing the entity-tag
header returned by an INDEX on conflict to the resource. If no entity-tag
header is available, user. Due to
this element MUST NOT be defined.

3.4 INDEX Method

3.4.1 Problem Description

A scenario, a mechanism is needed to discover if a resource prevent different programs
from accidentally ignoring locks taken out by other programs with
the same authorization.
INTERNET-DRAFT WebDAV November 19, 1997

In order to prevent these collisions the lock token request header
is a collection introduced. Please refer to the Lock Token Request Header
section for details and if so, list its members.

3.4.2 Solution Requirements

The solution:
- requirements.

6.7.1. Write Lock Token Example

COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
Lock-Token: <opaquelocktoken:123AbcEfg1284h23h2>
<opaquelocktoken:AAAASDFcalkjfdas12312>

HTTP/1.1 200 OK

In this example, both the source and destination are locked so two
lock tokens must allow be submitted. If only one of the two resources was
locked, then only one token would have to be submitted.

7. Notational Conventions

Since this document describes a client set of extensions to the HTTP/1.1
protocol, the augmented BNF used herein to discover describe protocol
elements is exactly the members of a collection
- must always provide a machine-readable description same as described in Section 2.1 of RFC
2068, _Hypertext Transfer Protocol -- HTTP/1.1_ [Fielding et al.,
1997]. Since this augmented BNF uses the
membership basic production rules
provided in Section 2.2 of a collection
- must be leveraged RFC 2068, these rules apply to this
document as a more general mechanism well.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to provide a
list of contents be interpreted as described in RFC 2119 [Bradner,
1997].

8. HTTP Methods for any resource which can profitably return a
membership like listing.

3.4.3 The Request Distributed Authoring

8.1. PROPFIND

The INDEX PROPFIND method returns retrieves properties defined on the Request-URI,
if it is a machine-readable representation of non-collection resource, or on the
membership of Request-URI and
potentially its member resources, if the resource at the Request-URI.

For a collection, INDEX MUST return is a list of its members. collection.
All
WebDAV DAV compliant resources MUST support the text/xml response
entity described below. The INDEX result for PROPFIND method.

A client MAY submit a Depth header with a PROPFIND on a collection MAY
also return
with a list value of "0", "1" or "infinity". DAV compliant servers MUST
support the members of child collections, to any
depth.

Collections that respond to an INDEX "0", "1" and "infinity" behaviors. By default, the
PROPFIND method with on a text/xml
entity collection without a Depth header MUST contain only one ResInfo element. This ResInfo
element contains an Href element, which gives the identifier(s)
of the resource, act as
if a Depth = infinity header was included.
INTERNET-DRAFT WebDAV November 19, 1997

A client MUST submit a Propfind request header describing what
information is being requested. It is possible to request
particular property values, all property values, or a Prop element, which gives selected properties list of the resource, and a Members element, which contains a ResInfo
element for each member
names of the collection. The Prop element MUST

contain at least the following properties, if they are defined
and available: DisplayName, IsCollection, CreationDate,
GETentity, and INDEXentity. resource's properties.

The response from INDEX is cacheable, and SHOULD be accompanied
by an ETag header (see section 13.3.4 of RFC 2068). If GET and
INDEX return different entities for the same resource state, they
MUST return different entity tags.

3.4.4 The Response

200 (OK) - The server MUST send a machine readable response
entity which text/xml message body that contains a multistatus
XML element that describes the membership results of the resource.

3.4.5 ResInfo XML Element

Name: http://www.ietf.org/standards/dav/resinfo
Purpose: Describes attempts to retrieve
the various properties. If a resource.
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Value: Href Prop Members
Description: There property was successfully retrieved
then its value MUST be at least one Href element. Each Href
element contains returned in a URI for prop XML element. If the scope
of PROPFIND covers more than a single resource, which as is the case with
Depth values of "1" and "infinity", each response XML element MUST be
contain an
absolute URI. There MUST be a single Prop href XML element that contains a
series of properties defined on the resource. If which identifies the resource is
a collection, it MAY have at most one Members element, on which
describes
the members of properties in the collection.

3.4.6 Members prop XML Element

Name: http://www.ietf.org/standards/dav/members
Purpose: Describes element are defined. In the membership case of
allprop and propname, if a collection resource.
Schema: http://www.ietf.org/standards/dav/
Parent: ResInfo
Value: ResInfo
Description: Contains zero or more ResInfo elements, which
describe members of the collection.

3.4.7 Href XML Element

Name: http://www.ietf.org/standards/dav/href
Purpose: To identify that the content of principal does not have the element is a URI.
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Value: URI ; See section 3.2.1 right to know
if a particular property exists, an error MUST NOT be returned. The
results of [Fielding et al., 1997]

3.4.8 Example

INDEX /user/yarong/dav_drafts/ this method SHOULD NOT be cached.

8.1.1. Example: Retrieving Named Properties

PROPFIND /files/ HTTP/1.1
Host: www.microsoft.com www.foo.bar
Depth: 0
Propfind: <http://www.foo.bar/boxschema/bigbox> <http://www.foo.bar/
boxschema/author> <http://www.foo.bar/boxschema/DingALing> <http://w
ww.foo.bar/boxschema/Random>

HTTP/1.1 200 OK 207 Multi-Status
Content-Type: text/xml
Content-Length: xxx
Last-Modified: Thu, 11 Sep 1997 23:45:12 GMT
ETag: "fooyyybar"

<?XML:Namespace xxxxx

<?XML version="1.0">
<?namespace href ="http://www.ietf.org/standards/dav/" AS = "http://www.ietf.org/standards/dav/" as "D"?>
<?namespace href = "D"/>

<D:ResInfo>
<XML:Href>
http://www.microsoft.com/user/yarong/dav_drafts/
</XML:Href>
<Prop>
<DisplayName>
WebDAV working drafts directory
</DisplayName>
<IsCollection>true</IsCollection>
<CreationDate>19970418T070304Z</CreationDate>
<GETentity>
<Content-Type>text/html</Content-Type>
<Content-Length>2754</Content-Length>
<Content-Language>en</Content-Language>
<Last-Modified>
Fri, 22 Aug 1997 10:11:26 GMT
</Last-Modified>
<Etag>"8675309"</Etag>
</GETentity>
<INDEXentity>
<Content-Type>text/xml</Content-Type>
<Content-Length>xxx</Content-Length>
<Last-Modified>
Thu, 11 Sep 1997 23:45:12 GMT
</Last-Modified>
<Etag>"fooyyybar"</Etag>
</INDEXentity>
</Prop>

<Members>
<ResInfo>
<XML:Href>
http://www.microsoft.com/user/yarong/dav_drafts/base
</XML:Href>
<Prop>
<IsCollection
D:PropLoc="http://www.microsoft.com/user/yarong/dav_drafts/b
ase;props=IsCollection">
False
</IsCollection>
<DisplayName> "http://www.foo.bar/boxschema" AS = R"?>
<D:multistatus>
<D:response>
<D:prop>
<R:bigbox>
<R:BoxType>Box type A</R:BoxType>
</R:bigbox>
<R:author>
<R:Name>J.J. Dingleheimerschmidt</R:Name>
</R:author>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:prop><R:DingALing/><R:Random/></D:prop>
<D:status>HTTP/1.1 403 Forbidden</D:status>
<D:responsedescription> The user does not have access to the
DingALing property.
</D:responsedescription>
</D:response>
INTERNET-DRAFT WebDAV Name Space Operations Draft
</DisplayName>
<Creation-Date>19970320T230525Z</Creation-Date>

<GETentity>
<Content-Type>application/msword</Content-Type>
<Content-Length>1400</Content-Length>
<Content-Language>en</Content-Language>
<Last-Modified>
Fri, 22 Aug November 19, 1997 18:22:56 GMT
</Last-Modified>
<Etag>"8675309"</Etag>
</GETentity>
</Prop>
</ResInfo>
</Members>
</D:ResInfo>

This example shows

<D:responsedescription> There has been an access violation error.
</D:responsedescription>
</D:multistatus>

In this example, PROPFIND is executed on the result of collection
http://www.foo.bar/files/. The specified depth is zero, hence the INDEX method applied
PROPFIND applies only to the collection resource
http://www.microsoft.com/user/yarong/dav_drafts/. It returns a
response body in XML format, which gives information about the
container itself, and not to any of
its sole member,
http://www.microsoft.com/user/yarong/dav_drafts/base. The entry

on the collection confirms that the resource the INDEX was
executed on is a collection. members. The result also contains the URI of
the IsCollection property on Propfind header specifies the member resource.

3.5 Behavior name of RFC 2068 Methods on Collections

With four
properties whose values are being requested. In this case only two
properties were returned, since the introduction of principal issuing the collection resource type request
did not have sufficient access rights to see the HTTP
object model, it is necessary third and fourth
properties.

8.1.2. Example: Using allprop to define the behavior of the
existing methods (defined in RFC 2068) when Retrieve All Properties

PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Depth: 1
Propfind: allprop

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

<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" As = "S"?>
<?namespace href = "http://www.foo.bar/boxschema/" AS = R"?>
<S:multistatus>
<S:response>
<S:href>http://www.foo.bar/container/</S:href>
<S:prop>
<R:bigbox>
<R:BoxType>Box type A</R:BoxType>
</R:bigbox>
<R:author>
<R:Name>Hadrian</R:Name>
</R:author>
</S:prop>
<S:status>HTTP 1.1 200 OK</S:status>
</S:response>
<S:response>
<S:href>http://www.foo.bar/container/index.html</S:href>
<S:prop>
<R:bigbox>
<R:BoxType>Box type B</R:BoxType>
</R:bigbox>
</S:prop>
<S:status>HTTP 1.1 200 OK</S:status>
</S:response>
</S:multistatus>
INTERNET-DRAFT WebDAV November 19, 1997

In this example, PROPFIND was invoked on a
collection the resource to avoid ambiguity. While some methods, such
as OPTIONS and TRACE behave identically when applied to
collections, GET, HEAD, POST, PUT, and DELETE require some
additional explanation.

3.5.1 GET, HEAD for Collections

The semantics of GET are unchanged when applied to
http://www.foo.bar/container/ with a collection,
since GET is defined as, "retrieve whatever information (in the
form Depth header of an entity) is identified by 1, meaning the Request-URI" [Fielding et
al., 1997]. GET when applied
request applies to a collection MAY return the
contents of an "index.html" resource, resource and its children, and a human-readable view Propfind
header of "allprop", meaning the contents of request should return the collection, or something else altogether, name and
hence it is possible the result
value of a GET all properties defined on each resource.

The resource http://www.foo.bar/container/ has two properties
defined on it, named http://www.foo.bar/boxschema/bigbox, and
http://www.foo.bar/boxschema/author, while resource
http://www.foo.bar/container/index.html has only a collection will
bear no correlation to the state of the collection.

Similarly, since the definition single resource
defined on it, named http://www.foo.bar/boxschema/bigbox, another
instance of HEAD is a GET without a
response message body, the semantics of HEAD are unmodified when
applied "bigbox" property type.

8.1.3. Example: Using propname to collection resources.

3.5.2 POST for Collections

Since by definition the actual function performed by POST Retrieve all Property Names

PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Propfind: propname

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

<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" As = "D"?>
<?namespace href = "http://www.foo.bar/boxschema/" AS = "R"?>
<D:multistatus>
<D:response>
<D:href>http://www.foo.bar/container/</D:href>
<D:prop>
<R:bigbox/>
<R:author/>
</D:prop>
<D:status>HTTP 1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http://www.foo.bar/container/index.html</D:href>
<D:prop>
<R:bigbox/>
</D:prop>
<D:status>HTTP 1.1 200 OK</D:status>
</D:response>
</D:multistatus>

In this example, PROPFIND is
determined by the server and often depends invoked on the particular
resource, the behavior of POST when applied collection resource
http://www.foo.bar/container/, with a Propfind header set to collections cannot
"propname", meaning the name of all properties should be meaningfully modified because it returned.
Since no depth header is largely undefined. Thus
the semantics present, it assumes its default value of POST are unmodified when applied to a
collection.

3.5.3 PUT for Collections

As defined in
"infinity", meaning the HTTP/1.1 specification [Fielding et al., 1997], name of the "PUT method requests that properties on the enclosed entity collection and
all its progeny should be stored under returned.
INTERNET-DRAFT WebDAV November 19, 1997

Consistent with the supplied Request-URI." Since submission of an entity
representing a collection would implicitly encode creation previous example, resource
http://www.foo.bar/container/ has two properties defined on it,
http://www.foo.bar/boxschema/bigbox, and
deletion of resources, this specification intentionally does not
define a transmission format for creating
http://www.foo.bar/boxschema/author. The resource
http://www.foo.bar/container/index.html, a collection using PUT.
Instead, member of the MKCOL method is "container"
collection, has only one property defined on it,
http://www.foo.bar/boxschema/bigbox.

8.2. PROPPATCH

The PROPPATCH method processes instructions specified in the request
body to create collections. If a
PUT is invoked set and/or remove properties defined on a collection resource it MUST fail.

When the PUT operation creates a new non-collection resource all
ancestors
identified by Request-URI.

All DAV compliant resources MUST already exist. If all ancestors do not exist, support the PROPPATCH method and
MUST fail with a 409 Conflict status code. For example,
if resource /a/b/c/d.html is to be created process instructions that are specified using the
propertyupdate, set, and /a/b/c/ does not
exist, then remove XML elements of the request DAV schema.
Execution of the directives in this method is, of course, subject to
access control constraints. DAV compliant resources MUST fail.

3.5.3.1 PUT for Non-Collection Resources

A PUT performed on an existing resource replaces support
the GET response
entity setting of arbitrary dead properties.

The request message body of a PROPPATCH method MUST contain at least
one propertyupdate XML element. Instruction processing MUST occur
in the resource, but order instructions are received (i.e., from top to bottom),
and MUST NOT change be performed atomically.

8.2.1. propertyupdate XML element

Name: propertyupdate
Namespace: http://www.ietf.org/standards/dav/
Purpose: To contain a request to alter the value of any dead properties defined on the a
resource. Live
Parent: None
Values= 1*(set | remove)
Description: This XML element is a container for the information
required to modify the properties defined on the resource MAY be recomputed during PUT processing.

3.5.4 DELETE for Collections

When DELETE resource. This XML element
is applied to a collection without internal members multi-valued.

8.2.2. set XML element

Name: set
Namespace: http://www.ietf.org/standards/dav/
Purpose: To set the collection resource, along with its properties, and external
members, MUST be deleted. A DELETE method applied to a
collection resource containing internal member resources DAV properties specified inside the set XML
element.
Parent: propertyupdate
Values= prop
Description: This XML element MUST
fail with contain only a 409 Conflict status code.

3.5.5 DELETE Method for Non-Collection Resources

If prop XML element.
The elements contained by prop specify the DELETE method is issued to a non-collection resource which
is an internal member name and value of
properties that are set on the Request-URI. If a collection, property already
exists then during DELETE
processing a server MUST its value is replaced.
INTERNET-DRAFT WebDAV November 19, 1997

8.2.3. remove XML element

Name: remove
Namespace: http://www.ietf.org/standards/dav/
Purpose: To remove the Request-URI from its parent
collection. A server MAY DAV properties specified inside the remove
XML element.
Parent: propertyupdate
Values= prop
Description: Remove specifies that the URI properties specified in prop
should be removed. Specifying the removal of a deleted resource
from any collections of which the resource property that does
not exist is not an external member.

3.6 COPY Method

3.6.1 Problem Description

Currently, error. All the elements in order prop MUST be empty,
as only the names of properties to create be removed are required.

8.2.4. Response Codes

200 OK - The command succeeded. As there can be a copy mixture of sets
and removes in a resource, body, a 201 Create seems inappropriate.

403 Forbidden - The client, for reasons the client
must GET an entity and then PUT that entity server chooses not to
specify, cannot alter one of the desired
destination. properties.

405 Conflict - The client has provided a value whose semantics are
not appropriate for the property. This requires (1) an entity includes trying to be transmitted set read-
only properties.

413 Request Entity Too Long - If a particular property is too long
to and
from be recorded then a composite XML error will be returned
indicating the offending property.

8.2.5. Example

PROPPATCH /bar.html HTTP/1.1
Host: www.foo.com
Content-Type: text/xml
Content-Length: xxxx

<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" AS = "D"?>
<?namespace href = "http://www.w3.com/standards/z39.50/" AS = "Z"?>
<D:propertyupdate>
<D:set>
<D:prop>
<Z:authors>
<Z:Author>Jim Whitehead</Z:Author>
<Z:Author>Roy Fielding</Z:Author>
</Z:authors>
</D:prop>
</D:set>
<D:remove>
<D:prop><Z:Copyright-Owner/></D:prop>
</D:remove>
</D:propertyupdate>
INTERNET-DRAFT WebDAV November 19, 1997

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

<?XML version="1.0">
<?namespace href="http://www.ietf.org/standards/dav/" AS = "D"?>
<?namespace href="http://www.w3.com/standards/z39.50/" AS = "Z"?>
<D:multistatus>
<D:response>
<D:prop><Z:Authors/></D:prop>
<D:status>HTTP/1.1 420 Method Failure</D:status>
</D:response>
<D:response>
<D:prop><Z:Copyright-Owner/></D:prop>
<D:status>HTTP/1.1 409 Conflict</D:status>
</D:response>
<D:responsedescription> Copyright Owner can not be deleted or
altered.</D:responsedescription>
</D:multistatus>

In this example, the client requests the server and (2) that to set the resource be expressible as an
entity with complete fidelity.

This is problematic because value of
the network traffic involved in
making a copy, http://www.w3.com/standards/z39.50/Authors property, and because there is often no way to fully express
a resource as an entity without a loss of fidelity.

3.6.2 Solution Requirements
remove the property http://www.w3.com/standards/z39.50/Copyright-
Owner. Since the Copyright-Owner property could not be removed, no
property modifications occur. The Method Failure response code for
the Authors property indicates this action would have succeeded if
it were not for the conflict with removing the Copyright-Owner
property.

8.3. MKCOL Method

The solution:
- MUST allow a principal MKCOL method is used to create a copy of a resource
without having to transmit the resource to and from new collection. All DAV
compliant resources MUST support the server.

3.6.3 The MKCOL method.

8.3.1. Request

The COPY method

MKCOL creates a duplicate of new collection resource at the source resource, given location specified by
the Request-URI, in the destination resource, given by Request-URI. If the
Destination header. The Destination header Request-URI exists, then MKCOL must fail.
During MKCOL processing, a server MUST be present. The
exact behavior of the COPY method depends on make the type Request-URI a member
of its parent collection. If no such ancestor exists, the
source resource.

3.6.3.1 COPY for HTTP/1.1 resources method
MUST fail. When the source resource is not MKCOL operation creates a collection, new collection
resource, all ancestors MUST already exist, or the method MUST fail
with a 409 Conflict status code. For example, if a request to
create collection /a/b/c/d/ is made, and neither /a/b/ nor /a/b/c/
exists, the request MUST fail.

When MKCOL is not invoked without a
property, request body, the body newly created
collection has no members.
INTERNET-DRAFT WebDAV November 19, 1997

A MKCOL request message MAY contain a message body. The behavior of the destination resource MUST be octet-for-
octet identical to
a MKCOL request when the body of the source resource. Alterations
to the destination resource do not modify the source resource.
Alterations is present is limited to the source resource do not modify the destination
resource. Thus, all copies are performed "by-value".

All creating
collections, members of a collection, bodies of members and
properties on the source resource MUST be duplicated on the
destination resource, subject to modifying headers, following collections or members. If the
definition for copying properties.

3.6.3.2 COPY for Properties

The following section defines how properties on server receives a resource are
handled during
MKCOL request entity type it does not support or understand it MUST
respond with a COPY operation.
Live properties SHOULD 415 Unsupported Media Type status code. The exact
behavior of MKCOL for various request media types is undefined in
this document, and will be duplicated as identically behaving live
properties at the destination resource. Since they specified in separate documents.

8.3.2. Response Codes

Responses from a MKCOL request are live
properties, the not cacheable, since MKCOL has
non-idempotent semantics.

201 Created - The collection or structured resource was created in
its entirety.

403 Forbidden - This indicates at least one of two conditions: 1)
The server determines does not allow the syntax creation of collections at the given
location in its namespace, and semantics (hence
value) 2) The parent collection of these properties. Properties named by the Enforce-
Live-
Properties header MUST
Request-URI exists but cannot accept members.

405 Method Not Allowed - MKCOL can only be live executed on the destination resource, or
the method MUST fail. If a property is not named by Enforce-
Live-
Properties and
deleted/non-existent resource.

409 Conflict - A collection cannot be copied live, then its value MUST be
duplicated, octet-for-octet, in an identically named, dead
resource on made at the destination resource.

If a property Request-URI until
one or more intermediate collections have been created.

415 Unsupported Media Type- The server does not support the request
type of the body.

419 Insufficient Space on Resource - The resource does not have
sufficient space to record the source already exists on state of the resource and after the overwrite header
execution of this method.

8.3.3. Example

This example creates a collection called /webdisc/xfiles/ on the
server www.server.org.

MKCOL /webdisc/xfiles/ HTTP/1.1
Host: www.server.org

HTTP/1.1 201 Created

8.4. INDEX Method

The INDEX method is set used to TRUE then the property at enumerate the
destination members of a resource.
All DAV compliant resources MUST be overwritten with the property from the
source. If the overwrite header is false and the previous
situation exists then support the COPY INDEX method if they
have members.
INTERNET-DRAFT WebDAV November 19, 1997

8.4.1. The Request

For a collection, INDEX MUST fail with return a 409 Conflict.

3.6.3.3 COPY list of its members. All
WebDAV compliant resources MUST support the text/xml response entity
described below. The INDEX result for Collections

A COPY on a collection causes MAY also return
a new, empty collection resource to
be created at list of the destination members of child collections, to any depth.

Collections that respond to an INDEX method with the same properties as the
source resource. All properties on the source collection a text/xml entity
MUST be
duplicated on the destination collection, subject to modifying
headers, following contain a single multistatus XML element which contains a
response XML element for each member.

A resource that supports INDEX MUST return the definition resourcetype property
for copying each member.

Note that the prop XML element MAY contain additional properties.

8.4.2. Example

INDEX /user/yarong/dav_drafts/ HTTP/1.1
Host: www.microsoft.com

HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: xxx
Last-Modified: Thu, 11 Sep 1997 23:45:12 GMT
ETag: _fooyyybar_

<?XML version="1.0">
<?namespace href = _http://www.ietf.org/standards/dav/_ as = _D_?>
<D:multistatus>
<D:response>
<D:href>http://www.microsoft.com/user/yarong/dav_drafts/
</D:href>
<D:prop>
<D:resourcetype>
<D:collection/>
</D:resourcetype>
</D:prop>
<D:status>HTTP 1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>
http://www.microsoft.com/user/yarong/dav_drafts/base
</D:href>
<D:prop>
<D:resourcetype/>
</D:prop>
<D:status>HTTP 1.1 200 OK</D:status>
</D:response>
</D:multistatus>
INTERNET-DRAFT WebDAV November 19, 1997

8.5. ADDREF Method

The
new ADDREF method is used to add external members to a resource.
All DAV compliant collection resources MUST NOT contain any members, internal or
external.

3.6.3.4 Type Interactions

If the destination resource identifies a property and support the source
resource is not a property, then ADDREF
method. All other DAV compliant resources MAY support the copy SHOULD fail.

If ADDREF
method as appropriate.

8.5.1. The Request

The ADDREF method adds the destination resource identifies a collection and URI specified in the
Overwrite Collection-Member
header is "true," prior as an external member to performing the copy, the
server MUST perform a DELETE operation on collection specified by the collection.

3.6.4 The Response

200 (OK) The source resource was successfully copied to a pre-
existing destination resource.

201 (Created) The source resource was successfully copied.
Request-URI. The
copy operation resulted value in the creation of a new resource.

412 (Precondition Failed) This status code Collection-Member header MUST be returned an
absolute URI meeting the requirements of an external member URI.

It is not an error if the server was unable to maintain URI specified in the liveness Collection-Member
header already exists as an external member of the properties
listed collection.
However, after processing the ADDREF there MUST be only one instance
of the URI in the Enforce-Live-Properties header, or if collection. If the Overwrite
header is false, and URI specified in the state
Collection-Member header already exists as an internal member of the destination
collection, the ADDREF method MUST fail with a 412 Precondition
Failed status code.

8.5.2. Example

ADDREF /~ejw/dav/ HTTP/1.1
Host: www.ics.uci.edu
Collection-Member: http://www.ietf.org/standards/dav/

HTTP/1.1 200 OK

This example adds the URI http://www.ietf.org/standards/dav/ as an
external member resource is
non-null.

417 (Insufficient Space on Resource) - of the collection
http://www.ics.uci.edu/~ejw/dav/.

8.6. DELREF Method

The destination resource
does not have sufficient space DELREF method is used to record remove external members from a
resource. All DAV compliant collection resources MUST support the state of
DELREF method. All other DAV compliant resources MUST support the
resource after
DELREF method only if they support the execution of this ADDREF method.

500 (Server Error)

8.6.1. The resource was Request

The DELREF method removes the URI specified in such a state that it could
not be copied. This may occur if the Destination Collection-Member
header specifies
a resource that is outside from the namespace collection specified by the resource Request-URI.

DELREFing a URI which is able to
interact with.

3.6.5 Examples

3.6.5.1 Overwrite Example

This example shows resource
http://www.ics.uci.edu/~fielding/index.html being copied to the
location http://www.ics.uci.edu/users/f/fielding/index.html. The
contents not a member of the destination resource were overwritten, if non-
null.

COPY /~fielding/index.html collection is not an
error. DELREFing an internal member MUST fail with a 412
Precondition Failed status code.
INTERNET-DRAFT WebDAV November 19, 1997

8.6.2. Example

DELREF /~ejw/dav/ HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html www.ics.udi.edu
Collection-Member: http://www.ietf.org/standards/dav/

HTTP/1.1 200 OK

3.6.5.2 No Overwrite Example

The following

This example shows the same copy operation being
performed, except with removes the Overwrite header set to "false." A
response of 412, Precondition Failed, is returned because URI http://www.ietf.org/standards/dav/, an
external member resource, from the
destination resource has a non-null state.

COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
Overwrite: "false"

HTTP/1.1 412 Precondition Failed

3.7 MOVE Method

3.7.1 Problem Description collection
http://www.ics.uci.edu/~ejw/dav/.

8.7. GET, HEAD for Collections

The move operation on semantics of GET are unchanged when applied to a resource collection,
since GET is defined as, _retrieve whatever information (in the logical equivalent form
of a
copy followed an entity) is identified by a delete, where the actions are performed
atomically. Using RFC 2068 methods only, this procedure could be
performed in several steps. First, the client could issue a Request-URI_ [Fielding et al.,
1997]. GET when applied to retrieve a representation collection MAY return the contents of a
an _index.html_ resource, issue a DELETE to
remove human-readable view of the resource from contents of
the server, then use PUT to place collection, or something else altogether, and hence it is
possible the
resource result of a GET on the server with a new URI. As is collection will bear no
correlation to the case for COPY -
because state of the network traffic involved in making a move, and
because there collection.

Similarly, since the definition of HEAD is often no way to fully express a resource as an
entity GET without a loss response
message body, the semantics of fidelity - server move functionality HEAD are unmodified when applied to
collection resources.

8.8. POST for Collections

Since by definition the actual function performed by POST is
preferable.

With a WEBDAV server, a principal may accomplish this task
determined by
issuing a COPY and then DELETE. Network load decreases, but the server load may still and often depends on the particular
resource, the behavior of POST when applied to collections cannot be significant
meaningfully modified because it is largely undefined. Thus the server must
create a duplicate resource. Were a server
semantics of POST are unmodified when applied to know beforehand
that a principal intended to perform COPY and collection.

8.9. DELETE operations
in succession, it could avoid

8.9.1. DELETE Method for Non-Collection Resources

If the creation DELETE method is issued to a non-collection resource which is
an internal member of a duplicate
resource.

3.7.2 Solution Requirements

The solution:
- Must prevent collection, then during DELETE processing a
server MUST remove the unneeded transfer of entity bodies Request-URI from and
to the server.
- Must prevent its parent collection. A
server MAY remove the unneeded creation URI of copies by a deleted resource from any collections
of which the server.

3.7.3 The Request resource is an external member.

8.9.2. DELETE for Collections
INTERNET-DRAFT WebDAV November 19, 1997

The move operation DELETE method on a resource is the logical equivalent of collection MUST act as if a
copy followed by Depth = Infinity
header was used on it. A client MUST NOT submit a delete, where the actions are performed
atomically. If Depth header on a resource exists at
DELETE on a collection with any value but Infinity.

DELETE instructs that the destination, collection specified in the
destination resource will be DELETEd as a side effect of request-URI,
the MOVE
operation, subject records of its external member resources, and all its internal
member resources, are to the restrictions be deleted.

If any member cannot be deleted then all of the overwrite header.

3.7.4 The Response

200 (OK) - The resource was moved. A successful response must
contain the Content-Location header, set equal member's progeny
MUST NOT be deleted, so as to maintain the URI namespace.

Any headers included with DELETE MUST be applied in
source. This lets caches properly flush any cached entries for
the source. Unfortunately the Content-Location header only allows processing every
resource to be deleted. In this case, a single value so it header of special interest
is not possible for caches unfamiliar with the MOVE Destroy header, which specifies the method to properly clear their caches.

412 (Precondition Failed) This status code MUST be returned if
the server was unable used to maintain
delete all resources in the liveness scope of the properties
listed in DELETE.

When the Enforce-Live-Properties header, or if DELETE method has completed processing it MUST return a
consistent namespace.

The response SHOULD be a Multi-Status response that describes the Overwrite
header is false, and
result of the DELETE on each affected resource.

8.9.2.1. Example

DELETE /container/ HTTP/1.1
Host: www.foo.bar
Destroy: NoUndelete

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

<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" As = "d"?>
<d:multistatus>
<d:response>
<d:href>http://www.foo.bar/container/resource1</d:href>
<d:href>http://www.foo.bar/container/resource2</d:href>
<d:status>HTTP/1.1 200 OK</d:status>
</d:response>
<d:response>
<d:href>http://www.foo.bar/container/</d:href>
<d:status>HTTP/1.1 420 Method Failure</d:status>
</d:response>
<d:response>
<d:href>http://www.foo.bar/container/resource3</d:href>
<d:status>HTTP/1.1 412 Precondition Failed</d:status>
</d:response>
</d:multistatus>
INTERNET-DRAFT WebDAV November 19, 1997

In this example the state of attempt to delete
http://www.foo.bar/container/resource3 failed because the destination resource is
non-null.

501 (Not Implemented) - This may occur if server was
unable to guarantee that resource3 would not be able to be
undeleted. Consequently, the Destination attempt to delete
http://www.foo.bar/container/ also failed, but resource1 and
resource2 were deleted. Even though a Depth header
specifies has not been
included, a resource which is outside its domain depth of control
(e.g., stored on another server) resource and infinity is assumed because the server either
refuses or method is incapable of moving to on a
collection. As this example illustrates, DELETE processing need not
be atomic.

8.10. PUT

8.10.1. PUT for Non-Collection Resources

A PUT performed on an external resource.

502 (Bad Gateway) - This may occur when moving to external
resources and existing resource replaces the destination server refused to accept GET response
entity of the resource.

3.7.5 Examples

3.7.5.1 Overwrite Example

This example shows Properties defined on the resource
http://www.ics.uci.edu/~fielding/index.html being moved to MAY be
recomputed during PUT processing. For example, if a server
recognizes the
location http://www.ics.uci.edu/users/f/fielding/index.html. The
contents content type of the destination resource were overwritten, if non-
null.

MOVE /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html

HTTP/1.1 200 OK
Content-Location:
http://www.ics.uci.edu/users/f/fielding/index.html

3.8 ADDREF Method

3.8.1 Problem Definition

There needs request body, it may be able to
automatically extract information that could be profitably exposed
as properties.

A PUT that would result in the creation of a way to add resource without an external member to a
collection.

3.8.2 Solution Requirements

The solution must:
- allow access control
- allow referencing to URIs of external members
- not require
appropriately scoped parent collection MUST fail with a body

3.8.3 The Request

The ADDREF method adds the URI specified 405 Method
Not Allowed.

8.10.2. PUT for Collections

As defined in the Collection-Member
header as an external member to the collection specified by HTTP/1.1 specification [Fielding et al., 1997],
the
Request-URI. The value in "PUT method requests that the Collection-Member header MUST enclosed entity be an
absolute URI meeting stored under
the requirements supplied Request-URI." Since submission of an external member URI.

It is not an error if the URI specified in the Collection-Member
header already exists as an external member of the collection,
however, after processing ADDREF there MUST be only one instance entity
representing a collection would implicitly encode creation and
deletion of resources, this specification intentionally does not
define a transmission format for creating a collection using PUT.
Instead, the URI in the collection. MKCOL method is defined to create collections. If a
PUT is invoked on a collection resource it MUST fail.

When the URI specified in the
Collection-Member header PUT operation creates a new non-collection resource all
ancestors MUST already exists as an internal member of
the collection, exist. If all ancestors do not exist, the ADDREF
method MUST fail with a 412
Precondition Failed 409 Conflict status code.

3.8.4 Example

ADDREF /~whitehead/dav/ HTTP/1.1
HOST: www.ics.udi.edu
Collection-Member: http://www.ietf.org/standards/dav/

HTTP/1.1 200 OK

3.9 DELREF Method

3.9.1 Problem Definition

There needs For example, if
resource /a/b/c/d.html is to be created and /a/b/c/ does not exist,
then the request must fail.

8.11. COPY Method

The COPY method creates a way duplicate of the specified resource. All
DAV compliant resources MUST support the COPY method.

Support for the COPY method does not guarantee the ability to remove an external member from copy a
collection.

3.9.2 Solution Requirements

The solution must:
- allow access
resource. For example, separate programs may control
- allow referencing to URIs of external members
- resources on
the same server. As a result, it may not require even be possible to copy a body

3.9.3
resource to a location that appears to be on the same server.
INTERNET-DRAFT WebDAV November 19, 1997

8.11.1. The Request

The DELREF COPY method removes creates a duplicate of the URI specified source resource, given by
the Request-URI, in the Collection-
Member destination resource, given by the
Destination header. The Destination header from MUST be present. The
exact behavior of the collection specified by COPY method depends on the Request-URI.

DELREFing a URI which type of the source
resource.

8.11.1.1. COPY for HTTP/1.1 resources

When the source resource is not a member collection the body of the collection is not an
error. DELREFing an internal member
destination resource MUST fail with a 412
Precondition Failed status code.

3.9.4 Example

DELREF /~whitehead/dav/ HTTP/1.1
Host: www.ics.udi.edu
Collection-Member: http://www.ietf.org/standards/dav/

HTTP/1.1 200 OK

3.10 PATCH Method

3.10.1 Problem Definition

At present, if a principal wishes be octet-for-octet identical to the body
of the source resource. Alterations to the destination resource do
not modify a the source resource. Alterations to the source resource
do not modify the destination resource. Thus, all copies are
performed _by-value_.

All properties on the source resource MUST be duplicated on the
destination resource, they must
issue subject to modifying headers, following the
definition for copying properties.

8.11.1.2. COPY for Properties

The following section defines how properties on a GET against resource are
handled during a COPY operation.

Live properties SHOULD be duplicated as identically behaving live
properties at the resource, modify their local copy destination resource. Since they are live
properties, the server determines the syntax and semantics of these
properties. Properties named by the Enforce-Live-Properties header
MUST be live on the destination resource, or the method MUST fail.
If a property is not named by Enforce-Live-Properties and cannot be
copied live, then its value MUST be duplicated, octet-for-octet, in
an identically named, dead property on the
resource, and then issue destination resource.

If a PUT to place the modified resource property on the server. This procedure is inefficient because source already exists on the entire
entity for a destination
resource must be transmitted to and from the server
in order Overwrite header is set to make even small changes. Ideally, "T" then the update entity
transmitted to property at
the server should destination MUST be proportional in size to overwritten with the
modifications.

3.10.2 Solution Requirements

The solution must:
- allow partial modification of a resource without having to
transmit property from the entire modified resource
- allow byte-range patching
- allows extensions so that patches can be done beyond simple
byte-range patching
- allow ranges to be deleted, inserted,
source. If the Overwrite header is "F" and replaced

3.10.3 The Request

The request entity of the PATCH previous situation
exists, then the COPY MUST fail with a 409 Conflict.

8.11.1.3. COPY for Collections

The COPY method contains on a list collection without a Depth header MUST act as
if a Depth = infinity header was included. A client MAY submit a
Depth header on a COPY on a collection with a value of
differences between the resource identified by "0" or
"infinity". DAV compliant servers MUST support the Request-URI "0" and the desired content
"infinity" behaviors.

A COPY of depth infinity instructs that the resource after collection specified in
the PATCH action
has been applied. The list Request-URI, the records of differences is in its external member resources, and
INTERNET-DRAFT WebDAV November 19, 1997

all its internal member resources, are to be copied to a format defined
by location
relative to the media type Destination header.

A COPY of depth "0" only instructs that the entity (e.g., "application/diff") collection, the
properties, and
must include sufficient information its external members, not its internal members, are
to be copied.

Any headers included with a COPY are to be applied in processing
every resource to allow the server be copied.

The exception to
convert this rule is the original version of Destination header. This header
only specifies the resource destination for the Request-URI. When applied to
members of the desired
version. Processing performed by PATCH is atomic, hence all
changes MUST be successfully executed or collection specified in the method fails. PATCH
MUST fail if executed on a non-existent resource; i.e. PATCH does
not create a resource as a side effect.

If request-URI the request appears (at least initially) value of
Destination is to be acceptable, modified to reflect the
server MUST transmit an interim 100 response message after
receiving current location in the empty line terminating
hierarchy. So, if the request headers request-URI is "a" and
continue processing the request. Since the semantics of PATCH
are non-idempotent, responses to this method are not cacheable.

While server support for PATCH destination is optional, if "b"
then when a/c/d is processed it MUST use a server does
support PATCH, destination of b/c/d.

When the COPY method has completed processing it MUST support have created a
consistent namespace at least the text/xml diff format
defined below. Support for the VTML difference format [VTML] destination. Thus if it is
recommended, but not required.

3.10.4 text/xml elements for PATCH possible
to COPY a collection with internal members, the internal members may
still be copied but a collection will have to be created at the
destination to contain them.

The resourceupdate XML element contains response is a set of XML sub-entities Multi-Status response that describe modification operations. The name and meaning describes the result of
these XML elements
the COPY on each affected resource. The response is given below. Processing for the
resource that was to be copied, not the resource that was created as
a result of these directives
MUST be performed in the order encountered within copy. In other words, each entry indicates whether
the XML
document. A directive operates copy on the resource as modified by
all previous directives (executed specified in sequential order). the href succeeded or failed
and why.

The
length of exception to this rule is for errors that occurred on the
destination. For example, if the destination was locked the
response would indicate the destination URL and a 421 Destination
Locked error.

8.11.1.4. Type Interactions

If the destination resource MAY be extended or reduced by identifies a PATCH.

The changes specified by collection and the resourceupdate XML element
Overwrite header is _T_, prior to performing the copy the server
MUST be
executed atomically.

3.10.4.1 ResourceUpdate

Name: http://www.ietf.org/standards/dav/patch/resourceupdate
Purpose: Contains an ordered set of changes perform a DELETE operation on the collection.

8.11.2. Response Codes

200 OK - The source resource was successfully copied to a non-
collection, non-property pre-
existing destination resource.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: Any
Value: *(Insert | Delete | Replace)

3.10.4.2 Insert

Name: http://www.ietf.org/standards/dav/patch/insert
Purpose: Insert the XML element’s contents starting at the
specified octet.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: ResourceUpdate
Value:

201 Created - The insert XML element MUST contain an Octet-Range
XML element that specifies an octet position within source resource was successfully copied. The copy
operation resulted in the body creation of a new resource. A value of "end" specifies

412 Precondition Failed - This status code MUST be returned if the end of
server was unable to maintain the resource.
The body liveness of the insert XML element contains the octets to be
inserted.

Please note that properties listed
INTERNET-DRAFT WebDAV November 19, 1997

in order to protect the white Enforce-Live-Properties header, or if the Overwrite header is
"F", and the state of the destination resource is non-null.

419 Insufficient Space on Resource - The destination resource does
not have sufficient space contained in
this XML element to record the following attribute/value MUST be included
in state of the element: XML-SPACE = "PRESERVE".

3.10.4.3 Delete

Name: http://www.ietf.org/standards/dav/patch/delete
Purpose: Removes resource after
the specified range execution of octets.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: ResourceUpdate
Value: The Delete XML element MUST contain an octet-range
XML element.

Discussion: this method.

421 Destination Locked _ The octets that are deleted are removed, which means
the destination resource is collapsed was locked and
either a valid Lock-Token header was not submitted, or the length of Lock-
Token header identifies a lock held by another principal.

500 Server Error - The resource was in such a state that it could
not be copied. This may occur if the Destination header specifies a
resource that is
decremented by outside the size of namespace the octet range. It resource is not
appropriate able to
interact with.

8.11.3. Overwrite Example

This example shows resource
http://www.ics.uci.edu/~fielding/index.html being copied to replace deleted octets with zeroed-out octets,
since zero is a valid octet value.

3.10.4.4 Replace

Name: http://www.ietf.org/standards/dav/patch/replace
Purpose: Replaces the specified range of octets with the
location http://www.ics.uci.edu/users/f/fielding/index.html. The
contents of the XML element. If the number of octets in destination resource were overwritten, if non-null.

COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html

HTTP/1.1 200 OK

8.11.4. No Overwrite Example

The following example shows the XML

element is different from same copy operation being performed,
except with the number Overwrite header set to _F._ A response of octets specified, 412
Precondition Failed is returned because the
update MUST be rejected.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: ResourceUpdate
Value: The Replace XML element MUST contain an octet-
range XML element. destination resource has
a non-null state.

COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
Overwrite: _F_

HTTP/1.1 412 Precondition Failed

8.11.5. Collection Example

COPY /container/ HTTP/1.1
Host: www.foo.bar
Destination: http://www.foo.bar/othercontainer/
Enforce-Live-Properties: *
Depth: Infinity
INTERNET-DRAFT WebDAV November 19, 1997

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

<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" As = "d"?>
<d:multistatus>
<d:response>
<d:href>http://www.foo.bar/othercontainer/resource1</d:href>
<d:href>http://www.foo.bar/othercontainer/resource2</d:href>
<d:href>http://www.foo.bar/othercontainer/</d:href>
<d:href>http://www.foo.bar/othercontainer/R2/D2</d:href>
<d:status>HTTP/1.1 201 Created</d:status>
</d:response>
<d:response>
<d:href>http://www.foo.bar/othercontainer/R2/</d:href>
<d:status>HTTP/1.1 412 Precondition Failed</d:status>
</d:response>
</d:multistatus>

The contents of the entity are Depth header is unnecessary as the replacement
octets.

Please note that in order default behavior of COPY on a
collection is to protect the white space contained in
this XML element the following attribute/value MUST be included
in the element: XML-SPACE = "PRESERVE".

3.10.4.5 Octet-Range Attribute

Name: http://www.ietf.org/standards/dav/patch/octet-
range
Purpose: Specifies act as if a range "Depth: Infinity" header had been
submitted. In this example most of octets that the enclosing property
effects.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: Insert, Delete, Replace
Value: number ["-" (number | "end")]
Number = 1*Digit

Description: Octet numbering begins resources, along with 0. If the octet contains
a single number then
collection, were copied successfully. However the operation is collection R2
failed, most likely due to begin a problem with enforcing live properties.
R2's member D2 was successfully copied. As a result a collection
was created at that octet and www.foo.bar/othercontainer/R2 to continue for contain D2.

8.12. MOVE Method

The move operation on a length specified by the operation. In resource is the case logical equivalent of a copy
followed by a delete, this would mean where the actions are performed atomically.
All DAV compliant resources MUST support the MOVE method.

However, support for the MOVE method does not guarantee the ability
to delete move a single octet. In the
case of an insert this would mean resource to begin the insertion at a particular destination. For example,
separate programs may actually control different sets of resources
on the
specified octet and same server. Therefore, it may not even be possible to move
a resource within a namespace that appears to belong to continue for the length of same
server.

8.12.1. The Request

If a resource exists at the included
value, extending destination, the destination resource if necessary. In
will be DELETEd as a side effect of the case MOVE operation, subject to
the restrictions of
replace, the replace begins at Overwrite header.

8.12.2. MOVE for Collections

MOVE instructs that the collection specified octet in the Request-URI, the
records of its external member resources, and overwrites all that follow its internal
INTERNET-DRAFT WebDAV November 19, 1997

member resources, are to be moved to a location relative to the length of the included value.

3.10.5 The Response

200 (OK) -
Destination header.

The request entity body MOVE method on a collection MUST act as if a Depth "infinity"
header was processed without error,
resulting used on it. A client MUST NOT submit a Depth header on a
MOVE on a collection with any value but "infinity".

Any headers included with MOVE are to be applied in an update processing every
resource to be moved.

The exception to this rule is the state Destination header. The behavior
of this header is the resource.

409 (Conflict) - If the update information in the request message
body does not make sense same as given for COPY on collections.

When the current state of the resource
(e.g., an instruction to delete MOVE method has completed processing it MUST have created a non-existent line), this status
code MAY be returned.

415 (Unsupported Media Type) - The server does not support
consistent namespace on both the
content type of source and destination, creating
collections at the update instructions source or destination as necessary.

As specified in the request message
body.

416 (Unprocessable Entity) - A new status code. definition of MOVE, a MOVE of a collection over
another collection causes the destination collection and all its
members to be deleted.

The server
understands response is a Multi-Status response that describes the content type result of
the request entity, but was
unable to process the contained instructions.

417 (Insufficient Space MOVE on Resource) - each effected resource. The response is given for the
resource does not have
sufficient space that was to record the state of be moved, not the resource after the
execution of this method.

3.10.6 Examples

3.10.6.1 HTML file modification

The following example shows that was created as
a modification result of the title and
contents of move. In other words, each entry indicates whether
the move on the HTML resource http://www.example.org/hello.html.

Before:
<HTML>
<HEAD>
<TITLE>Hello world HTML page</TITLE>
</HEAD>
<BODY>
Hello, world!
</BODY>
</HTML>
PATCH Request: Response:
PATCH hello.html HTTP/1.1
Host: www.example.org
Content-Type: text/xml
Content-Length: xxx

HTTP/1.1 100 Continue
<?XML:Namespace specified in the href =
Shttp://www.ietf.org/standards/dav/patch/" AS = "D"/>
<D:ResourceUpdate>
<Replace XML-SPACE = "PRESERVE"><octet-range>14</octet-
range>&003CTITLE&003ENew Title&003C/TITLE&003E</Replace>
<Delete><octet-range>38-50</Delete>
<Insert XML-SPACE = "PRESERVE"><octet-range>86</>&
003CP&003ENew paragraph&003C/P&003E</Insert>
</D:ResourceUpdate>
HTTP/1.1 succeeded or failed
and why.

The exception to this rule is for errors that occurred on the
destination. For example, if the destination was locked the
response would indicate the destination URL and a 421 Destination
Locked error.

8.12.3. Response Codes

200 OK
After:
<HTML>
<HEAD>
<TITLE>New Title</TITLE>
</HEAD>
<BODY>
Hello, world!
New paragraph
</BODY>
</HTML>

3.11 Headers

3.11.1 Destination Header - The Destination header specifies move operation was successful.

409 Conflict _ The MOVE was attempted on a destination resource for
methods such as collection with members.
While the COPY and MOVE, which take two URIs as parameters.
Destination= "Destination" ":" URI

3.11.2 Enforce-Live-Properties Header

The Enforce-Live-Properties header specifies properties that part of this operation could succeed the DELETE could
not. Therefore the MOVE MUST fail.

412 Precondition Failed - This status code MUST be "live" after they are copied (moved) to the destination
resource of a copy (or move). If returned if the value "*" is given for
server was unable to maintain the liveness of the
header, then it designates all live properties on listed
in the source
resource. If Enforce-Live-Properties header, or if the value Overwrite header is "Omit" then
"F", and the server MUST NOT
duplicate on state of the destination resource any properties that are
defined on is non-null.

421 Destination Locked - The destination resource was locked and
either a valid Lock-Token header was not submitted, or the source resource. If this Lock-
Token header identifies a lock held by another principal.

502 Bad Gateway - This may occur when the destination is not included
then

o
n another
server and the destination server is expected refuses to act as defined by the default
property handling behavior of accept the associated method.

EnforceLiveProperties = "Enforce-Live-Properties" ":" ("*" |
"Omit" | 1#(Property-Name))
Property-Name = "<" URI ">"

3.11.3 Overwrite Header

The resource
INTERNET-DRAFT WebDAV November 19, 1997

8.12.4. Overwrite header specifies whether the server should
overwrite Example

This example shows resource
http://www.ics.uci.edu/~fielding/index.html being moved to the state
location http://www.ics.uci.edu/users/f/fielding/index.html. The
contents of a non-null the destination resource during were overwritten, if non-null.

MOVE /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html

HTTP/1.1 200 OK

8.12.5. Collection Example

MOVE /container/ HTTP/1.1
Host: www.foo.bar
Destination: http://www.foo.bar/othercontainer/
Enforce-Live-Properties: *
Overwrite: False
Lock-Token: <OpaqueLockToken:xxxx> <OpaqueLockToken:xxxx>

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

<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" As = "D"?>
<d:multistatus>
<d:response>
<d:href>http://www.foo.bar/container/resource1</d:href>
<d:href>http://www.foo.bar/container/resource2</d:href>
<d:href>http://www.foo.bar/container/</d:href>
<d:href>http://www.foo.bar/container/C2/R2</d:href>
<d:status>HTTP/1.1 201 Created</d:status>
</d:response>
<d:response>
<d:href>http://www.foo.bar/container/C2</d:href>
<d:status>HTTP/1.1 420 Method Failure</d:status>
<d:response>
<d:href>http://www.foo.bar/othercontainer/C2</d:href>
<d:status>HTTP/1.1 409 Conflict</d:status>
</d:response>
</d:multistatus>

In this example the client has submitted a
COPY or MOVE. A value number of "false" states that the server MUST NOT
perform lock tokens
with the COPY or MOVE operation if request. A lock token will need to be submitted for every
resource, both source and destination, anywhere in the state scope of the
INTERNET-DRAFT WebDAV November 19, 1997

method, that is locked. In this case the proper lock token was not
submitted for the destination http://www.foo.bar/othercontainer/C2.
This means that the resource is non-null. By default, continer/c2 could not be moved,
although its child container/C2/R2 could be moved.

8.13. LOCK Method

The following sections describe the value of
Overwrite LOCK method, which is "true," and a client MAY omit this header from used to
take out a
request when its value is "true." While lock of any access type. These sections on the Overwrite header
appears LOCK
method describe only those semantics that are specific to duplicate the functionality LOCK
method and are independent of the If-Match: * header access type of HTTP/1.1, If-Match applies only to the Request-URI, and not to lock being
requested. Once the Destination general LOCK method has been described,
subsequent sections describe the semantics of a COPY or MOVE.

Overwrite = "Overwrite" ":" ("true" | "false")

If there is a conflict the "write" access
type, and the Overwrite write lock.

8.13.1. Operation

A LOCK method invocation creates the lock specified by the Lock-Info
header equals "true", or
is absent and thus defaults to "true", then on the Request-URI. Lock method MUST fail
with requests SHOULD have a 409 Conflict.

3.11.4 Destroy Header

When deleting XML
request body which contains an Owner XML element for this lock
request. The LOCK request MAY have a resource the client often wishes Timeout header.

A successful response to specify
exactly what sort a lock invocation MUST include Lock-Token
and Timeout headers. Clients MUST assume that locks may arbitrarily
disappear at any time, regardless of delete is being enacted. The Destroy header,
used with the Mandatory header, allows the client to specify value given in the
end result they desire. Timeout
header. The Destroy Timeout header is specified as
follows:

The Undelete token requests that, only indicates the behavior of the
server if possible, "extraordinary" circumstances do not occur. For example,
an administrator may remove a lock at any time or the resource
should be left system may
crash in a state such a way that it can be undeleted. The
server is not required to honor this request.

The NoUndelete token requests that loses the resource record of the lock's
existence. The response MUST NOT be left also contain the value of the
lockdiscovery property in a state such that it can be undeleted. prop XML element.

8.13.2. The VersionDestroy token includes Effect of Locks on Properties and Collections

By default the functionality scope of a lock is the
NoUndelete token entire state of the resource,
including its body and extends it to include having associated properties. As a result, a lock
on a resource also locks the server
remove all versioning references resource's properties, and a lock on a
property may lock a property's resource or may restrict the ability
to lock the resource that it has
control over.

DestroyHeader = "Destroy" ":" #Choices

Choices = "VersionDestroy" | "NoUndelete" | "Undelete" | token
|"<" URI ">" ; property's resource. Only a single lock token extension MUST NOT be
used unless it is
specified in when a RFC16, otherwise lock extends to cover both a URI MUST be used for
extensions.

3.11.5 Collection-Member Header resource and its
properties. Note that certain lock types MAY override this
behavior.

For collections, a lock also affects the ability to add or remove
members. The Collection-Member header specifies nature of the URI effect depends upon the type of an external
resource to be added/deleted to/from access
control involved.

8.13.3. Locking Replicated Resources

Some servers automatically replicate resources across multiple URLs.
In such a collection.

CollectionMember = "Collection-Member" ":" URI

3.12 Links

3.12.1 Source Link Property Type

Name: http://www.ietf.org/standards/dav/link/source
Purpose: The destination circumstance the server MAY only accept a lock on one of
INTERNET-DRAFT WebDAV November 19, 1997

the source link identifies URLs if the
resource server can guarantee that contains the unprocessed source of lock will be honored
across all the link’s
source.

Schema: http://www.ietf.org/standards/dav/link/
Parent: Any
Value: An XML document with zero or more link XML
elements.

Discussion: URLs.

8.13.4. Locking Multiple Resources

The source LOCK method supports locking multiple resources simultaneously
by allowing for the listing of several URIs in the link (src) is typically LOCK request.
These URIs, in addition to the URI Request-URI, are then to be locked as
a result of the output resource on which LOCK method's invocation. When multiple resources
are specified the link is defined, and there is
typically LOCK method only one destination (dst) succeeds if all specified
resources are successfully locked.

The Lock-Tree option of the link, which is the
URI where the unprocessed source of lock request specifies that the resource may be accessed.
When more than one link destination exists, this specification
asserts no policy on ordering.

4 State Tokens

4.1 Overview

4.1.1 Problem Description

There
and all its internal children (including internal collections, and
their internal members) are times when a principal will want to predicate
successful execution of a method on the current state of a
resource. While HTTP/1.1 provides a be locked. This is another mechanism
by which a request for conditional
execution of methods using entity tags via the "If-Match" and
"If-None-Match" headers, the mechanism is not sufficiently
extensibleto express conditional statements involving more
generic state indicators, such as a lock tokens.

The fundamental issue with entity tags is that they on multiple resources can only be
generated by a resource. However there are times when a client
will want to
specified.

Currently existing locks can not be able extended to share state tokens between cover more or less
resources,
potentially on different servers, as well as be able to generate
certain types and any request to expand or contract the number of
resources in a lock tokens without first having to communicate MUST fail with a server.

For example, a principal may wish to require that resource B have
a certain state in order 409 Conflict status code. So,
for a method to successfully execute on example, if resource A. If A is exclusively write locked and then the client submits an e-tag from resource B
same principal asks to
resource exclusively write lock resources A, then A has no way of knowing that B, and C,
the e-tag request will fail as A is meant
to describe resource B.

Another example occurs when a principal wishes to predicate already locked and the lock can not be
extended.

A successful completion of result will return a method on single lock token which represents
all the absence of any locks on
a resource. It is not sufficient to submit resources that have been locked. If an "If-None-Match: *"
as UNLOCK is executed
on this refers to the existence of an entity, not of a lock.

This draft defines token, all associated resources are unlocked.

If the term "state token" as an identifier for lock cannot be granted to all resources, a
state of 409 Conflict
status code MUST be returned with a resource. The sections below define requirements for
state tokens and provide response entity body containing
a state token syntax, along with two
new headers multistatus XML element describing which can accept resource(s) prevented the new state token syntax.

4.1.2 Solution Requirements

4.1.2.1 Syntax

Self-Describing. A state token must be self describing such that
upon inspecting
lock from being granted.

8.13.5. Interaction with other Methods

The interaction of a state token it LOCK with various methods is possible to determine what
sort dependent upon the
lock type. However, independent of lock type, a successful DELETE
of state token it is, what resource(s) it applies to, and
what state it represents.

This self-describing nature allows servers a resource MUST cause all of its locks to accept tokens from
other servers and potentially be able to coordinate state

information cross resource and cross site through standardized
protocols. For example, removed.

8.13.6. Lock Compatibility Table

The table below describes the execution of behavior that occurs when a lock
request is made on resource A
can a resource.

Current lock state/ Shared Lock Exclusive
Lock request Lock
None True True
Shared Lock True False
Exclusive Lock False False*
INTERNET-DRAFT WebDAV November 19, 1997

Legend: True = lock MAY be predicated on granted. False = lock MUST NOT be
granted. *=if the principal requesting the lock is the owner of the
lock, the lock MAY be regranted.

The current lock state of a resource B, where A is given in the leftmost
column, and B lock requests are
potentially on different servers.

Client Generable. The state token syntax must allow, when
appropriate, for clients to generate a state token without having listed in the first communicated with row. The
intersection of a server.

One drawback row and column gives the result of entity tags a lock request.
For example, if a shared lock is that they are set held on a resource, and an
exclusive lock is requested, the table entry is _false_, indicating
the lock must not be granted.

If an exclusive or shared lock is re-requested by the server,
and there principal who
owns the lock, the lock MUST be regranted. If the lock is no interoperable algorithm
regranted, the same lock token that was previously issued MUST be
returned.

8.13.7. Owner XML Element

Name: owner
Namespace: http://www.ietf.org/standards/dav/
Purpose: Provide information about the principal taking out a
lock.
Parent: Any
Values: XML Elements
Descripton: The Owner XML element provides information sufficient
for calculating an entity
tag. Consequently, either directly contacting a client cannot generate an entity tag from principal (such as a
particular state telephone
number or Email URI), or for discovering the principal (such as the
URL of a resource. However, a state token which
encodes an MD5 state hash could be calculated by homepage) who owns a client based
on lock.

8.13.8. Lock Response

A successful lock response MUST contain a client-held state of Lock-Token response
header, a resource, Timeout header and then submitted to a
server prop XML element in a conditional method invocation.

Another potential use for client generable state tokens the response body
which contains the value of the lockdiscovery property.

8.13.9. Response Codes

409 Conflict - The resource is for a
client to generate lock tokens with wild card fields, and hence
be able to express conditionals such as: "only execute this GET
if there are no write locks locked, so the method has been
rejected.

412 Precondition Failed - The included Lock-Token was not
enforceable on this resource."

4.1.2.2 Conditonals

Universal. A solution must be applicable to all requests.
Positive and Negative. Conditional expressions must allow for resource or the
expression of both positive and negative state requirements.

4.2 State Token Syntax
State tokens are URLs employing server could not satisfy the following syntax:
State-Token = "StateToken:" Type ":" Resources ":" State-Info
Type = "Type" "=" Caret-encoded-URL
Resources = "Res" "=" Caret-encoded-URL
Caret-encoded-URL = "^" Resource "^"
Resource
request in the Lock-Info header.

8.13.10. Example - Simple Lock Request

LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Lock-Info: LockType=Write LockScope=Exclusive
Timeout: Infinite; Second-4100000000
Content-Type: text/xml
INTERNET-DRAFT WebDAV November 19, 1997

Content-Length: xyz

<?XML version="1.0">
<?namespace href="http://www.ietf.org/standards/dav/" AS = <A URI where all "^" characters are escaped>
State-Info "D"?>
<D:owner>
<D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
</D:owner>

HTTP/1.1 200 OK
Lock-Token: opaquelocktoken:xyz122393481230912asdfa09s8df09s7df
Timeout: Second-604800
Content-Type: text/xml
Content-Length: xxxxx

<?XML version="1.0">
<?namespace href ="http://www.ietf.org/standards/dav/" AS = *(uchar | reserved) ; uchar, reserved defined
section 3.2.1 "D"?>
<D:prop>
<D:lockdiscovery>
<D:activelock>
<D:locktype>write</D:locktype>
<D:lockscope>exclusive</D:lockscope>
<D:addlocks/>
<D:owner>
<D:href>
http://www.ics.uci.edu/~ejw/contact.html
</D:href>
</D:owner>
<D:timeout>Second-604800</D:timeout>
<D:locktoken>
<D:href>
opaquelocktoken:xyz122393481230912asdfa09s8df09s7df
</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>

This example shows the successful creation of RFC 2068

This proposal has created a new URL scheme for state tokens
because a state token names a network an exclusive write
lock on resource using its normal
name, which is typically state-invariant, along with additional
information that specifies a particular state of the resource.
Encoding the state
http://webdav.sb.aol.com/workspace/webdav/proposal.doc. The
resource http://www.ics.uci.edu/~ejw/contact.html contains contact
information into for the native URL scheme owner of the
network resource was not felt to be safe, since freedom from name
space collisions could not be guaranteed. If lock. The server has an activity-

based timeout policy in place on this proposal is
accepted, resource, which causes the StateToken URL scheme will need
lock to automatically be defined and
registered with IANA.

State Token URLs begin with the URL scheme name "StateToken"
rather than the name of removed after 1 week (604800 seconds). The
response has a Lock-Token header that gives the particular state lock token type they
represent in order to make the URL self describing. Thus it is
possible to examine that
uniquely identifies the URL and know, at lock created by this lock request.

8.13.11. Example - Multi-Resource Lock Request

LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
INTERNET-DRAFT WebDAV November 19, 1997

Lock-Info: LockType=Write LockScope=Exclusive
Addlocks=<http://webdav.sb.aol.com/workspace/><http://foo.bar/blah>
Timeout: Infinite, Second-4100000000

<?XML version="1.0">
<?namespace href="http://www.ietf.org/standards/dav/" AS = "D"?>
<D:href>http://www.ics.uci.edu/~ejw/contact.html<D:href>

HTTP/1.1 409 Conflict
Content-Type: text/xml
Content-Length: xxxxx

<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" As = "D"?>
<D:multistatus>
<D:response>
<D:href>
http://webdav.sb.aol.com/workspace/webdav/proposal.doc
</D:href>
<D:href>
http://webdav.sb.aol.com/workspace/webdav/
</D:href>
<D:status>HTTP/1.1 202 Accepted</D:status>
</D:response>
<D:response>
<D:href>http://foo.bar/blah</D:href>
<D:status>HTTP/1.1 403 Forbidden</D:status>
</D:response>
</D:multistatus>

This example shows a minimum, request for an exclusive write lock on three
resources, http://webdav.sb.aol.com/workspace/webdav/proposal.doc,
http://webdav.sb.aol.com/workspace/, and http://foo.bar/blah. In
this request, the client has specified that it is desires an infinite
length lock, if available, otherwise a
state token.

Labeled name/value pairs are used within the token to allow new
fields to be added. Processors timeout of state tokens MUST be prepared
to accept the fields in whatever order they are present and MUST
ignore any fields they do not understand. 4.1 billion
seconds, if available. The "Type" Owner header field specifies the type of the state web
address for contact information
encoded in the state token. A URL is used in order to avoid
namespace collisions.

The "Res" field identifies the resource for which the state token

specifies a particular state. Since commas and spaces are
acceptable URL characters, a caret is used to delimit a URL.
Since a caret is an acceptable URL character, any instances of it
must be escaped using principal taking out the % escape convention.

The State-Info production is expanded upon in descriptions of
specific state token types, and is intended to contain
lock.

This lock request has failed, because the state
description information server rejected the lock
request for a particular state token.

4.3 State Token Conditional Headers

4.3.1 If-State-Match

If-State-Match = "If-State-Match" ":" ("AND" | "OR") 1#("<"
State-Token ">") http://foo.bar/blah. The If-State-Match header is intended to have similar
functionality to 409 Conflict status code
indicates that the If-Match header defined in section 14.25 of
RFC 2068.

If server was unable to satisfy the AND keyword request because
there is used and all of the state tokens identify a conflict between the state of the resource, then the server MAY perform resources and the
requested method. If
operation named in the OR keyword is used and any of request. Within the state
tokens identifies multistatus, the current state of 202
Accepted status code indicates that the resource, then server
MAY perform lock method was accepted by
the requested method. If neither of resources, and would have been completed if all resources named
in the keyword
requirements is met, request were able to be locked. The 403 Forbidden status
code indicates that the server MUST NOT perform the requested
method, and MUST return a 412 (Precondition Failed) response.

4.3.2 If-None-State-Match

If-None-State-Match = "If-None-State-Match" ":" 1#("<" State-
Token ">") does not allow lock requests on this
resource.

8.14. UNLOCK Method
INTERNET-DRAFT WebDAV November 19, 1997

The If-None-State-Match header is intended to have similar
functionality to UNLOCK method removes the If-None-Match header defined lock identified by the lock token in section
14.26 of RFC 2068.

If any of
the state tokens identifies Lock-Token header from the current state of Request-URI, and all other resources
included in the
resource, lock.

Any DAV compliant resource which supports the server LOCK method MUST NOT perform
support the requested UNLOCK method.
Instead, if

8.14.1. Example

UNLOCK /workspace/webdav/info.doc HTTP/1.1
Host: webdav.sb.aol.com
Lock-Token:opaquelocktoken:123AbcEfg1284h23h2

HTTP/1.1 200 OK

In this example, the request method was GET, HEAD, INDEX, or GETMETA, lock identified by the server SHOULD respond with a 304 (Not Modified) response,
including lock token
"opaquelocktoken:123AbcEfg1284h23h2" is successfully removed from
the cache-related entity-header fields (particularly
ETag) of resource http://webdav.sb.aol.com/workspace/webdav/info.doc. If
this lock included more than just one resource, the current state lock was removed
from those resources as well.

8.15. PATCH Method

The PATCH method is used to modify parts of the resource. For all other
request methods, entity returned in
the server MUST respond with response to a status of 412
(Precondition Failed).

If none of the state tokens identifies GET method. DAV compliant resources MAY support
the current state PATCH method.

8.15.1. The Request

The request entity of the
resource, the server MAY perform PATCH method contains a list of
differences between the requested method.

Note that resource identified by the "AND" Request-URI and "OR" keywords specified with the If-
State-Match header are intentionally not defined for If-None-
State-Match, because this functionality is not required.

4.4 State Token Header

State-Token-Header = "State-Token" ":" 1#("<" State-Token ">")
The State Token header is intended to have similar functionality
to
the etag header defined in section 14.20 desired content of RFC 2068. the resource after the PATCH action has been
applied. The
purpose list of the tag differences is to return state tokens defined on a

resource in a response. The contents format defined by the
media type of the state-token are not
guaranteed to be exhaustive entity (e.g., "application/diff") and are generally used must include
sufficient information to return a
new state token that has been defined as allow the result server to convert the original
version of a method.
For example, if a LOCK method were the resource to the desired version. Processing
performed by PATCH is atomic. Hence all changes MUST be
successfully executed or the method fails. PATCH MUST fail if
executed on a non-existent resource; i.e., PATCH does not create a
resource as a side effect.

If the request appears (at least initially) to be acceptable, the
server MUST transmit an interim 100 response would include a state token header with message after receiving
the
lock state token included.

4.5 E-Tags
E-tags have already been deployed using empty line terminating the If-Match request headers and If-None-
Match headers. Introducing two mechanisms to express e-tags
would only confuse matters, therefore e-tags should continue to
be expressed using quoted strings and
processing the If-Match and If-None-
Match headers.

5 Locking

5.1 Locking: Introduction

Locking is used to arbitrate access request. Since the semantics of PATCH are non-
idempotent, responses to this method are not cacheable.

While server support for PATCH is optional, if a resource amongst
principals that have equal access rights to that resource.

This specification allows locks to vary over two parameters, server does support
PATCH, it MUST support at least the
number text/xml diff format defined
INTERNET-DRAFT WebDAV November 19, 1997

below. Support for the VTML difference format [VTML] is
recommended, but not required.

8.15.2. text/xml elements for PATCH

The resourceupdate XML element contains a set of principals involved XML sub-entities
that describe modification operations. The name and the type meaning of access to
these XML elements are given below. Processing of these directives
MUST be
granted. Furthermore, this document only provides performed in the definition
of locking for one access type, write. However, order encountered within the syntax is
extensible, and allows XML document.
A directive operates on the specification of other access types.

5.1.1 Exclusive Vs. Shared Locks resource as modified by all previous
directives (executed in sequential order). The most basic form length of lock is an exclusive lock. This is a lock
where the access right in question is only granted to
resource MAY be extended or reduced by a single
principal. PATCH.

The need for this arbitration results from a desire to
avoid having to constantly merge results. In fact, many users so
dislike having to merge that they would rather serialize their
access to a resource rather than have to constantly perform
merges.

However, there are times when changes specified by the goal of a lock is not to
exclude others from exercising resourceupdate XML element MUST be
executed atomically.

8.15.2.1. resourceupdate XML Element

Name: resourceupdate
Namespace: http://www.ietf.org/standards/dav/patch/
Purpose: Contains an access right but rather to
provide a mechanism for principals to indicate that they intend
to exercise their access right. Shared locks are provided for
this case. A shared lock allows multiple principals ordered set of changes to receive a
lock, hence any principal with appropriate access can get non-collection,
non-property resource.
Parent: None
Value= *(insert | delete | replace)

8.15.2.2. insert XML Element

Name: insert
Namespace: http://www.ietf.org/standards/dav/patch/
Purpose: Insert the
lock.

With shared locks there are two trust sets XML element's contents starting at the
specified octet.
Parent: resourceupdate
Value: The insert XML element MUST contain an octet-range XML
attribute that affect specifies an octet position within the body of a
resource. A value of _end_ specifies the end of the resource. The first trust set is created by access permissions.
Principals who are trusted, for example, may have permission to
write
body of the resource, those who are not, don't. Among those who
have access permission insert XML element contains the octets to write be inserted.

Please note that in order to protect the resource, white space contained in
this XML element the set following attribute/value MUST be included in
the element: XML-SPACE = "PRESERVE". This attribute is defined in
the XML specification [Bray, Sperberg-McQueen, 1997].

8.15.2.3. delete XML Element

Name: delete
Namespace: http://www.ietf.org/standards/dav/patch/
Purpose: Removes the specified range of
principals who have taken out a shared lock also must trust each
other, creating a (typically) smaller trust set within octets.
Parent: resourceupdate
Value: The delete XML element MUST contain an octet-range XML
attribute.
INTERNET-DRAFT WebDAV November 19, 1997

Discussion: The octets that are deleted are removed, which means the access
permission write set.

Starting with every possible principal on
resource is collapsed and the Internet, in most
situations length of the vast majority resource is decremented
by the size of these principals will the octet range. It is not have
write access appropriate to replace
deleted octets with zeroed-out octets, since zero is a given resource. Of the small number who do
have write access, some principals may decide to guarantee their
edits are free from overwrite conflicts by using exclusive write
locks. Others may decide they trust their collaborators (the
potential set valid octet
value.

8.15.2.4. replace XML Element

Name: replace
Namespace: http://www.ietf.org/standards/dav/patch/
Purpose: Replaces the specified range of collaborators being octets with the set contents
of principals who
have write permission) and use a shared lock, which informs their

collaborators that a principal is potentially working on the
resource.

The WebDAV extensions to HTTP do not need to provide all XML element. If the number of octets in the
communications paths necessary for principals to coordinate their
activities. When using shared locks, principals may use any out XML element is
different from the number of band communication channel to coordinate their work (e.g.,
face-to-face interaction, written notes, post-it notes on octets specified, the
screen, telephone conversation, email, etc.) update MUST be
rejected.
Parent: resourceupdate
Value: The intent replace XML element MUST contain an octet-range XML
attribute. The contents of a
shared lock is the entity are the replacement octets.

Please note that in order to let collaborators know who else protect the white space contained in
this XML element the following attribute/value MUST be included in
the element: XML-SPACE = "PRESERVE"
.

This attribute is potentially
working on defined in the
XML specification [Bray, Sperberg-McQueen, 1997].

8.15.2.5. octet-range Attribute

Name: octet-range
Namespace: http://www.ietf.org/standards/dav/patch/
Purpose: Specifies a resource.

Shared locks are included because experience from web distributed
authoring systems has indicated range of octets that exclusive write locks are
often too rigid. An exclusive write lock the enclosing property
affects.
Parent: insert | delete | replace
Value: number [_-_ (number | _end_)]
Number = 1*Digit

Description: Octet numbering begins with 0. If the octet contains a
single number then the operation is used to enforce begin at that octet and to
continue for a length specified by the operation. In the case of a
delete, this would mean to delete a
particular editing process: take out exclusive write lock, read single octet. In the resource, perform edits, write case of an
insert this would mean to begin the resource, release insertion at the
lock. What happens if specified octet
and to continue for the lock isn't released? While length of the time-
out mechanism provides one solution, included value, extending the
resource if you need to force necessary. In the
release case of a lock immediately, it doesn't help much. Granted, an
administrator can release replace, the lock for you, but this could become
a significant burden for large sites. In addition there is replace begins
at the
problem specified octet and overwrites all that an administrator may not be immediately available.

Despite their potential problems, exclusive write locks are
extremely useful, since often a guarantee follow to the length
of freedom from
overwrite conflicts is what is needed. the included value.

8.15.3. Response Codes

200 OK - The tradeoff described request entity body was processed without error,
resulting in
this specification is an update to provide exclusive write locks, but also the state of the resource.

409 Conflict - If the update information in the request message body
does not make sense given the current state of the resource (e.g.,
an instruction to provide delete a less strict mechanism non-existent line), this status code MAY
be returned.
INTERNET-DRAFT WebDAV November 19, 1997

415 Unsupported Media Type - The server does not support the content
type of the update instructions in the form request message body.

418 Unprocessable Entity - The entity body submitted with the PATCH
was not understood by the resource.

419 Insufficient Space on Resource - The resource does not have
sufficient space to record the state of shared locks
which can be used by the resource after the
execution of this method.

8.15.4. HTML file modification Example

The following example shows a set modification of people who trust each other the title and who
have access to a communications channel external to HTTP which
can be used to negotiate writing to contents
of the resource.

5.1.2 Required Support

A HTML resource http://www.example.org/hello.html.

Before:
<HTML>
<HEAD>
<TITLE>Hello world HTML page</TITLE>
</HEAD>
<BODY>
Hello, world!
</BODY>
</HTML>

PATCH Request: Response:

PATCH hello.html HTTP/1.1
Host: www.example.org
Content-Type: text/xml
Content-Length: xxx

HTTP/1.1 100 Continue

<?XML version="1.0">
<?namespace href = _http://www.ietf.org/standards/dav/patch/_ AS =
_D_?>
<D:resourceupdate>
<D:replace XML-SPACE = "PRESERVE">
<D:octet-range>14</D:octet-range>&003CTITLE&003ENew
Title&003C/TITLE&003E</D:replace>
<D:delete><D:octet-range>38-50</D:octet-range></D:delete>
<D:insert XML-SPACE = "PRESERVE"><D:octet-range>86</D:octet-
range>&003CP&003ENew paragraph&003C/P&003E</D:insert>
</D:resourceupdate>

HTTP/1.1 200 OK

After:
<HTML>
INTERNET-DRAFT WebDAV compliant server November 19, 1997

<HEAD>
<TITLE>New Title</TITLE>
</HEAD>
<BODY>
Hello, world!
New paragraph
</BODY>
</HTML>

9. HTTP Headers for Distributed Authoring

9.1. Collection-Member Header

CollectionMember = "Collection-Member" ":" URI ; URI is not required to support locking defined in
any form. If the server does support locking it may choose to
support any combination
section 3.2.1 of exclusive and shared locks for any
access types. [Fielding et al., 1997]

The reason for this flexibility is that server implementers have
said that they are willing to accept minimum requirements on all
services but locking. Locking policy strikes to Collection-Member header specifies the very heart URI of
their an external
resource management and versioning systems and they require
control over what sort of locking will to be made available. For
example, some systems only support shared write locks while
others only provide support for exclusive write locks while yet
others use no locking at all. As each system is sufficiently
different added/deleted to/from a collection.

9.2. DAV Header

DAV = "DAV" ":" ("1" | "2" | extend)

This header indicates that the resource supports the DAV schema and
protocol to merit exclusion of certain locking features, the
authors are proposing that locking be allowed as level indicated. All DAV compliant resources MUST
return the sole axis of
negotiation within WebDAV.

5.2 LOCK Method DAV header on all OPTIONS responses.

9.3. Depth Header

Depth = "Depth" ":" ("0" | "1" | "infinity")

The following sections describe the LOCK method, which Depth header is used to
take out a lock of any access type. These sections with methods executed on collections to
indicate whether the LOCK method describe is to be applied only those semantics that are specific to the
LOCK method collection
(Depth = 0), to the collection and are independent of its immediate children, (Depth =
1), or the access type of collection and all its progeny (Depth = infinity). Note
that Depth = 1 and Depth = infinity behavior only applies to
internal member resources, and not to external member resources.

The Depth header is only supported if a method's definition
explicitly provides for such support.

The following rules are the lock
being requested. Once default behavior for any method that
supports the general LOCK depth header. A method has been
described, subsequent sections describe MAY override these defaults by
defining different behavior in its definition.

Methods which support the semantics depth header MAY choose not to support all
of the
"write" access type, header's values and MAY define, on a case by case basis, the
behavior of the write lock.

5.2.1 Operation

A LOCK method invocation creates on a collection if a depth header is not
present. For example, the lock specified by MOVE method only supports Depth = infinity
and if a depth header is not present will act as if a Depth =
infinity header had been applied.
INTERNET-DRAFT WebDAV November 19, 1997

Clients MUST NOT rely upon methods executing on members of their
hierarchies in any particular order or the Lock-
Info header execution being atomic.
Note that methods MAY provide guarantees on the Request-URI. Lock ordering and atomicity.

Upon execution, a method requests SHOULD NOT
have with a request body. A user-agent SHOULD submit an Owner depth header
field with will perform as much of
its assigned task as possible and then return a lock request.

A successful response specifying
what it was able to a lock invocation MUST include Lock-
Token accomplish and Time-Out headers.

5.2.2 The Effect what it failed to do.

So, for example, an attempt to COPY a hierarchy may result in some
of Locks on Properties and Containers

By default the scope of members being copied and some not.

Any headers on a lock is method with a depth header MUST be applied to all
resources in the entire state scope of the
resource, including method. For example, an if-match
header will have its body and associated properties. As a
result, a lock on a value applied against every resource also locks in the resource's
properties,
method's scope and will cause the method to fail if the header fails
to match.

If a lock on a property may lock a property's
resource resource, source or may restrict destination, within the ability to lock scope of the property's
resource. Only method
is locked in such a single way as to prevent the successful execution of
the method, then the lock token for that resource MUST be used when submitted
with the request in the Lock-Token request header.

9.4. Destination Header

Destination = "Destination" ":" URI

The Destination header specifies a lock
extends to cover both destination resource for methods
such as COPY and MOVE, which take two URIs as parameters.

9.5. Destroy Header

DestroyHeader = "Destroy" ":" #Choices

Choices = "VersionDestroy" | "NoUndelete" | "Undelete" | extend

Extend = RFC-Reg | Coded-URL

RFC-Req = Token ; This is a resource and its properties. Note token value (defined in section 2.2 of
[Fielding et al., 1997]) that
certain lock types MAY override this behavior.

For containers, has been published as an RFC.

Coded-URL = "<" URI ">"

When deleting a lock also affects resource the ability client often wishes to add or remove
members. The nature specify exactly
what sort of delete should be performed. The Destroy header, used
with the effect depends upon the type of access
control involved.

5.2.3 Locking Replicated Resources

Some servers automatically replicate resources across multiple
URLs. In such a circumstance Mandatory header, allows the server MAY only accept a lock on
one of client to specify the URLs end
result it desires. The Destroy header is specified as follows:

The Undelete token requests that, if possible, the server resource should
be left in a state such that it can guarantee be undeleted. The server is not
required to honor this request.
INTERNET-DRAFT WebDAV November 19, 1997

The NoUndelete token requests that the lock will resource MUST NOT be
honored across all the URLs.

5.2.4 Locking Multiple Resources left in
a state such that it can be undeleted.

The LOCK method supports locking multiple resources
simultaneously by allowing for VersionDestroy token includes the listing functionality of several URIs in the
LOCK request. These URIs, in addition
NoUndelete token and extends it to include having the Request-URI, are
then server remove
all versioning references to be locked as a result of the LOCK method's invocation.
When multiple resources are specified the LOCK method only
succeeds if all specified resources are successfully locked. resource that it has control over.

9.6. Enforce-Live-Properties Header

EnforceLiveProperties = "Enforce-Live-Properties_ _:" (_*_ | "Omit"
| 1*(Property-Name))

Property-Name = Coded-URL

The Lock-Tree option of the lock request Enforce-Live-Properties header specifies properties that the
resource and all its internal children (including internal
collections, and their internal members) are to be locked. This
is another mechanism by which a request for a lock on multiple
resources can be specified.

Currently existing locks can not MUST be extended to cover more or
less resources, and any request
_live_ after they are copied (moved) to expand or contract the number destination resource of resources in a lock MUST fail with
a 409 Conflict status code.
So, for example, if resource A is exclusively write locked and
then the same principal asked to exclusively write lock resources
A, B, and C, copy (or move). If the request would fail as A value _*_ is already locked and given for the lock can not be extended.

A successful result will return a single lock token which
represents header, then it
designates all live properties on the resources that have been locked. source resource. If an UNLOCK the value
is executed "Omit" then the server MUST NOT duplicate on this token, all associated resources the destination
resource any properties that are unlocked.

If defined on the lock can source resource. If
this header is not be granted included then the server is expected to all resources, a 406 Conflict
status code MUST be returned with a response entity body
containing a multiresponse XML element describing which
resource(s) prevented act as

defined by the default property handling behavior of the associated
method.

9.7. If-None-State-Match

If-None-State-Match = "If-None-State-Match" ":" 1#Coded-URL

The If-None-State-Match header is intended to have similar
functionality to the If-None-Match header defined in section 14.26
of RFC 2068. However the lock from being granted.

5.2.5 Interaction if-none-state-match header is intended for
use with other Methods

The interaction of any URI which represents state information about a LOCK with various methods
resource, referred to as a state token. A typical example is dependent upon
the a lock type. However, independent
token.

If any of lock type, a successful
DELETE the state tokens identifies the current state of a resource the
resource, the server MUST cause all of its locks to be removed.

5.2.6 Lock Compatibility Table

The table below describes NOT perform the requested method.
Instead, if the behavior that occurs when a lock request is made on method was GET, HEAD, INDEX, or PROPFIND,
the server SHOULD respond with a 304 Not Modified response,
including the cache-related entity-header fields (particularly ETag)
of the current state of the resource.

Current lock state/ Shared Lock Exclusive Lock
Lock For all other request
None True True
Shared Lock True False
Exclusive Lock False False*

Legend: True = lock
methods, the server MUST respond with a status of 412 Precondition
Failed.

If none of the state tokens identifies the current state of the
resource, the server MAY be granted. False = lock perform the requested method.

If any of the tokens is not recognized then the method MUST NOT be
granted. *=if fail
with a 412 Precondition Failed.
INTERNET-DRAFT WebDAV November 19, 1997

Note that the principal requesting "AND" and "OR" keywords specified with the lock If-State-
Match header are intentionally not defined for If-None-State-Match,
because this functionality is not required.

9.8. If-State-Match

If-State-Match = "If-State-Match" ":" ("AND" | "OR") 1#Coded-URL

The If-State-Match header is intended to have similar functionality
to the owner If-Match header defined in section 14.25 of RFC 2068.
However the lock, the lock MAY be regranted.

The current lock If-State-Match header is intended for use with any URI
which represents state of information about a resource resource. A typical
example is given in the leftmost
column, and a lock requests are listed in token.

If the first row. The
intersection of a row AND keyword is used and column gives all of the result state tokens identify the
state of a lock
request. For example, if a shared lock is held on a the resource,
and an exclusive lock is requested, then the table entry is "false",
indicating server MAY perform the lock must not be granted. requested
method. If an exclusive or shared lock the OR keyword is re-requested by used and any of the principal
who owns state tokens
identifies the lock, current state of the lock MUST be regranted. resource, then the server MAY
perform the requested method. If the lock keyword requirement for the
the keyword used is
regranted, not met, the same lock token that was previously issued server MUST be
returned.

5.2.7 Status Codes

409 "Conflict" - The resource is locked, so NOT perform the method has been
rejected.
requested method, and MUST return a 412 "Precondition Failed" - The included state-token was not
enforceable on this resource or the request in Precondition Failed
response.

If any of the lock-info
header could tokens is not be satisfied by recognized then the server.

5.2.8 method MUST fail
with a 412 Precondition Failed.

9.9. Lock-Info Request Header

The Lock-Info request header specifies the scope and type of a
lock for a LOCK method request. The syntax specification below is
extensible, allowing new type and scope identifiers to be added.

LockInfo = "Lock-Info" ":" DAVLockType SP DAVLockScope [SP
AdditionalLocks] [SP Lock-Tree]
DAVLockType = "LockType" "=" DAVLockTypeValue
DAVLockTypeValue = ("Write" | *(uchar | reserved)) Extend)
DAVLockScope = "LockScope" "=" DAVLockScopeValue
DAVLockScopeValue = ("Exclusive" |"Shared" | *(uchar | reserved)) Extend)
AdditionalLocks = "AddLocks" "=" 1*("<" URI ">")
Lock-Tree = "Lock-Tree" "=" ("True" ("T" | "False") "F")

The Lock-Info request header specifies the scope and type of a lock
for a LOCK method request. The syntax specification below is
extensible, allowing new type and scope identifiers to be added.

The LockType field specifies the access type of the lock. At
present, this specification only defines one lock type, the "Write"
lock. The LockScope field specifies whether the lock is an
exclusive lock, or a shared lock. The AddLocks field specifies
additional URIs, beyond the Request-URI, to which the lock request
applies. The LockTree field is used to specify recursive locks. If
the LockTree field is "true", "T", the lock request applies to the hierarchy
traversal of the internal
members member resources of the Request-URI, and
the AddLocks URIs, inclusive of the Request-URI and the AddLocks
URIs. It is not an error if LockTree is true, "T", and the Request-URI or
the AddLocks URIs have no internal member resources. By default,
INTERNET-DRAFT WebDAV November 19, 1997

the value of LockTree is "false", "F", and this field MAY be omitted when its
value is false.

5.2.9 Owner "F".

9.10. Lock-Token Request Header

5.2.9.1 Problem Description

When discovering

Lock-Token = "Lock-Token" ":" 1#Coded-URL

The Lock-Token request header, containing a lock token owned by the list
requesting principal, is used by the principal to indicate that the
principal is aware of owners the existence of locks on the lock specified by the
lock token.

If the following conditions are met:

1) The method is restricted by a resource, lock type that requires the
submission of a
principal may want lock token, such as a write lock,
2) The user-agent has authenticated itself as a principal,
3) The user-agent is submitting a method request to a resource on
which the principal owns a write lock,

Then:

1) The method request MUST include a Lock-Token header with the lock
token, or,
2) The method MUST fail with a 409 Conflict status code.

If multiple resources are involved with a method, such as a COPY or
MOVE method, then the lock tokens, if any, for all involved
resources, MUST be able included in the Lock-Token request header.

For example, Program A, used by user A, takes out a write lock on a
resource. Program A then makes a number of PUT requests on the
locked resource. All the requests contain a Lock-Token request
header that includes the write lock state token. Program B, also
run by User A, then proceeds to contact perform a PUT to the locked
resource. However, program B was not aware of the owner directly. For
this existence of the
lock and so does not include the appropriate Lock-Token request
header. The method is rejected even though principal A is
authorized to be possible perform the PUT. Program B can, if it so chooses, now
perform lock discovery mechanism must provide
enough information for and obtain the lock owner to be contacted.
Additionally, token. Note that
programs may wish to be able to record structured
information in A and B can perform GETs without using the owner Lock-Token
header so that other programs may be
able because the ability to parse it later. Note, however, that these programs may perform a GET is not necessarily be coordinating so there need be affected by a
write lock.

Having a lock token provides no guarantee
that the information special access rights. Anyone can
find out anyone else's lock token by performing lock discovery.
Locks are to be parsed.

5.2.9.2 Solution Requirements

Not all systems have enforced based upon whatever authentication procedures that provide
sufficient information to identify a particular user in
mechanism is used by the server, not based on the secrecy of the
token values.

9.11. Lock-Token Response Header
INTERNET-DRAFT WebDAV November 19, 1997

Lock-Token = "Lock-Token" ":" Coded-URL

If a way
that resource is meaningful to successfully locked then a person. In addition, many systems Lock-Token header will
be returned containing the lock token that do
have sufficient information, such as represents the lock.

9.12. Overwrite Header

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

The Overwrite header specifies whether the server should overwrite
the state of a name and e-mail address,
do not have non-null destination resource during a COPY or MOVE.
A value of _F_ states that the server MUST NOT perform the COPY or
MOVE operation if the state of the ability to associate this information with destination resource is non-null.
By default, the
lock discovery mechanism. Therefore a means value of Overwrite is needed to allow
principals to provide authentication in a manner which will be
meaningful to _T,_ and a person.

The From client MAY omit
this header (defined in RFC 2068), which contains only an
email mailbox, from a request when its value is not sufficient for _T._ While the purposes of quick
identification. When desperately looking for someone
Overwrite header appears to remove a
lock, e-mail is often not sufficient. A telephone number (cell
number, pager number, etc.) would be better. Furthermore, duplicate the
email address in functionality of the From If-
Match: * header of HTTP/1.1, If-Match applies only optionally includes the
owners name and that name is often set to an alias anyway.
Therefore a header more flexible than From is required.

The value also needs to be such that both man and machine can
place values in it the Request-
URI, and later retrieve those values.

5.2.9.3 Syntax

Owner = "Owner" ":" (Coded-XML | quoted-string)
Coded-XML = field-content ; XML where any character which is not legal in field-content (see section 4.2 of [Fielding et al.,
1997]) is XML encoded

The XML SHOULD provide information sufficient for either directly
contacting to the principal (such as Destination of a telephone number COPY or e-mail
URI), MOVE.

If a COPY or for discovering the principal (such as MOVE is not performed due to the URL value of a
homepage) who owns the lock. The quoted string SHOULD provide a
means for directly contacting the principal who owns Overwrite
header, the lock,

such as method MUST fail with a name and telephone number.

5.2.10 Time-Out 409 Conflict status code.

9.13. Propfind Request Header

5.2.10.1 Problem Description

In a perfect world principals take out locks, work on the
resource, and then remove the lock when it is no longer needed.
However, this process

Propfind = "Propfind" ":" ("allprop" | "propname" | RFC-Reg |
1*(Property-Name))

The Propfind header is frequently not completed, leaving active
but unused locks. Reasons for this include client programs
crashing and losing information about locks, users leaving their
systems for the day and forgetting used to remove their locks, etc. As
a result of this behavior, servers need specify which properties are to establish be
returned in a policy PROPFIND method. The properties are identified by
which they can remove a lock without input from
their URIs. Two special tokens are defined for use with the lock owner.
Once such a policy is instituted,
Propfind header, allprop and propname. The allprop token specifies
that all property names and values on the server also needs a
mechanism resource are to inform the principal be
returned. The propname token specifies that only a list of property
names on the policy.

5.2.10.2 Solution Requirements

There resource are two basic lock removal policies: administrator and time
based removal. In the case of administrator based removal, a
principal other than to be returned.

9.14. Status-URI Response Header

The Status-URI response header MAY be used with the lock owner has sufficient access rights 102 Processing
response code to order inform the lock removed, even though they did not take it out.
The second policy type is time based removal. In this case, a
timer is set as soon client as to the lock is created. Every time status of a method method.

Status-URI = "Status-URI" ":" *(Status-Code "<" URI ">") ; Status-
Code is executed on any resource covered by the lock, defined in 6.1.1 of [Fielding et al., 1997]

The URIs listed in the timer is
reset. If header are source resources which have been
affected by the timer runs out, outstanding method. The status code indicates the lock is removed.

User-agents MUST assume that locks may arbitrarily disappear at
any time. If their actions require confirmation
resolution of the existence
of method on the identified resource. So, for
example, if a MOVE method on a collection is outstanding and a lock then 102
"Processing" response with a Status-URI response header is returned,
the If-State headers are available.

5.2.10.3 Syntax included URIs will indicate resources that have had move
attempted on them and what the result was.

9.15. Timeout Header
INTERNET-DRAFT WebDAV November 19, 1997

TimeOut = "Time-Out" "Timeout" ":" 1#TimeType
TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Extend) Other)
DAVTimeOutVal = 1*digit
Extend = RFC-Reg | URL "-" Token ; The URL format is used for
unregistered TimeTypes
RFC-Req
Other = Token Extend field-value ; This is a TimeType that has been published as
an See section 4.2 of RFC 2068

Clients MAY include TimeOut Timeout headers in their LOCK requests.
However
However, the server is not required to honor or even consider the
request. these
requests. Clients MUST NOT submit a Time-Out Timeout request header with any
method other than a LOCK method.

A Time-Out Timeout request header MUST contain at least one TimeType and MAY
contain multiple TimeType entries. The purpose of listing multiple
TimeType entries is to indicate multiple different values and value
types that are acceptable to the client. The client lists the
TimeType entries in order of preference.

The Time-Out Timeout response header MUST use a Second value, Infinite, or a
TimeType the client has indicated familiarity with. The server MAY
assume a client is familiar with any TimeType submitted in a Time-Out Timeout
header.

The "Second" _Second_ TimeType specifies the number of seconds that MUST
elapse between granting of the lock at the server, and the automatic
removal of the lock. A server MUST not generate a time
out timeout value for "Second"
_Second_ greater than 2^32-1.

The time out timeout counter is restarted any time an owner of the client lock sends
a method to any member of the lock, including unsupported methods,
or methods which are unsuccessful. It is recommended that the HEAD
method be used when the goal is simply to restart the time
out timeout
counter.

If the timeout expires then the lock is lost. Specifically the
server SHOULD act as if an UNLOCK method was executed by the server
on the resource using the lock token of the timed-out lock,
performed with its override authority. Thus logs,
notifications, and other mechanisms that act as side effects to
the granting and removal of a lock will logs should be properly informed as
to updated
with the disposition of the lock. lock, notifications should be sent,
etc., just as they would be for an UNLOCK request.

Servers are advised to pay close attention to the values submitted
by clients, as they will be indicative of the type of activity the
client intends to perform. For example, an applet running in a
browser may need to lock a resource, but because of the instability
of the environment within which the applet is running, the applet
may be turned off without warning. As a result, the applet is
likely to ask for a relatively small time-
out timeout value so that if the
applet dies, the lock can be quickly harvested. However However, a document
management system is likely to ask for an extremely long time-out timeout
because its user may be planning on going off-line.

5.2.11 Lock
INTERNET-DRAFT WebDAV November 19, 1997

10. Response

A successful lock response MUST contain a Lock-Token Code Extensions to HTTP/1.1

The following response
header, a Time-Out header and a PROP element codes are added to those defined in the response body
which contains the value of the LockDiscovery property.

5.2.11.1 Lock-Token Response Header

If a resource is successfully locked then a lock-token header
will be returned containing the lock token that represents the
lock.

Lock-Token = "Lock-Token" ":" URI

5.2.12 Example - Simple Lock Request

LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Lock-Info: LockType=Write LockScope=Exclusive
Time-Out: Infinite; Second-4100000000
Owner: <?XML:Namespace href="http://www.ietf.org/standards/dav/"
AS =
"D"/><D:HREF>http://www.ics.uci.edu/~ejw/contact.html</D:HREF> HTTP/1.1 200 OK
Lock-Token: OpaqueLockToken:xyz122393481230912asdfa09s8df09s7df08
sd0f98a098sda
Time-Out: Second-604800
Content-Type: text/xml
Content-Length: xxxxx

<?XML:Namespace

href ="http://www.ietf.org/standards/dav/" AS = "D"/>
<D:Prop>
<lockdiscovery>
<activelock>
<locktype>write</locktype>
<lockscope>exclusive</lockscope>
<addlocks/>
<owner>
<HREF>http://www.ics.uci.edu/~ejw/contact.html</HREF>
</owner>
<timeout>Second-604800</timeout>
<locktoken>
<HREF>
OpaqueLockToken:xyz122393481230912asdfa09s8df09s7d
f08sd0f98a098sda
</HREF>
</locktoken>
</activelock>
</lockdiscovery>
</D:Prop>

This example shows the successful creation
[Fielding et al., 1997].

10.1. 102 Processing

Methods can potentially take a long period of an exclusive write
lock on resource
http://webdav.sb.aol.com/workspace/webdav/proposal.doc. The
resource http://www.ics.uci.edu/~ejw/contact.html contains
contact information time to process,
especially methods that support the Depth header. In such cases the
client may time-out the connection while waiting for a response. To
prevent this the owner of server MAY return a 102 response code to indicate
to the client that the lock. The server has an
activity-based timeout policy in place on this resource, which
causes is still processing the lock method.

If a method is taking longer than 20 seconds (a reasonable, but
arbitrary value) to automatically be removed after 1 week (604800
seconds). process the server SHOULD return a 102
"Processing" response.

10.2. 207 Multi-Status

The response has a Lock-Token header that gives the
state token URL requires providing status for multiple independent
operations.

10.3. 418 Unprocessable Entity

The server understands the content type of the lock token generated by this lock
request.

5.2.13 Example - Multi-Resource Lock Request

LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Lock-Info: LockType=Write LockScope=Exclusive
Addlocks=<http://webdav.sb.aol.com/workspace/><http://foo.bar/bla
h>
Time-Out: Infinite, Second-4100000000
Owner: <http://www.ics.uci.edu/~ejw/contact.html>

HTTP/1.1 409 Conflict
Content-Type: text/xml
Content-Length: xxxxx

<?XML:Namespace href =
"http://www.ietf.org/standards/dav/" As = "D"/>
<D:MultiResponse>
<Response>
<HREF>
http://webdav.sb.aol.com/workspace/webdav/proposal.doc
</HREF>
<HREF>
http://webdav.sb.aol.com/workspace/webdav/
</HREF>
<Status>HTTP/1.1 202 Accepted</Status>
</Response>
<Response>
<HREF>http://foo.bar/blah</HREF>
<Status>HTTP/1.1 403 Forbidden</Status>
</Response>
</D:MultiResponse>

This example shows a request for an exclusive write lock entity, but
was unable to process the contained instructions.

10.4. 419 Insufficient Space on three
resources,
http://webdav.sb.aol.com/workspace/webdav/proposal.doc,
http://webdav.sb.aol.com/workspace/, and http://foo.bar/blah. In Resource

The resource does not have sufficient space to record the state of
the resource after the execution of this request, method.

10.5. 420 Method Failure

The method was not executed on a particular resource within its
scope because some part of the client has specified that it desires an
infinite length lock, method's execution failed causing the
entire method to be aborted. For example, if available, otherwise a timeout resource could not
be moved as part of 4.1
billion seconds, if available. The Owner header field specifies
the web address for contact information for a MOVE method, all the principal taking
out other resources would
fail with a 420 Method Failure.

10.6. 421 Destination Locked

The destination resource of a method is locked, and either the lock.

This lock
request has failed, because the server rejected did not contain a valid Lock-Info header, or the Lock-Info
header identifies a lock request for http://foo.bar/blah. held by another principal.

11. Multi-Status Response

The 409 Conflict status
code indicates that the server was unable to satisfy the request
because there default 207 Multi-Status response body is a conflict between the state text/xml HTTP entity
that contains a single XML element called multistatus, which
contains a set of the resources XML elements called response, one for each 200,
INTERNET-DRAFT WebDAV November 19, 1997

300, 400, and the operation named in the request. Within the
multiresponse, the 202 Accepted 500 series status code indicates that generated during the
lock method was accepted by the resources, and would have been
completed if all resources named in the request were able to
invocation. 100 series status codes MUST NOT be
locked. recorded in a
response XML element.

11.1. multistatus XML Element

Name: multistatus
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains multiple response messages.
Parent: Any
Value: 1*response [responsedescription]
Description: The 403 Forbidden status code indicates that the server
does not allow lock requests on this resource.

5.3 Write Lock

This section describes the semantics specific to responsedescription at the write access
type for locks. The write lock top level is used to
provide a specific instance general message describing the overarching nature of a lock
type, and is the only lock type described in
response. If this specification.

5.3.1 Methods Restricted by Write Locks

A write lock prevents a principal without value is available an application MAY use it
instead of presenting the individual response descriptions contained
within the lock from
successfully executing responses.

11.2. response XML Element

Name: response
Namespace: http://www.ietf.org/standards/dav/
Purpose: Holds a PUT, POST, PATCH, PROPPATCH, MOVE,
DELETE, MKCOL, ADDREF single response
Parent: multistatus
Value: href [prop] status [responsedescription]
Description: Prop MUST contain one or DELREF on more empty XML elements
representing the locked resource. All other
current methods, GET in particular, function independent names of the
lock.

Note, however, that as new methods are created it will properties. Multiple properties may be
necessary
included if the same response applies to them all. If href is used
then the response refers to specify how they interact with a write lock.

5.3.2 Write Locks and Properties

While those without a write lock may problem with the referenced resource,
not alter a property on property.

11.3. status XML Element

Name: status
Namespace: http://www.ietf.org/standards/dav/
Purpose: Holds a
resource it is still possible for the values of live properties
to change, even while locked, due single HTTP status-line
Parent: response
Value: status-line ;status-line defined in [Fielding et al.,
1997]

11.4. responsedescription XML Element

Name: responsedescription
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains a message that can be displayed to the requirements user
explaining the nature of their
schemas. Only dead properties and live properties defined the response.
Parent: multistatus | response
Value: Any
Description: This XML element provides information suitable to
respect locks are guaranteed be
presented to not change while write locked.

If a property user.

12. Generic DAV XML Elements
INTERNET-DRAFT WebDAV November 19, 1997

12.1. href XML Element

Name: href
Namespace: http://www.ietf.org/standards/dav/
Purpose: To identify that the content of the element is write locked then a LOCK request on the
associated resource MUST fail with URI.
Parent: Any
Value: URI ; See section 3.2.1 of [Fielding et al., 1997]

12.2. link XML Element

Name: link
Namespace: http://www.ietf.org/standards/dav/
Purpose: To identify a property as a 409 "Conflict". Note link and to contain the
source and destination of that link.
Values= 1*src 1*dst
Description: Link is used to provide the sources and destinations of
a
write lock on a link. The type of the property MAY be extended to include containing the
associated resource without link XML element
provides the principal having explicitly
requested type of the extension.

5.3.3 Write Locks and Null Resources

It link. Link is possible to assert a write lock on a null resource in order multi-valued element, so
multiple Links may be used together to lock indicate multiple links with
the name. Please note, however, that locking same type.

12.2.1. src XML Element

Name: src
Namespace: http://www.ietf.org/standards/dav/
Purpose: To indicate the source of a null
resource effectively makes link.
Parent: link
Values= URI

12.2.2. dst XML Element

Name: dst
Namespace: http://www.ietf.org/standards/dav/
Purpose: To indicate the resource non-null as destination of a link
Parent: link
Values= URI

12.2.3. Example

<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" AS = "D"?>
<?namespace href = "http://www.foocorp.com/Project/" AS = "F"?>
<D:prop>
<D:Source>
<D:link>
<F:projfiles>Source</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<D:dst>http://foo.bar/src/main.c</D:dst>
</D:link>
<D:link>
<F:projfiles>Library</F:projfiles>
INTERNET-DRAFT WebDAV November 19, 1997

<D:src>http://foo.bar/program</D:src>
<D:dst>http://foo.bar/src/main.lib</D:dst>
</D:link>
<D:link>
<F:projfiles>Makefile</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<D:dst>http://foo.bar/src/makefile</D:dst>
</D:link>
</D:Source>
</D:prop>

In this example the resource
now http://foo.bar/program has lock related properties defined on it.

5.3.4 Write Locks and Collections

A write lock on a collection prevents the addition or removal source
property that contains three links. Each link contains three
elements, two of
members which, src and dst, are part of the collection. As a consequence, when a principal
issues a request to create a new internal member of a collection
using PUT or POST, or to remove an existing internal member of a
collection using DELETE, DAV schema
defined in this request MUST fail if document, and one which is defined by the schema
http://www.foocorp.com/project/ (Source, Library, and Makefile). A
client which only implements the principal
does elements in the DAV spec will not have a write lock on
understand the collection.

However, if a write lock request is issued foocorp elements and will ignore them, thus seeing
the expected source and destination links. An enhanced client may
know about the foocorp elements and be able to a collection
containing internal member resources that are currently locked, present the request MUST fail user with a 409 Conflict status code.

5.3.5 Write Locks and COPY/MOVE

The owner
additional information about the links. This example demonstrates
the power of XML markup that allows for element values to be
enhanced without breaking older clients.

12.3. prop XML element

Name: prop
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains properties related to a write lock MUST NOT execute resource.
Parent: Any
Values: XML Elements
Description: The prop XML element is a MOVE method generic container for
properties defined on a
resource they have locked. This specification intentionally does
not resources. All elements inside prop MUST
define what happens if a MOVE method request is made on properties related to the resource. No other elements may be
used inside of a
locked resource by prop element.

13. DAV Properties

13.1. creationdate Property

Name: creationdate
Namespace: http://www.ietf.org/standards/dav/
Purpose: The time and date the lock's owner.

A COPY method invocation resource was created.
Value: The time and date MUST NOT duplicate any write locks
active be given in ISO 8601 format
[ISO8601]
Description: This property SHOULD be defined on the source.

5.3.6 Re-issuing Write Locks all DAV compliant
resources. If a principal already owns a write lock on a resource, any
future requests for the same type present, it contains a timestamp of write lock, on the same
resource, while moment when
the principal's previous write lock is in effect,
MUST result in a successful response with resource was created (i.e., the same lock token as
provided moment it had non-null state).

13.2. displayname Property
INTERNET-DRAFT WebDAV November 19, 1997

Name: displayname
Namespace: http://www.ietf.org/standards/dav/
Purpose: A name for the currently existing lock. Two lock requests are
defined resource that is suitable for
presentation to a user.
Value: Any valid XML character data (as defined in [Bray,
Sperberg-McQueen, 1997])
Description:This property SHOULD be identical if their Lock-Info headers are identical.

5.3.7 Write Locks and The State-Token Header

5.3.7.1 Problem Definition defined on all DAV compliant
resources. If present, the property contains a user agent description of the
resource that is not required suitable for presentation to have knowledge about a lock
when requesting an operation on a locked resource, user.

13.3. get-content-language Property

Name: get-content-language
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the following
scenario might occur. Program A, run Content-Language header returned by User A, takes out a write
lock on a resource. Program B, also run by User A, has GET
without accept headers. If no
knowledge Content-Language header is available,
this property MUST NOT exist.
Value: language-tag ;language-tag is defined in section 14.13
of RFC 2068

13.4. get-content-length Property

Name: get-content-length
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the lock taken out Content-Length header returned by Program A, yet performs a PUT
to GET
without accept headers. If no Content-Length header is available,
this property MUST NOT exist.
Value: content-length ; see section 14.14 of RFC 2068

13.5. get-content-type Property

Name: get-content-type
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the locked resource. In Content-Type header returned by a GET
without accept headers. If no Content-Type header is available,
this scenario, property MUST NOT exist.
Value: media-type ; defined in Section 3.7 of [Fielding et
al., 1997]

13.6. get-etag Property

Name: get-etag
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the PUT succeeds
because locks are associated with a principal, not ETag header returned by a program, and
thus program B, because it is acting with principal A’s
credential, GET without
accept headers. If no ETag header is allowed to perform available, this property MUST
NOT exist.
Value: entity-tag ; defined in Section 3.11 of [Fielding et
al., 1997]
Description:Note that the PUT. However, had program B
known about ETag on some resource may reflect changes
in any part of the lock, it would not have overwritten state of the resource,
preferring instead to present a dialog box describing the
conflict to the user. Due to this scenario, not necessarily just a mechanism is needed
change to prevent different programs from accidentally ignoring locks
taken out by other programs with the same authorization.

5.3.7.2 Solution Requirement

The solution must not require principals to perform discovery in
order to prevent accidental overwrites as this could cause race
conditions.

The solution must not require that clients guess what sorts of
locks might be used and use if-state-match headers with wildcards
to prevent collisions. The problem with trying response to "guess" which
locks are being used is that new lock types might be introduced,

and the program would not know to "guess them". So, for GET method. For example, a client might put change in an if-state-match header with a wildcard
specifying that if any write lock is outstanding then
the
operation should fail. However a new read/write lock could be
introduced which ACL may cause the client would not know ETag to put in change.
INTERNET-DRAFT WebDAV November 19, 1997

13.7. get-last-modified Property

Name: get-last-modified
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the header.

5.3.7.3 State-Token Header

The State-Token header, containing a lock token owned Last-Modified header returned by the
requesting principal, a GET
method without accept headers. If no Last-Modified header is used by the principal to indicate
available, this property MUST NOT exist.
Value: HTTP-date ; defined in Section 3.3.1 of [Fielding et
al., 1997]
Description:Note that the principal is aware last-modified date on some resource may
reflect changes in any part of the existence state of the lock specified by
the lock token. It is used in resource, not
necessarily just a change to the following way.

If response to the following conditions are met:
1. GET method. For
example, a user-agent has authenticated itself as change in a principal,
2. property may cause the user-agent is submitting a method request last-modified date to a
resource
on which the principal owns a write lock,
3.
change.

13.8. index-content-language Property

Name: index-content-language
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the method is restricted Content-Language header returned by a write lock, as an
INDEX without accept headers. If no Content-Language header is
available, this property MUST NOT exist.
Value: language-tag ;language-tag is defined in
the section "Methods Restricted 14.13
of RFC 2068

13.9. index-content-length Property

Name: index-content-length
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the Content-Length header returned by a Write Lock",
then an INDEX
without accept headers. If no Content-Length header is available,
this property MUST NOT exist.
Value: content-length ; see section 14.14 of RFC 2068

13.10. index-content-type Property

Name: index-content-type
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the method request Content-Type header returned by an INDEX
without accept headers. If no Content-Type header is available,
this property MUST include a State-Token NOT exist.
Value: media-type ; defined in Section 3.7 of [Fielding et
al., 1997]

13.11. index-etag Property

Name: index-etag
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the ETag header with returned by an INDEX without
accept headers. If no ETag header is available, this property MUST
NOT exist.
INTERNET-DRAFT WebDAV November 19, 1997

Value: entity-tag ; defined in Section 3.11 of [Fielding et
al., 1997]
Description:Note that the lock token ETag on some resource may reflect changes
in any part of the write lock, or state of the method fails with a 409
Conflict status code. If multiple resources are involved with a
method, such as resource, not necessarily just a COPY or MOVE method, then
change to the lock tokens, if
any, for all involved resources, MUST be included in response to the State-
Token request header. INDEX method. For example, Program A, used by user A, takes out a write lock on
a resource. Program A then makes a number of PUT requests on change
in the
locked resource, all ACL may cause the requests contain a State-Token header
which includes ETag to change.

13.12. index-last-modified Property

Name: index-last-modified
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the write lock state token. Program B, also run Last-Modified header returned by
User A, then proceeds to perform a PUT to an INDEX
method without accept headers. If no Last-Modified header is
available, this property MUST NOT exist.
Value: HTTP-date ; defined in Section 3.3.1 of [Fielding et
al., 1997]
Description:Note that the locked resource.
However program B was not aware last-modified date on some resource may
reflect changes in any part of the existence state of the lock and
so does resource, not include the appropriate state-token header. The
method is rejected even though principal A is authorized
necessarily just a change to
perform the PUT. Program B can, if it so chooses, now perform
lock discovery and obtain the lock token. Note that program A and
B can perform GETs without using response to the state-token header because INDEX method. For
example, a change in a property may cause the ability last-modified date to perform
change.

13.13. lockdiscovery Property

Name: lockdiscovery
Namespace: http://www.ietf.org/standards/dav/
Purpose: To discover what locks are active on a GET is not affected by resource
Values= *activelock
Description:The lockdiscovery property returns a write lock.

Having listing of who has
a lock, what type of lock state token provides no special access rights.
Anyone can find out anyone else’s lock state token by performing
lock discovery. Locks are to be enforced based upon whatever
authentication mechanism is used by the server, not based on he have, the
secrecy of timeout type and the token values.

5.3.7.3.1 Example

COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
State-Token: <OpaqueLockToken:123AbcEfg1284h23h2>
<OpaqueLockToken:AAAASDFcalkjfdas12312>

HTTP/1.1 200 OK

In this example, both time
remaining on the source timeout, and destination are locked so
two the associated lock tokens must be submitted. If only one token. The server
is free to withhold any or all of this information if the two
resources was locked, then only one token would requesting
principal does not have sufficient access rights to be
submitted.

5.4 Lock Tokens

5.4.1 Problem Description

It is possible that once a lock has been granted it may be
removed without see the lock owner’s knowledge. This can cause
serialization problems if
requested data. A server which supports locks MUST provide the lock owner executes methods
thinking their lock is still active. Due to this,
lockdiscovery property on any resource with locks on it.

13.13.1. activelock XML Element

Name: activelock
Namespace: http://www.ietf.org/standards/dav/
Purpose: A multivalued XML element that describes a mechanism is
needed for particular
active lock on a principal to predicate resource
Parent: lockdiscovery
Values= locktype lockscope [addlocks] owner timeout locktoken

13.13.2. owner XML Element

Name: owner
Namespace: http://www.ietf.org/standards/dav/
Purpose: Returns owner information
Parent: activelock
Values= XML:REF | *PCDATA
INTERNET-DRAFT WebDAV November 19, 1997

13.13.3. timeout XML Element

Name: timeout
Namespace: http://www.ietf.org/standards/dav/
Purpose: Returns information about the timeout associated with
the successful execution of a
message upon lock
Parent: activelock
Values= TimeType

13.13.4. addlocks XML Element

Name: addlocks
Namespace: http://www.ietf.org/standards/dav/
Purpose: Lists additional resources associated with this lock, if
any.
Parent: activelock
Values= 1*href

13.13.5. locktoken XML Element

Name: locktoken
Namespace: http://www.ietf.org/standards/dav/
Purpose: Returns the continuing existence of a lock.

5.4.2 Lock Token Introduction

A lock token is
Parent: activelock
Values= href
Description:The href contains a type of state token that describes Lock-Token-URL.

13.13.6. Example

PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml

<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" AS = "D"?>
<D:propfind>
<D:prop><lockdiscovery/></D:prop>
</D:propfind>

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

<?XML version="1.0">
<?namespace href ="http://www.ietf.org/standards/dav/" AS = "D"?>
<D:multistatus>
<D:response>
<D:prop>
<D:lockdiscovery>
<D:activelock>
INTERNET-DRAFT WebDAV November 19, 1997

<D:locktype>write</D:locktype>
<D:lockscope>exclusive</D:lockscope>
<D:addlocks>
<D:href>http://foo.com/doc/</D:href>
</D:addlocks>
<D:owner>Jane Smith</D:owner>
<D:timeout>Infinite</D:timeout>
<D:locktoken>
<D:href>iamuri:unique!!!!!</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>

This resource has a particular
lock. A lock token is returned by every successful LOCK
operation, and can also be discovered through single exclusive write lock discovery on a
resource.

There are two types of lock tokens, a generic lock token, which
is unique only for a particular resource, and it, with an opaque
infinite timeout. This same lock
token, which is unique across all resources for all time.

Uniqueness for a particular also covers the resource prevents problems with long
held outstanding lock tokens being confused with newer tokens.
http://foo.com/doc/.

13.14. resourcetype Property

Name: resourcetype
Namespace: http://www.ietf.org/standards/dav/
Purpose: This uniqueness requirement is the same as for e-tags. Uniqueness
across all resources for all time allows for tokens to be
submitted across resources and servers without fear property contains a series of confusion.

Generic lock tokens, because XML elements that
specify information regarding the nature of their relaxed uniqueness
requirements, are faster to generate than opaque lock tokens.

5.4.3 Generic Lock Tokens

Any valid URI can the resource. This
specification only defines a single value, collection.
Value: XML elements
Description:This property MUST be used by defined on all DAV compliant
resources. The default value is empty.

13.14.1. collection XML Element

Name: collection
Namespace: http://www.ietf.org/standards/dav/
Purpose: Identifies the associated resource as a generic lock
token. collection.
Collection resources MUST define this value with the resourcetype
property.
Parent: resourcetype
Values: None

13.15. Source Link Property Type

Name: source
Namespace: http://www.ietf.org/standards/dav/link/
Purpose: The only requirement is that destination of the lock token MUST never
have been issued previously on that resource. Because a lock
token is only guaranteed to be unique on source link identifies the
resource that
generated it, contains the lock token MUST NOT be submitted in a state-
token request header unprocessed source of the link's source.
Parent: None
Value: An XML document with zero or an if-state[-not]-match header on any
resource but more link XML elements.
INTERNET-DRAFT WebDAV November 19, 1997

Discussion: The source of the link (src) is typically the URI of the
output resource that generated it.

5.4.4 OpaqueLockToken Lock Token

The opaquelocktoken scheme on which the link is designed to defined, and there is typically
only one destination (dst) of the link, which is the URI where the
unprocessed source of the resource may be unique across all
resources for all time. Due to accessed. When more than

one link destination exists, this uniqueness quality, specification asserts no policy on
ordering.

13.16. supportedlock Property

Name: supportedlock
Namespace: http://www.ietf.org/standards/dav/
Purpose: To provide a client
MAY submit an opaque listing of the lock token in a state-token request header
and an if-state[-not]-match header on capabilities supported
by the resource.
Values: An XML document containing zero or more LockEntry XML
elements.
Description:The supportedlock property of a resource other than the
one that returned it.

All resources MUST recognize returns a
listing of the opaquelocktoken scheme combinations of scope and access types which may be
able to, at minimum, recognize that the
specified in a lock token was not
generated by request on the resource. Note, however, Note that resources the actual
contents are themselves controlled by access controls so a server is
not required to generate opaquelocktokens.

In order to guarantee uniqueness across all resources for all
time provide information the opaquelocktoken requires client is not authorized to
see. If supportedlock is available on _*_ then it MUST define the use
set of locks allowed on all resources on that server.

13.16.1. lockentry XML Element

Name: lockentry
Namespace: http://www.ietf.org/standards/dav/
Purpose: Defines a DAVLockType/LockScope pair that may be legally
used with a LOCK on the GUID mechanism.

Opaquelocktoken generators however have specified resource.
Parent: supportedlock
Values= locktype lockscope

13.16.2. locktype XML Element

Name: locktype
Namespace: http://www.ietf.org/standards/dav/
Purpose: Lists a choice DAVLockType
Parent: lockentry
Values= DAVLockTypeValue

13.16.3. lockscope XML Element

Name: lockscope
Namespace: http://www.ietf.org/standards/dav/
Purpose: Lists a DAVLockScope
Parent: lockentry

Values: DAVLockScopeValue

13.16.4. Example

PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
INTERNET-DRAFT WebDAV November 19, 1997

Content-Length: xxxx
Content-Type: text/xml

<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" AS = "D"?>
<D:propfind>
<D:prop><supportedlock/></D:prop>
</D:propfind>

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

<?XML version="1.0">
<?namespace href ="http://www.ietf.org/standards/dav/" AS = "D"?>
<D:multistatus>
<D:response>
<D:prop>
<D:supportedlock>
<D:LockEntry>
<D:locktype>Write</D:locktype>
<D:lockscope>Exclusive</D:lockscope>
</D:LockEntry>
<D:LockEntry>
<D:locktype>Write</D:locktype>
<D:lockscope>Shared</D:lockscope>
</D:LockEntry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>

14. DAV Compliance Levels

A DAV compliant resource can choose from two levels of how they
create these tokens. They compliance.
A client can either generate discover which level a new GUID for
every lock token they create, resource supports by executing
OPTIONS on the resource, and examining the "DAV" header which is potentially very

expensive, or they can create a single GUID
returned.

Since this document describes extensions to the HTTP/1.1 protocol,
minimally all DAV compliant resources, clients, and then add
extension characters. If proxies MUST be
compliant with RFC 2068 [Fielding et al., 1997].

14.1. Level 1

A level 1 compliant resource MUST meet all "MUST" requirements in
all sections of this document.

14.2. Level 2
INTERNET-DRAFT WebDAV November 19, 1997

A level 2 compliant resource MUST meet all level 1 requirements and
support the second method is selected then supportedlock property as well as the
program generating LOCK method.

15. Internationalization Considerations

In the extensions MUST guarantee that realm of internationalization issues, this specification is
substantively in compliance with the same
extension will never IETF Character Set Policy
[Alvestrand, 1997]. In this specification, human-readable fields can
be used twice with found in either the associated GUID.

Opaque-Lock-Token = "OpaqueLockToken" ":" GUID [Extension]
GUID = ; As defined value of a property, or in [LEACH]
Extension = *urlc ;urlc is defined an error message
returned in [Berners-Lee et al.,
1997] (draft-fielding-url-syntax-07.txt)

5.5 UNLOCK Method

5.5.1 Problem Definition

The UNLOCK method removes a response entity body. In both cases, the lock identified human-
readable content is encoded using XML, which has explicit provisions
for character set tagging and encoding, and requires by default that
XML processors read XML elements encoded using the lock token
in the State-Token header from the Request-URI, UTF-8 and all UCS-2
encodings of the ISO 10646 basic multilingual plane. Furthermore,
XML contains provisions for encoding XML elements using other
resources included
encoding schemes, notable among them UCS-4, which permits encoding
of characters from any ISO 10646 character plane.

The default character set encoding for XML data in the lock.

5.5.2 Example

UNLOCK /workspace/webdav/info.doc HTTP/1.1
Host: webdav.sb.aol.com
State-Token: OpaqueLockToken:123AbcEfg1284h23h2

HTTP/1.1 200 OK

In this example,
specification, and in general, is UTF-8. WebDAV compliant
applications MUST support the lock identified by UTF-8 and UCS-2 character set
encodings for XML elements, and SHOULD support the lock token
"OpaqueLockToken:123AbcEfg1284h23h2" UCS-4 encoding.
The XML character set encoding declaration for each supported
character set MUST also be supported, since it is successfully removed from
the resource http://webdav.sb.aol.com/workspace/webdav/info.doc.
If by using this lock included more than just one resource,
encoding declaration that an XML processor determines the lock is
removed from those resources as well.

5.6 Discovery Mechanisms

5.6.1 Lock Capability Discovery

5.6.1.1 Problem Definition

Since server lock support is optional, a client trying encoding
of an element.

XML also provides language tagging capability which provides the
ability to lock a
resource on a server can either try specify the lock language of the contents of a particular XML
element. Although XML, and hope hence WebDAV, does not use RFC 1766
language tags for its language names, the
best, or perform some form benefit of discovery to determine what lock
capabilities using standard
XML in this context outweighs the server supports. This is known as lock
capability discovery. Lock capability discovery differs from
discovery advantage of supported access control types, since there may be
access control types without corresponding lock types.

5.6.1.2 SupportedLock Property

Name: http://www.ietf.org/standards/dav/lock/supportedlock
Purpose: To provide a listing using RFC 1766
language tags.

Names used within this specification fall into two categories: names
specific to protocol elements such as methods and headers, names of the lock capabilities supported
by the resource.
Schema: http://www.ietf.org/standards/dav/
Values: An XML document containing zero or more LockEntry
XML
elements.
Description: The SupportedLock property elements, and names of a resource returns a
listing properties. Naming of protocol elements
follows the combinations precedent of scope and access types which may
be specified HTTP, using English names encoded in a lock request on the resource. Note that the
actual contents
USASCII for methods and headers. Since these protocol elements are themselves controlled by access controls so a

server is
not required visible to provide information the client is users, and are in fact simply long token identifiers,
they do not
authorized need to see. If SupportedLock is available on "*" then it
MUST define the set of locks allowed on all resources on that
server.

5.6.1.3 LOCKENTRY XML Element

Name: http://www.ietf.org/standards/dav/lockentry
Purpose: Defines a DAVLockType/LockScope pair which may be
legally used with a LOCK on the specified resource.
Schema: http://www.ietf.org/standards/dav/
Parent: A SupportedLock entry
Values: LockType LockScope

5.6.1.4 LOCKTYPE XML Element

Name: http://www.ietf.org/standards/dav/locktype
Purpose: Lists a DAVLockType
Schema: http://www.ietf.org/standards/dav/
Parent: LOCKENTRY
Values: DAVLockTypeValue

5.6.1.5 LOCKSCOPE support encoding in multiple character sets.
Similarly, though the names of XML Element

Name: http://www.ietf.org/standards/dav/lockscope
Purpose: Lists elements used in this
specification are English names encoded in UTF-8, these names are
not visible to the user, and hence do not need to support multiple
character set encodings.

The name of a DAVLockScope
Schema: http://www.ietf.org/standards/dav/
Parent: LOCKENTRY
Values: DAVLockScopeValue

5.6.1.6 Example

PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml

<?XML:Namespace href =
"http://www.ietf.org/standards/dav/" AS = "D"/>
<D:PROPFIND>
<prop><SupportedLock/></prop>
</D:PROPFIND>

HTTP/1.1 207 Multi-Response
Content-Type: text/xml
Content-Length: xxxxx

<?XML:Namespace
href ="http://www.ietf.org/standards/dav/" AS = "D"/>
<D:MultiResponse>
<Response>
<Prop>
<SupportedLock>
<LockEntry>
<LockType>Write</LockType>
<LockScope>Exclusive</LockScope>
</LockEntry>
<LockEntry>
<LockType>Write</LockType>
<LockScope>Shared</LockScope>
</LockEntry>

</SupportedLock>
</Prop>
<Status>HTTP/1.1 200 Success</Status>
</Response>
</D:MultiResponse>

5.6.2 Active Lock Discovery

5.6.2.1 Problem Definition

If another principal locks property defined on a resource that is a principal wishes URI. Although
some applications (e.g., a generic property viewer) will display
property URIs directly to
access, their users, it is useful for the second principal to be able to find
out who expected that the first principal is.

5.6.2.2 Solution Requirements

The lock discovery mechanism should provide
typical application will use a list fixed set of who has the
resource locked, what locks they have, properties, and what their lock tokens
are. The lock tokens are useful will
provide a mapping from the property name URI to a human-readable
INTERNET-DRAFT WebDAV November 19, 1997

field when displaying the property name to a user. It is only in shared lock situations
the case where
two principals may want to guarantee that they do the set of properties is not overwrite
each other. The lock tokens are also useful for administrative
purposes so known ahead of time that
an administrator can remove application need display a lock by referring property name URI to its token.

5.6.2.3 LOCKDISCOVERY Property

Name: http://www.ietf.org/standards/dav/lockdiscovery
Purpose: To discover what locks are active on a resource
Schema: http://www.ietf.org/standards/dav/
Values= An XML document containing zero or more ActiveLock XML
elements.

Description: The LOCKDISCOVERY user. We
recommend that applications provide human-readable property returns a listing names
wherever feasible.

For error reporting, we follow the convention of who
has HTTP/1.1 status
codes, including with each status code a lock, what type short, English description
of lock they have, the time out type and the time remaining on code (e.g., 421 Destination Locked). While the time out, possibility
exists that a poorly crafted user agent would display this message
to a user, internationalized applications will ignore this message,
and display an appropriate message in the associated lock
token. The server is free to withhold any or all user's language and
character set.

Since interoperation of clients and servers does not require locale
information, this
information if the requesting principal specification does not have sufficient
access rights to see the requested data. A server which supports
locks MUST provide the LOCKDISCOVERY property on specify any resource
with locks on it.

5.6.2.4 ACTIVELOCK XML Element

Name: http://www.ietf.org/standards/dav/activelock
Purpose: mechanism for
transmission of this information.

16. Security Considerations
[TBD]

17. Terminology

Collection - A multivalued XML element resource that describes a particular
active lock on a contains member resources.

Member Resource - A resource
Schema: http://www.ietf.org/standards/dav/
Parent: contained by a collection. There are
two types of member resources: external and internal.

Internal Member Resource _ A LOCKDISCOVERY entry
Values= LOCKTYPE LOCKSCOPE [ADDLOCKS] OWNER TIMEOUT LOCKTOKEN

5.6.2.5 OWNER XML Element

Name: http://www.ietf.org/standards/dav/lock/owner
Purpose: Returns owner information
Schema: http://www.ietf.org/standards/dav/
Parent: ACTIVELOCK
Values= XML:REF | {any valid XML string}

5.6.2.6 TIMEOUT XML Element

Name: http://www.ietf.org/standards/dav/timeout
Purpose: Returns information about the timeout associated with member resource of a collection whose
URI is relative to the lock
Schema: http://www.ietf.org/standards/dav/
Parent: ACTIVELOCK
Values= TimeType

5.6.2.7 ADDLOCKS XML Element

Name: http://www.ietf.org/standards/dav/addlocks
Purpose: Lists additional resources associated with this lock, if
any.
Schema: http://www.ietf.org/standards/dav/
Parent: ACTIVELOCK
Values= 1*HREF

5.6.2.8 LOCKTOKEN XML Element

Name: http://www.ietf.org/standards/dav/statetoken
Purpose: Returns URI of the lock token
Schema: http://www.ietf.org/standards/dav/
Parent: ACTIVELOCK
Values= HREF
Description: The HREF contains a Lock-Token-URL.

5.6.2.9 Example

PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml

<?XML:Namespace href =
"http://www.ietf.org/standards/dav/" AS = "D"/>
<D:PROPFIND>
<prop><lockdiscovery/></prop>
</D:PROPFIND>

HTTP/1.1 207 Multi-Response
Content-Type: text/xml
Content-Length: xxxxx

<?XML:Namespace
href ="http://www.ietf.org/standards/dav/" AS = "D"/>
<D:MultiResponse>
<Response>
<Prop>
<lockdiscovery>
<activelock>
<locktype>write</locktype>
<lockscope>exclusive</lockscope>
<addlocks>
<HREF>http://foo.com/doc/</HREF>
</addlocks>
<owner>Jane Smith</owner>
<timeout>Infinite</timeout>
<locktoken>
<HREF>iamuri:unique!!!!!</HREF>
</locktoken>
</activelock>

</lockdiscovery>
</Prop>
<Status>HTTP/1.1 200 Success</Status>
</Response>
</D:MultiResponse>

This collection.

External Member Resource - A member resource has of a single exclusive write lock on it, collection with an
infinite time out. This same lock also covers
absolute URI that is not relative to its parent's URI.

Property - A name/value pair that contains descriptive information
about a resource.

Live Property _ A property whose semantics and syntax are enforced
by the resource
http://foo.com/doc/.

6 Version Control
[TBD]

7 Internationalization Support
[TBD]

8 Security Considerations
[TBD]

9 server. For example, a live "content-length" property would
have its value, the length of the entity returned by a GET request,
automatically calculated by the server.

Dead Property _ A property whose semantics and syntax are not
enforced by the server. The server only records the value of a dead
property; the client is responsible for maintaining the consistency
of the syntax and semantics of a dead property.

18. Copyright
INTERNET-DRAFT WebDAV November 19, 1997

The following copyright notice is copied from RFC 2026 chapter 10.4,
and describes the applicable copyright for this document

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

19. Acknowledgements

A specification such as this thrives on piercing critical review and
withers from apathetic neglect. The authors gratefully acknowledge
the contributions of the following people, whose insights were so
valuable at every stage of our work.

Terry Allen, Harald Alvestrand, Alan Babich, Dylan Barrell, Bernard
Chester, Tim Berners-Lee, Dan Connolly, Jim Cunningham, Ron Daniel,
Jr., Jim Davis, Keith Dawson, Mark Day, Martin Duerst, David Durand,
Lee Farrell, Chuck Fay, Roy Fielding, Mark Fisher, Alan Freier,
George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton,
Steve Henning, Alex Hopmann, Andre van der Hoek, Ben Laurie, Paul
Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter,
Michael Mealling, Keith Moore, Henrik Nielsen, Kenji Ota, Bob
Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry Sanders,
Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar Stefferud,
Ralph Swick, Kenji Takahashi, Richard N. Taylor, Robert Thau, John
Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and
Lauren Wood

11 Wood.
INTERNET-DRAFT WebDAV November 19, 1997

One from this list deserves special mention. The contributions by
Larry Masinter have been invaluable, both in helping the formation
of the working group and in patiently coaching the authors along the
way. In so many ways he has set high standards we have toiled to
meet.
INTERNET-DRAFT WebDAV November 19, 1997

20. References

[Alvestrand, 1997] H. T. Alvestrand, "IETF Policy on Character Sets
and Languages." Internet-draft, work-in-progress.
ftp://ds.internic.net/internet-drafts/draft-alvestrand-charset-
policy-02.txt

[Berners-Lee, 1997] T. Berners-Lee, "Metadata Architecture."
Unpublished white paper, January 1997.
http://www.w3.org/pub/WWW/DesignIssues/Metadata.html.

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

[Bray, Sperberg-McQueen, 1997] T. Bray, C. M. Sperberg-McQueen,
"Extensible Markup Language (XML): Part I. Syntax", WD-xml-
lang.html, http://www.w3.org/pub/WWW/TR/WD-xml-lang.html.

[Connolly et al, 1997] D. Connolly, R. Khare, H.F. Nielsen, "PEP
- an Extension Mechanism for HTTP", Internet draft, work-in-
progress. draft-ietf-http-pep-04.txt,
ftp://ds.internic.net/internet-drafts/draft-ietf-http-pep-04.txt.

[Fielding et al., 1997] R. Fielding, J. Gettys, J. Mogul, H.
Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1."
RFC 2068. U.C. Irvine, DEC, MIT/LCS. January, 1997.
ftp://ds.internic.net/rfc/rfc2068.txt

[Lasher, Cohen, 1995] R. Lasher, D. Cohen, "A Format for
Bibliographic Records," RFC 1807. Stanford, Myricom. June, 1995.
ftp://ds.internic.net/rfc/rfc1807.txt

[Leach, Salz, 1997] P. J. Leach, R. Salz, "UUIDs and GUIDs."
Internet-draft (expired), work-in-progress, February, 1997.
http://www.internic.net/internet-drafts/draft-leach-uuids-guids-
00.txt

[Maloney, 1996] M. Maloney, "Hypertext Links in HTML." Internet
draft (expired), work-in-progress, January, 1996.

[MARC, 1994] Network Development and MARC Standards, Office, ed.
1994. "USMARC Format for Bibliographic Data", 1994. Washington, DC:
Cataloging Distribution Service, Library of Congress.

[Miller et al., 1996] J. Miller, T. Krauskopf, P. Resnick, W.
Treese, "PICS Label Distribution Label Syntax and Communication
Protocols" Version 1.1, W3C Recommendation REC-PICS-labels-
961031. REC-PICS-labels-961031.
http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.

[Slein et al., 1997] J. A. Slein, F. Vitali, E. J. Whitehead, Jr.,
D. Durand, "Requirements for Distributed Authoring and Versioning on
Protocol for the World Wide Web." Internet-draft, work-in-
progress, draft-ietf-webdav-requirements-04.txt,
ftp://ds.internic.net/internet-drafts/draft-ietf-webdav-
requirements-04.txt. RFC XXXX. Xerox, Univ. of Bologna,
U.C. Irvine, Boston Univ. YYY, 1997.
ftp://ds.internic.net/rfc/rfcXXXX.txt
INTERNET-DRAFT WebDAV November 19, 1997

[WebDAV, 1997] WEBDAV Design Team. "A Proposal for Web Metadata
Operations." Unpublished manuscript.
http://www.ics.uci.edu/~ejw/authoring/proposals/metadata.html

[Weibel et al., 1995] S. Weibel, J. Godby, E. Miller, R. Daniel,
"OCLC/NCSA Metadata Workshop Report."
http://purl.oclc.org/metadata/dublin_core_report.

[Yergeau, 1997] F. Yergeau, "UTF-8, a transformation format of
Unicode and ISO 10646", Internet Draft, work-in-progress, draft-
yergeau-utf8-rev-00.txt, http://www.internic.net/internet-
drafts/draft-yergeau-utf8-rev-00.txt.

12
INTERNET-DRAFT WebDAV November 19, 1997

21. Authors' Addresses

Y. Y. Goland
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Email
Email: yarong@microsoft.com

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

A. Faizi
Netscape
685 East Middlefield Road
Mountain View, CA 94043
Email: asad@netscape.com

S. R R. Carter
Novell
1555 N. Technology Way
M/S ORM F111
Orem, UT 84097-2399
Email
Email: srcarter@novell.com

D. Jensen
Novell
1555 N. Technology Way
M/S ORM F111
Orem, UT 84097-2399
Email
Email: dcjensen@novell.com

----