view Side-By-Side changes
WEBDAV Working Group Y. Y. Goland, Microsoft
INTERNET-DRAFT E. J. Whitehead, Jr., U.C. Irvine
<draft-ietf-webdav-protocol-01> Asad
<draft-ietf-webdav-protocol-02> A. Faizi, Netscape
Stephen R.
S. R Carter, Novell
Del
D. Jensen, Novell
Expires January 15, 1997 July 13, March 8, 1998 September 3, 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>.
Discussions of the WEBDAV working group are archived at
<URL:http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth>.
Abstract
This Document specifies a set of methods and content-types
ancillary to HTTP/1.1 for the management of resource properties,
simple name space manipulation, simple resource locking
(collision avoidance) and resource version control.
Table of Contents
Abstract
1 Terminology
2 Data Model and Methods for DAV Properties
2.1 Introduction
2.1.1............................The
2.1.1 The DAV Property
2.1.2.................Existing
2.1.2 Existing Metadata Proposals
2.1.3.................Properties
2.1.3 Properties and HTTP Headers
2.2 A Property Model for HTTP Resources
2.2.1....................................Overview
2.2.2..........................Property
2.2.1 Overview
2.2.2 Property Namespace
2.2.3.........................Property Attributes
2.2.4.....................................Schemas
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.3.1..............................Live Attribute
2.3.2..........................ReadOnly
2.4.1 DAV Property
2.4.2 Level XML Element
2.4.3 Prop XML element
2.4.4 PropLoc XML Attribute
2.3.3....................................Elements
2.4
2.4.5 Example
2.5 Property Identifiers
2.4.1..........................Problem
2.5.1 Problem Definition
2.4.2........................Solution Requirement
2.4.3...........................DAV URL Parameter
2.4.4...............................Name Encoding
2.4.5...........Compatibility with legacy systems
2.5
2.6 Link XML Element
2.5.1.........................Problem
2.6.1 Problem Description
2.5.2.......................Solution
2.6.2 Solution Requirements
2.5.3............................Link
2.6.3 Link XML Element
2.5.4.............................Src
2.6.4 Src XML Element
2.5.5.............................Dst
2.6.5 Dst XML Element
2.5.6.....................................Example
2.6
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 and Methods
2.6.1......................................DELETE
2.6.2.........................................GET
2.6.3............................PROPPATCH Method
2.6.4.........................................PUT
2.6.5......................................SEARCH
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 and Name Space
Operations
3.1 Observations on the HTTP Object Model
3.1.1........................Collection
3.1.1 Collection Resources
3.1.2Creation and Retrieval of Collection Resources
3.1.3.......Source
3.1.3 Source Resources and Output Resources
3.2 MKCOL Method
3.2.1.........................Problem
3.2.1 Problem Description
3.2.2.......................Solution
3.2.2 Solution Requirements
3.2.3.....................................Request
3.2.4....................................Response
3.2.5.....................................Example
3.2.3 Request
3.2.4 Response
3.2.5 Example
3.3 INDEX Method
3.3.1.........................Problem
3.3.1 Problem Description
3.3.2.......................Solution
3.3.2 Solution Requirements
3.3.3.................................The
3.3.3 The Request
3.3.4................................The
3.3.4 The Response
3.3.5 Response
3.3.5.......................Response Message Body
3.3.6.....................................Example
3.3.6 Example
3.4 Behavior of RFC 2068 Methods on Collections
3.4.1...................GET,
3.4.1 GET, HEAD for Collections
3.4.2........................POST
3.4.2 POST for Collections
3.4.3.........................PUT
3.4.3 PUT for Collections
3.4.4......................DELETE
3.4.4 DELETE for Collections
3.5 COPY Method
3.5.1.........................Problem
3.5.1 Problem Description
3.5.2.......................Solution
3.5.2 Solution Requirements
3.5.3.................................The
3.5.3 The Request
3.5.4................................The
3.5.4 The Response
3.5.5....................................Examples
3.5.5 Examples
3.6 MOVE Method
3.6.1.........................Problem
3.6.1 Problem Description
3.6.2.......................Solution
3.6.2 Solution Requirements
3.6.3.................................The
3.6.3 The Request
3.6.4................................The
3.6.4 The Response
3.6.5....................................Examples
3.6.5 Examples
3.7 Multi-Status Response
3.7.1..........................Problem Definition
3.7.2.......................Solution Requirements
3.7.3.......................Multi-Status Response
3.7.4.....................................Example
3.8 ADDREF Method
3.8.1..........................Problem
3.7.1 Problem Definition
3.8.2.......................Solution
3.7.2 Solution Requirements
3.8.3.................................The
3.7.3 The Request
3.9
3.8 DELREF Method
3.9.1..........................Problem
3.8.1 Problem Definition
3.9.2.......................Solution
3.8.2 Solution Requirements
3.9.3.................................The
3.8.3 The Request
3.10
3.9 PATCH Method
3.10.1.........................Problem
3.9.1 Problem Definition
3.10.2......................Solution
3.9.2 Solution Requirements
3.10.3................................The
3.9.3 The Request
3.10.4.........application/XML
3.9.4 application/XML elements for PATCH
3.10.5...............................The
3.9.5 The Response
3.10.6...................................Examples
3.11
3.9.6 Examples
3.10 Headers
3.11.1......................................Depth
3.11.2................................Destination
3.11.3....................Enforce-Live-Properties
3.11.4.......................Duplicate-Properties
3.11.5..................................Overwrite
3.11.6.............................Destroy
3.10.1 Depth
3.10.2 Destination
3.10.3 Enforce-Live-Properties
3.10.4 Duplicate-Properties
3.10.5 Overwrite
3.10.6 Destroy Header
3.11.7...................Collection-Member
3.10.7 Mandatory header
3.10.8 Collection-Member Header
3.12
3.11 Links
3.12.1..................Source
3.11.1 Source Link Property Type
4 State Tokens
4.1 Overview
4.1.1.........................Problem
4.1.1 Problem Description
4.1.2.......................Solution
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.3.1 If-State-Match
4.3.2 If-None-State-Match
4.4 State Token Header
4.5 E-Tags
5 Locking
5.1 Problem Description - Overview
5.1.1..................Exclusive
5.1.1 Exclusive Vs. Shared Locks
5.1.2............................Required
5.1.2 Required Support
5.2 LOCK Method
5.2.1...................................Operation
5.2.2The Effect
5.2.1 Operation
5.2.2Effect of Locks on Properties and Containers
5.2.3................Locking
5.2.3 Locking Replicated Resources
5.2.4..............Interaction
5.2.4 Interaction with other Methods
5.2.5....................Lock
5.2.5 Lock Compatibility Table
5.2.6................................Status
5.2.6 Status Codes
5.2.7.....................................Example
5.2.8....................Lock-Info
5.2.7 Example
5.2.8 Lock-Info Request Header
5.2.9........................Owner
5.2.9 Owner Request Header
5.2.10............................Time-Out
5.2.10 Time-Out Header
5.2.11.........................State-Token
5.2.11 State-Token Header
5.3 Write Lock
5.4 Lock Tokens
5.4.1.........................Problem
5.4.1 Problem Description
5.4.2...........................Proposed
5.4.2 Proposed Solution
5.4.3.......................Lock
5.4.3 Lock Token Definition
5.5 UNLOCK Method
5.5.1..........................Problem
5.5.1 Problem Definition
5.5.2.....................................Example
5.5.2 Example
5.6 Discovery Mechanisms
5.6.1.........................Lock
5.6.1 Lock Type Discovery
5.6.2.......................Active
5.6.2 Active Lock Discovery
6 Version Control
7 Internationalization Support
8 Security Considerations
9 Acknowledgements
10 References
11 Authors' Addresses
Appendix
1 - Content Type Application/XML
Syntax
XML element
Entity-Name
Close
XML Encoding
Markup Modifier
XML Syntax Shorthand
Appendix 2 - Parameter Syntax for Content-Type Application/XML
Schema Content-Type Parameter
Appendix 3 – URI Path Encoding
Problem Definition
Solution Requirement
Path Component
Appendix 4 - XML URI
Appendix 5 - XML elements
Ref XML element
Namespace
Namespace XML element
AS XML element
Required XML element
The XML URI and Namespace
1 Terminology
Collection 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 – Also known as small-chunk metadata, a hierarchical - A set of name/value pairs that describe contain descriptive
information about a resource.
Live Properties – - Properties whose semantics and syntax are
enforced by the server. For example, a live “read-only” "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” "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.
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” "metadata" and “attribute”. "attribute".
Properties are used within distributed authoring environments to
provide for efficient discovery and management of resources. For
example, a ‘subject’ 'subject' property might allow for the indexing of all
resources by their subject, and an ‘author’ '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
fully 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/attribute triples. name/value doubles. The name
of a property identifies the property’s property's syntax and semantics, and
provides an address with which to refer to a property. The name
and value of a property is an octet stream. The
attributes of a property are expressed as a set well-formed XML
element, where the name of name/value pairs that are
not directly addressable. Attributes are retrieved in conjunction
with retrieving a property, and are set when changing a property’s
value. This specification defines two attributes, live, which
indicates if the property’s syntax and semantics property is enforced by the server, name of the XML
element, and readonly, which indicates that the property’s value may of the property MUST be retrieved but not set. 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 and to be able to directly address
that value.
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 certainly ubiquitous.
Many
· The majority of databases use a fixed schema mechanism, which 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 should will not restrict RDBS from taking
full advantage of their search facilities.
However, it seems that future trends might be toward hierarchical
properties. As such, 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
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 for 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 A B but not a property A/B.
2.2.3 Property Attributes
The attributes of A/B, where is also a property provide information about
defined on the
property. Note that a property contains information about a resource.
Attributes consist of name/value pairs whose value MUST be a
string. Attributes are
Finally, it is not directly addressable, rather they
are retrieved and defined possible to define the same property twice as
this would cause a collision in the context resource's property
namespace.
2.3 Schemas
A schema is a group of other property
operations. For example, names and XML elements.
Schema discovery is used to determine if one retrieves a property value,
the attributes will also be returned. If one sets a property
value, one may also specify the values for its attributes.
All attributes on a server MUST be live. This means that the
server MUST only record attributes with syntax and semantics
the server understands and enforces. This normally means
that clients can not define new attributes on a property;
clients may only make use of the attributes supported by the
server.
If a client submits an attribute when setting a property
then the server MUST NOT record the property unless it
accepts the values specified for the corresponding
attributes. Thus, if a property value is submitted with a
live attribute then the server MUST NOT record the value
unless the server understands and enforces the syntax and
semantics of the property.
2.2.4 Schemas
A schema is a group of property names, attributes, and XML
elements.
It is often useful to indicate support for a particular
schema in a request or a response. Schema discovery is also
useful for determining if a system supports system supports a
group of
properties, attributes, 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.
2.3 DAV Schema
The DAV Schema is specified as
http://www.ietf.org/standards/dav/. This schema is used to
indicate
A resource declares its support for
properties and attributes that can be defined on a resource
and
XML elements that can be returned in responses.
All DAV compliant servers MUST support schema by defining a
property whose name is the DAV schema. same as the schema's. The property
SHOULD contain the PropSchema XML element.
2.3.1 Live Attribute PropSchema XML Element
Name: http://www.ietf.org/standards/dav/live http://www.ietf.org/standards/dav/PropSchema
Purpose: To indicate that the property has its syntax and
semantics enforced by the resource on which it is recorded. provide information about properties
Schema: http://www.ietf.org/standards/dav/
Parent: Any property
Values= “=” <”><”>
Description: This attribute is used to indicate that the
resource expressing the [DTD] [DefinedProps]
Description:This property understands and enforces
the syntax and semantics of contains the property. The absence definition of the
Live attribute in schema.
This definition consists of two parts. A DTD element that
contains a response indicates to the client DTD that
the corresponding property does not have its syntax declares all XML elements and
semantics enforced by DefinedProps
that defines any properties associated with the resource on which schema. As with
all XML it is recorded.
If a live attribute is included when setting the value of a
property then the server SHOULD set the property if the
property will be live and MUST NOT set the property if the
property will not possible to add extra XML elements. Therefore
schemas may define extra XML elements which are to be live. included
with their values.
2.3.2 ReadOnly Attribute DTD XML Element
Name: http://www.ietf.org/standards/dav/readonly http://www.ietf.org/standards/dav/DTD
Purpose: To indicate that a property can be retrieved, but
not set through contain the property mechanism. DTD for XML elements associated with the
schema.
Schema: http://www.ietf.org/standards/dav/
Parent: Any property
Values= “=” <”><”>
Description: This attribute is used to indicate that the
property can only be retrieved, not set through the property
mechanism. This attribute is not meant as an access control
mechanism but rather to reflect the fact that the property
is not designed to have its value set through the property
mechanism. If this attribute is included when setting the
value of a property, the request MUST be rejected since
accepting the value would violate ReadOnly attribute. A
server MUST NOT effect a property protocol element that is
inconsistent or ill-defined with respect to the element’s
attribute state, were it to be expressed.
Values: XML Declaration statements
2.3.3 Elements
2.3.3.1 Prop DefinedProps XML element Element
Name: http://www.ietf.org/standards/dav/prop http://www.ietf.org/standards/dav/DefinedProps
Purpose: To specify the name and value of contain a property list of properties defined by the schema.
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Values: PropName PropValue
2.3.3.2 PropName
Values= 1*PropEntries
2.3.4 PropEntries XML element Element
Name: http://www.ietf.org/stnadards/dav/name http://www.ietf.org/standards/dav/PropEntries
Purpose: To specify contain the name of a defined property, which MUST be a
URI.
Schema: http://www.ietf.org/standards/dav/
Parent: Prop
Values: URI
2.3.3.3 PropValue XML element
Name: http://www.ietf.org/standards/dav/propvalue
Purpose: To specify the value DTD of a property.
its value, and its live/dead status.
Schema: http://www.ietf.org/standards/dav/
Parent: DefinedProps
Values= Prop
Values: The contents [DTD] [Live]
Description:Prop contains the name of a the property.
2.4 Property Identifiers
2.4.1 Problem Definition The addition DTD
contains the DTD of DAV properties to the HTTP object model
introduces property's value. Live, if defined,
indicates that the need for a mechanism to unambiguously refer
to either property has semantics and syntax that are
enforced by the body of server.
2.3.5 Live XML Element
Name: http://www.ietf.org/standards/dav/Live
Purpose: If present this indicates the resource or server MUST enforce the properties
syntax and semantics of a
resource.
2.4.2 Solution Requirement the property.
Schema: http://www.ietf.org/standards/dav/
Parent: PropEntries
2.4 DAV Schema
The mechanism DAV Schema is specified as
http://www.ietf.org/standards/dav/. This schema is used for referring to the
indicate support for
· properties that may be defined on a resource body must
also and
· XML elements that may be usable returned in responses.
2.4.1 DAV Property
Name: http://www.ietf.org/standards/dav
Purpose: Defines support for referring to the resource’s properties,
such that even non-DAV aware clients can retrieve DAV
properties.
2.4.3 schema and protocol.
Schema: http://www.ietf.org/standards/dav/
Values= PropSchema Level
Description:This property indicates that the resource supports
the DAV URL Parameter 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 allow for indicate the specification level of property information in DAV compliance the context resource
meets.
Schema: http://www.ietf.org/standards/dav/
Parent: DAV
Values= "1" | "2" | "3"
Description:A value of an http scheme URL, a switch is needed. The
switch 1 for level indicates that following path segments specify a
property location. To this end the “DAV” param is introduced
for use with http scheme URLs. The path segment to resource
supports the right property and namespace sections of the DAV param MUST be formatted according to
specification. Level 2 indicates that the XML Link
standard, described in Appendix 3.
2.4.4 Name Encoding
Properties on a resource are given URIs as a name. Thus, in
order to be able to refer to a property one must be able to
put supports level
1 and the property’s URI into an HTTP URI.
For example, lock section of the author property specification, with full name
http://www.w3.org/standards/z39.50/author is defined on
http://somewhere.com/resource.
To create a reference to minimum
locking capability of the author one would perform write lock. Level 3 indicates support
for levels 1 and 2 as well as support for the
following steps.
Add versioning section
of the DAV parameter to the base URI,
http://somewhere.com/resource;DAV.
Add “/” specification.
2.4.3 Prop XML element
Name: http://www.ietf.org/standards/dav/prop
Purpose: Contains properties related to refer 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 root 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 resource’s property
namespace, http://somewhere.com/resource;DAV/.
Change location of the author property’s name into parameter format by
changing “/”s 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 “!”s and encasing specify the entire value in
parenthesis. URL of the property on the
associated resource. The value must PropLoc attribute MUST NOT be encased in parenthesis used in
order to indicate the “/” to “!” translation.
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
translation “/” to “!” is done in order to prevent
confusion over segments boundaries, and to make sure previous specifies that the syntax for relative URIs remains well-defined.
http://somewhere.com/resource;DAV/(http:!!www.w3.org!stand
ards!z39.50!author).
The process is now complete, property author exists on some
unspecified resource and that the URL property can be used in a
GET or PATCH to retrieve or alter the value. See appendix 3
for more information.
2.4.5 Compatibility with legacy systems
2.4.5.1 Problem Definition directly
referenced at http://www.foo.com/resource/props/Author. The HTTP parameter space
resource upon which the property is uncontrolled, thus someone may
already defined must be using a parameter with a value of “DAV” for some
end other than the one described here. Thus a client sending
a URI with a determined
from context.
2.5 Property Identifiers
2.5.1 Problem Definition
DAV param to a server properties are resources and thus may receive have a URI where the
value of an unexpected
or inappropriate response.
2.4.5.2 Solution Requirement
A mechanism instance of the property may be retrieved. This URI
is needed to prevent namespace collisions.
2.4.5.3 Proposed Solution
All DAV compliant servers MUST honor separate from the DAV param type URI name of the property, which identifies
the syntax and semantics of the property, but which does not give
information on
http URLs. Thus if a client knows it is talking how to a DAV
server, it can safely send an http URL with the DAV param.
The client may send access the http URL with value of an instance of the DAV param
extension
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 that
is free not known to be DAV compliant
if reveal the URI of an instance of a particular
resource and instead require that the client uses PEP [Connolly, 1997] to prevent
collisions. The proper PEP header is:
DAVPEP = “PEP: {{map “DAV”}{strength must}}”
Note: this PEP header is not compliant with [Connolly,
1997]; access the PEP authors have indicated they property
through PROPFIND and PROPPATCH. However, many servers will change the
format want
to make allow clients to directly manipulate properties. On these
servers, a client can discover the example legal.
2.5 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.5.1
2.6.1 Problem Description
A mechanism is needed to associate resources with other
resources. These associations, also 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.5.2
2.6.2 Solution Requirements
The association mechanism MUST make use of the DAV property
mechanism in order to make the existence of the associations
searchable.
2.5.3
2.6.3 Link XML Element
Name: http://www.ietf.org/standards/dav/link
Purpose: The XML document which is To identify a property as a link and to contain the value
source and destination of a that link.
Schema: http://www.ietf.org/standards/dav/
Values= An XML document which MUST have a src and dst XML
element.
Description: Link 1*Src 1*Dst
Description:Link is used to provide the source sources and one or
more destinations
of the a link. The type of the property containing the Link XML
element provides the type of the link. Link is a multivalued
element,so multi-valued
element, so multiple Links may be used together to indicate
multiple links with the same type.
2.5.4
2.6.4 Src XML Element
Name: http://www.ietf.org/standards/dav/src
Purpose: To indicate the source of a link.
Schema: http://www.ietf.org/standards/dav/
Parent: http://www.ietf.org/standards/dav/link
Values= URI
2.5.5
2.6.5 Dst XML Element
Name: http://www.ietf.org/standards/dav/Dst
Purpose: To indicate one or more destinations the destination of a link
Schema: http://www.ietf.org/standards/dav/
Parent: http://www.ietf.org/standards/dav/link
Values= URI
2.5.6
2.6.6 Example
<XML>
<Namespace><Ref>http://www.ietf.org/standards/dav/</><A
S>D</></>
<?XML:Namespace
href = "http://www.ietf.org/standards/dav/" AS = "D"/>
<?XML:Namespace
href = "http://www.foocorp.com/Project/" AS = "F"/>
<D:Prop>
<Propname>Source</>
<Propvalue>
<XML:XML>
<Namespace>
<Ref>http://www.ietf.org/standards/
dav/</><AS>D</>
</>
<Namespace>
<Ref>http://www.foocorp.com/Project
/</><AS>F</>
</>
<D:Link>
<F:ProjectFiles>Source</>
<src>http://foo.bar/program</>
<dst>http://foo.bar/source/main.c</>
</>
<D:Link>
<F:ProjectFiles>Library</>
<src>http://foo.bar/program</>
<dst>http://foo.bar/source/main.lib</>
</>
<D:Link>
<F:ProjectFiles>Makefile</>
<src>http://foo.bar/program</>
<dst>http://foo.bar/source/makefile</>
</> </> </> </> </>
<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 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 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 the expected source and destination links. An
enhanced client may know about the foocorp elements and be able
to present the user with additional information about the links.
2.6 Properties and Methods
2.6.1 DELETE
2.7 Multi-Status Response
2.7.1 Problem Definition
Some methods effect more than one resource. The delete method, when used on a property, causes effect of the
property to be removed.
2.6.2 GET
A GET
method on a property returns the name each of the property. Accept
types scoped resources may be used to different, as such
a return format that can specify the format effect of the method on each
resource is needed.
2.7.2 Solution Requirements
The solution must:
- communicate the status code and reason
- give the URI of the resource on which the method was invoked
- be consistent with other return value,
but all DAV compliant servers body formats
-
2.7.3 Multi-Status Response
The default multi-status response body is an text/xml HTTP entity
that contains a single XML element called multiresponse, which
contains a set of XML elements called response, one for each 200,
300, 400, and 500 series status code generated during the method
invocation. 100 series status codes MUST NOT be recorded in 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 minimum support the top level is used to
provide a
return type general message describing the over arching nature of application/XML.
the response. If application/XML this value is used
as available an application MAY use
it instead of presenting the individual response format then it MUST include descriptions
contain within the
http://www.ietf.org/standards/dav/ schema.
2.6.2.1 Example
GET bar;DAV/(http:!!www.w3.org!standards!z39.50!Authors)
HTTP/1.1
Host: foo.com
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: xxxx
E-tag: “1234”
Last-Modified: xxxx
<XML>
<XML:Namespace><Ref>http://www.ietf.org/standards/dav/<
/><AS>D</></>
<XML:Namespace><Ref>http://www.w3.com/standards/z39.50/
</><AS>Z</></>
<D:prop>
<propname>Z:Authors</>
<propvalue>
<XML:XML>
<Namespace>
<Ref>http://www.ietf.org/standards/
dav/</>
<AS>D</>
</>
<Namespace>
<Ref>http://www.w3.com/standards/z39.50/
</>
<AS>Z</>
</>
<Z:Author>Jane Doe</>
<Z:Author>Joe Doe</>
<Z:Author>Lots o’Doe</>
</> </> </> </>
GET bar;DAV/(Dublin:Producer) HTTP/1.1
Host: foo.com
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: xxxx
E-tag: “2345”
Last-Modified: xxxx
<XML>
<XML:Namespace><Ref>http://www.ietf.org/standards/dav/<
/><AS>D</></>
<XML:Namespace><Ref>Dublin</><AS>Du</></>
<D:prop>
<propname>Du:Producer</>
<propvalue><XML:XML>Marcus Doe</></>
</> </>
GET bar;DAV/ HTTP/1.1
Host: foo.com
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: xxxx
E-tag; “1234”
Last-Modified: xxxx
<XML>
<XML:Namespace><Ref>http://www.ietf.org/standards/dav/<
/><AS>D</></>
<XML:Namespace><Ref>http://www.w3.com/standards/z39.50/
</><AS>Z</></>
<XML:Namespace><Ref>Dublin</><AS>Du</></>
<D:prop>
<propname>Z:Authors</>
<propvalue>
<XML:XML>
<Namespace>
<Ref>http://www.ietf.org/standards/
dav/</>
<AS>D</>
</>
<Namespace>
<Ref>http://www.w3.com/standards/z39.50/
</>
<AS>Z</>
</>
<Z:Author>Jane Doe</>
<Z:Author>Joe Doe</>
<Z:Author>Lots o’Doe</>
</> </> </>
<D:prop>
<propname>Du:Producer</>
<propvalue><XML:XML>Marcus Doe</></>
</> </>
2.6.3 PROPPATCH Method
The PROPPATCH method specifies how to alter a property. The
message body controls the actual action taken by responses.
2.7.3.2 Response
Name: http://www.ietf.org/standards/dav/response
Purpose: Holds a
PROPPATCH. All DAV compliant servers are required to support 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 the use name of properties. Multiple properties may be
included if the application/XML content-type using same response applies to them all. If HREF is
used then the
http://www.ietf.org/standards/dav/proppatch/ schema in response refers to a
PROPPATCH method problem with a request-URI that points to the
resource upon which the property is defined.
The changes in a http://www.w3.com/standards/dav/proppatch/
request MUST be atomically executed, partial results are referenced
resource, not
allowed.
2.6.3.1 Request URI
The request URI of a PROPPATCH method with the
http://www.ietf.org/standards/dav/proppatch/ schema MUST
point to the resource upon which the property is defined.
2.6.3.2 PropertyUpdate XML element property.
2.7.3.3 Status
Name: http://www.ietf.org/standards/dav/PropertyUpdate http://www.ietf.org/standards/dav/status
Purpose: To contain Holds a request 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 be displayed to alter the properties on a
resource. user
explaining the nature of the response.
Schema: http://www.ietf.org/standards/dav/
Parent: <XML>
Values= *(Create | Remove | Insert) Multiresponse and/or Response
Value: Any
Description: This XML element is a container for the provides information required suitable to modify the
be presented to a user.
2.8 Properties and Methods
2.8.1 DELETE
As properties on the
resource. This XML element is multivalued.
2.6.3.3 Create XML element
Name: http://www.ietf.org/standards/dav/create
Purpose: To create are resources, the DAV deletion of a property specified inside causes
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 contains a Prop same result as the only
element. The PropName contains deletion of any resource. It is worth
pointing out that the name deletion of a property effects both direct
manipulation, that is by the property's URL, as well as indirect
discovery and manipulation, that is PROPPATCH and PROPFIND.
2.8.2 GET
A GET with a Request-URI that identifies a property to
be created or overwritten. The PropValue XML element
contains returns the
name and value of the new that property.
2.6.3.4 Remove XML element
Name: http://www.ietf.org/standards/dav/remove
Purpose: To remove Accept types may be used to
specify the format of the return value, but all DAV compliant
servers MUST at minimum support a return type of text/xml. If
text/xml is used as the response format then it MUST return the
name and value of the property specified inside using the
Remove Prop XML element.
Schema: http://www.ietf.org/standards/dav/
Parent: http://www.ietf.org/standards/dav/PropertyUpdate
Values= PropName
Description: Remove specifies
2.8.2.1 Example
The following example assumes that the property specified in
PropName should be removed. Specifying property's URL, originally
generated by the removal of server, was discovered by examining the proploc
XML attribute returned on a
property that does not exist is not an error.
2.6.3.5 Response Codes 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
The command succeeded. As there can be a mixture of
PUT and DELETEs PROPPATCH method processes instructions specified in a body, a 201 Create seems inappropriate.
400 Bad Request – The client has provide a value whose
syntax is illegal for the property.
401 Unauthorized – The client does not have authorization
request body to
alter one of create and/or remove properties defined on the properties. This error also occurs if a
property is inherently read only.
403 Forbidden – The client, for reasons
resource identified by Request-URI.
All DAV compliant servers MUST process instructions which are
specified using the server chooses
not to specify, can not alter one PropertyUpdate, Create, and Remove XML
elements of the properties.
405 Conflict – DAV schema. The client has provided a value whose
semantics are not appropriate for the property.
413 Request Entity Too Long – If a particular property is
too long to be recorded then a composite request message body MUST
contain at least one PropertyUpdate XML error will be
returned indicating the offending property.
2.6.3.6 Example
PROPPATCH bar;DAV/ HTTP/1.1
Host: www.foo.com
Content-Type: application/XML
Content-Length: xxxx
<XML>
<Namespace><Ref>http://www.ietf.org/standards/dav/</><A
S>D</></>
<Namespace><Ref>http://www.w3.com/standards/z39.50/</><
AS>Z</></>
<D:PropertyUpdate>
<Create><prop>
<propname>Z:authors</>
<propvalue>
<XML:XML>
<Namespace>
<Ref>http://www.ietf.org/standards/dav/proppatch/</>
<AS>D</>
</>
<Namespace>
<Ref>http://www.w3.com/standards/z39.50/</>
<AS>Z</>
</>
<Z:Author>Jim Whitehead</>
<Z:Author>Roy Fielding</>
</>
</>
<Remove><propname>Z:Copyright-Onwer</></>
</> </>
2.6.4 PUT
A PUT is specified element. Instruction
processing MUST occur in the order instructions are received
(i.e., from top to control what is returned by a
GET. However bottom), and MUST be performed atomically.
2.8.3.1 PropertyUpdate XML element
Name: http://www.ietf.org/standards/dav/PropertyUpdate
Purpose: To contain a GET request to alter the properties on a property always returns some sort of
property containment format. As such PUT can not be used if
the Request-URI refers to
resource.
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Values= *(Create | Remove)
Description:This XML element is a property.
2.6.5 SEARCH
2.6.5.1 Request-URI
The request-URI of container for the search method is information
required to modify the URI of properties on the resource. .
The Depth header MUST NOT be used on a SEARCH method which
contains a Limited-Search This XML
element (“limited search”).
2.6.5.2 Command Format
The message body stipulates the action of a SEARCH method.
This section defines an application/xml content type using
the http://www.ietf.org/standards/dav/ schema. This method is not normally cacheable.
2.6.5.2.1 Limited-Search multi-valued.
2.8.3.2 Create XML element
Name: http://www.ietf.org/standards/dav/limited-search http://www.ietf.org/standards/dav/create
Purpose: To specify create the set of matching DAV properties specified inside the
Create XML element.
Schema: http://www.ietf.org/standards/dav/
Parent: <XML>
Values: The value is a single OR http://www.ietf.org/standards/dav/PropertyUpdate
Values= Prop
Description:This XML element. The OR element
may only contain AND XML elements, and MUST contain at least
one AND element.
Description: This property indicates a very limited search.
The search may only be on HTTP properties.
2.6.5.2.2 OR XML element
Name: http://www.ietf.org/standards/dav/or
Purpose: To take its members, evaluate them, get a true or
false result, “or” the results together, and have that be
the total result.
Schema: http://www.ietf.org/standards/dav/
Parent: Limited-Search XML element
Values: AND Prop XML
element.
2.6.5.2.3 AND XML element
Name: http://www.ietf.org/sandards/dav/and
Purpose: To take its members, evaluate them, get a true or
false result, “and” The elements contained by Prop specify the results together, name and have
value of properties that be
the total result.
Schema: http://www.ietf.org/standards/dav
Parent: OR are created on Request-URI. If a
property already exists then its value is replaced. The Prop XML
element
Values: Zero or one Name XML element, and zero or one Value
XML element. There MUST be at least one Name or Value NOT contain a PropLoc XML
element.
2.6.5.2.4 Name attribute.
2.8.3.3 Remove XML element
Name: http://www.ietf.org/standards/dav/name http://www.ietf.org/standards/dav/remove
Purpose: To provide a pattern against which property names
are to be compared. If remove the name matches then DAV properties specified inside the property
evaluates to true, otherwise false.
Remove XML element.
Schema: http://www.ietf.org/standards/dav/
Parent: AND XML element
Values: Match-Stream
2.6.5.2.5 Value XML element
Name: http://www.ietf.org/standards/dav/value
Purpose: To provide a pattern against which property values
are to be compared. If http://www.ietf.org/standards/dav/PropertyUpdate
Values= Prop
Description:Remove specifies that the value matches then properties specified in
Prop should be removed. Specifying the removal of a property
evaluates to true, otherwise false.
Schema: http://www.ietf.org/standards/dav/
Parent: AND XML element
Values: Match-Stream
2.6.5.2.6 Match-String XML element
Name: http://www.ietf.org/standards/dav/match-string
Purpose: To specify a search pattern to be matched against
an octet stream
Schema: http://www.ietf.org/standards/dav/
Parent: Name or Value XML element
Values: (“*” | “?” | EncodedOctet)
EncodedOctet = <An EncodedOctet uses XML encoding to encode
“*” and “?” as well as “<” and “>”
Description: This element provides a template against which
anything that can
does not exist is not an error. All the elements in Prop MUST be expressed
empty, as an octet stream may only the names of properties to be
compared. “*” is a wildcard that matches zero or more
unspecified contiguous octets. “?” is a wildcard that
matches exactly one unspecified octet.
2.6.5.3 removed are
required.
2.8.3.4 Response Format
The response is an application/xml message MUST have a response body which that contains a single SearchResult XML element whose contents
are a series of XML elements representing matching
properties.
2.6.5.3.1 SearchResult XML element
Name: http://www.ietf.org/standards/dav/searchresult
Purpose: To contain
multiresponse identifying the results of for each property.
2.8.3.5 Response Codes
200 OK - The command succeeded. As there can be a SEARCH request
Schema: http://www.ietf.org/standards/dav/
Parent: Any, usually <XML>
Values: Zero or more Prop XML elements (defined mixture of
Create and Removes in
Properties draft)
Description: a body, a 201 Create seems inappropriate.
403 Forbidden - The SearchResult XML element provides client, for reasons the
context server chooses not to inform
specify, can not alter one of the properties.
405 Conflict - The client that its contents has provided a value whose semantics
are not just
some XML element, but an appropriate for the property. This includes trying to set
read only properties.
413 Request Entity Too Long - If a particular property is too
long to be recorded then a composite XML representation of error will be returned
indicating the requested offending property.
2.6.5.4 Example
SEARCH /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: application/xml
<XML>
<XML:Namespace>
<Ref>http://www.ietf.org/standards/dav/</>
<AS>S</>
</>
<S:limited-search>
<OR>
<AND>
<Name>*</>
</>
</>
</>
</>
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: xxxxx
<XML>
<XML:Namespace>
<Ref>http://www.ietf.org/standards/dav/</>
<As>S</>
</>
<XML:Namespace>
<Ref>http://www.foo.bar/boxschema</>
<AS>R</>
</>
<S:SearchResult>
<Prop>
<PropName>R:bigbox</>
<PropValue>
<XML:XML>
<BoxType>Box type A</>
</>
</>
</>
<Prop>
<PropName>R:author</>
<PropValue>
<XML:XML>
<Name>J.J.
Dingleheimerschmidt</>
</>
</>
</>
</>
</>
The result will return all properties on the container and
its members. In this case only two properties were found,
one on the container and one on one of its members, both
properties are live.
3 A Proposal for Collections of Web Resources and Name
417 Insufficient Space Operations
3.1 Observations on the HTTP Object Model
As a prerequisite for specification of collections and name Resource - The resource does not have
sufficient space operations for to record the Web, a model for collection
resources and for namespace topology must be given. This
section describes a new type state of Web resource, the collection
resource, and provides a model for discussing the
relationship between the resources that are generated as resource after the
result
execution of a data-producing process, and this method.
418 Atomicity Failure - The command was not executed because of
an atomicity failure elsewhere the source resources
that describe caused the process.
3.1.1 Collection Resources entire command 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 collection PUT is a Web resource type whose primary state specified in order to control what is returned by a
set of URIs and associated values that are recorded as
properties GET.
However a GET on a property always returns a predefined property
containment format. Therefore PUT can not be used if the resource. Request-
URI refers to a property.
2.8.5 PROPFIND
The URIs identify resources PROPFIND method retrieves properties defined on Request-URI.
The request message body is an XML document that are members of MUST contain
only one PropFind XML element, which specifies the collection. type of
property find action to be performed. The values associated
with each URI include information such as XML element contained
by PropFind specifies the Last Modified
Date, Entity Tag, Creation Date, Content Type, Display Name, type of action to be performed:
retrieve all property names and whether the member is values (AllProp), retrieve only
specified property names and values (Prop), or retrieve only a collection.
A member
list of all property names (Propname). When a collection Prop XML element
is either an internal member
resource, which MUST have present, it specifies a URI that is relative to the base
URI list of the collection, or an external member resource, which
has a URI which is not relative to the base URI names of the
collection. External member resources properties whose
name and value are further subdivided
into propagate members, which have recursive method
invocations propagated to them, and no-propagate members,
which do not.
A collection resource may be viewed and returned. The Prop element, when used as
within a compound
resource in which the collection FINDPROP request body MUST be empty.
The response is a container for a group
of related resources that, together, form a larger logical
unit. For example, text/xml message body that contains a collection of HTML resources where
each resource is
MultiResponse XML element which describes the chapter results of the
attempts to retrieve the various properties. If a book can property was
successfully retrieved then its value MUST be viewed as a
compound resource representing returned in the entire book.
Some methods, when invoked on a collection, affect
prop XML element. In the
entire collection. For example, it is possible to copy an
entire collection case of Allprop and its contents with just a single copy
method request. The model for performing these operations is Findprop, if a tree traversal. The method is invoked on the collection,
which then performs the method on itself before propagating
principal does not have the method right to all its internal members and propagate
external members. If these are non-collection resources,
the request method is processed. However, know if the request is
propagated to another collection, then the propagation
begins again. This sequence a particular
property exists, an error MUST NOT be returned. The results of actions causes the
this method to SHOULD NOT be propagated as a tree traversal of cached.
2.8.5.1 Propfind XML element
Name: http://www.ietf.org/standards/dav/Propfind
Purpose: To specify the members set of the
collections. It matching properties
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Values= (Prop | Allprop | Propname)
Description: Propfind is incumbent upon the client to perform any
locking operation on a container element for the collection or subordinate members exact
specification of a PROPFIND request.
2.8.5.2 Allprop
Name: http://www.ietf.org/standards/dav/Allprop
Purpose: To specify that it deems necessary in order all properties are to maintain state
consistency during be returned
Schema: http://www.ietf.org/standards/dav/
Parent: Propfind
Description: Its presence in a PROPFIND request specifies the execution of such methods.
3.1.2 Creation
name and Retrieval value of Collection Resources
Since all properties defined on the existing HTTP methods for creating (PUT, POST) and
retrieving (GET) a resource were defined for non-collection
resources, it is not surprising MUST be
returned.
2.8.5.3 Propname
Name: http://www.ietf.org/standards/dav/Propname
Purpose: To specify that the semantics names of these
methods do not transfer well to collections. For example,
the PUT method is all properties defined to store on
the request entity under
the Request-URI. While a description format for a
collection can readily be constructed that could be used
with PUT, the implications of sending such a description to
the server resource 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 returned.
Schema: http://www.ietf.org/standards/dav/
Parent: Propfind
Description: Its presence in a command to
remove those members. This would extend PUT to perform
DELETE functionality, which is undesirable since it changes PROPFIND request specifies the semantics
name of PUT, and makes it difficult to control
DELETE functionality with an access control scheme based all properties defined 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 resource MUST be difficult to provide
separate access control for collection creation and other
uses of POST if they both use returned.
2.8.5.4 PropFindResult XML element
Name: http://www.ietf.org/standards/dav/PropFindResult
Purpose: To contain the same method. results 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 Partial 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">
<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 GET method when applied to collections is also
problematic. While it might seem desirable to user does not have GET access to
the DingALink property. </ResponseDescription>
</Response>
</D:MultiResponse>
The result will return a listing of all properties on the members of a collection, container. In this is
foiled by the existence of the “index.html” de-facto
standard namespace redirection, in which a GET request on a
collection is automatically redirected
case only two properties were found. The principal did not have
sufficient access rights to see the index.html
resource.
Because of the difficulty of reusing some existing third and fourth properties
so an error was returned.
2.8.5.6 Example 2 - Allprop
PROPFIND /container/ HTTP/1.1
methods for collections, two new resource creation/retrieval
methods are needed.
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 specification introduces the MKCOL
method for creating collection resources, and the INDEX
method for retrieving the contents of a collection.
The exact definition of particular client only had the behavior of GET right to see two properties,
BoxType and PUT on
collections Author. No error is defined later in this draft.
3.1.3 Source Resources and Output Resources
For many resources, the entity returned by GET exactly
matches the persistent state of the resource, for example, a
GIF file stored on a disk. For this simple case, the URL at
which a resource is accessed is identical to the URL at
which remaining
properties, as the source (the persistent state) of client does not even have sufficient rights to
know they exist. If the resource is
accessed. This is also client did have the case for HTML source files that
are right to know they
existed but did not processed by have the server prior right to transmission.
However, HTML files can sometimes be processed by the server
before being transmitted as see their value, a return entity body. Server-
side-include directives within an HTML file instruct 201
Partial Success with a
server to replace the directive with another value, such multiresponse, as used in the current date. 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, what is returned by GET
(HTML plus date) differs from the persistent state case only two of the
resource (HTML plus directive). Typically there is no way to
access the HTML file containing the unprocessed directive.
Sometimes the entity returned by GET is the output of a
data-producing process that is described by one or more
source resources (that may not even properties have a location in direct URLs
available, while the
URL namespace). other two properties can only be referenced
via PROPFIND and PROPPATCH.
3 A single data-producing process may
dynamically generate the state Proposal for Collections of Web Resources and Name Space
Operations
3.1 Observations on the HTTP Object Model
As a potentially large number
of output resources. An example prerequisite for specification of this is collections and name space
operations for the Web, a CGI script that model for collection resources and for
namespace topology must be given. This section describes a "finger" gateway process that maps part new
type of Web resource, the
namespace of collection resource, and provides a server into finger requests, such as
http://www.foo.bar.org/finger_gateway/user@host.
In
model for discussing the absence of distributed authoring capability, relationship between the fact resources that the source resource(s) for server
are generated output do
not have a mapping to as the URI namespace is not result of a problem, data-producing process, and has desirable security benefits. However, if remote
editing of the
source resource(s) resources that describe the process.
3.1.1 Collection Resources
A collection is desired, they should be
given a location in Web resource type whose primary state is a set
of URIs and associated values that are recorded as properties on
the URI namespace. This source location
should not be one resource. The URIs identify resources that are members of
the locations at which collection. The values associated with each URI include
information such as the generated
output is retrievable, since in general it is impossible for Last Modified Date, Entity Tag, Creation
Date, Content Type, Display Name, and whether the server to differentiate requests for source resources
from requests for process output resources. There member is often a
many-to-many relationship between source resources and
output resources.
For DAV compliant servers all output resources
collection.
A member of a collection is either an internal member resource,
which MUST have a
single source resource (and URI that source resource is relative to the base URI of the
collection, or an external member resource, which has a URI), URI which
is not relative to the base URI of the source collection. External
member resources are further subdivided into propagate members,
which have recursive method invocations propagated to them, and
no-propagate members, which do not.
A collection resource SHOULD may be stored in viewed and used as a single
link on the output compound
resource with type DAV:/ Source. Note
that by storing the source URI in links on the output
resources, the burden of discovering which the source collection is placed on
the authoring client.
In the general case, a large number container for a group of source
related resources can
comprise that, together, form a data-producing process that generates many output
resources, creating larger logical unit.
For example, a many-to-many relationship between
output collection of HTML resources and source resources. If where each output
resource had links back to every source resource in
is the
data-producing process, there chapter of a book can be viewed as a potentially large
number of such links. Due to the potentially large number of
links, and compound resource
representing the lack of entire book.
Some methods, when invoked on a policy for ordering access to
multiple sources, explicit storage of source relationships collection, affect the entire
collection. For example, it is limited possible to cases copy an entire
collection and its contents with only just a single source resource.
3.2 MKCOL Method
3.2.1 Problem Description copy method
request. The client needs a way to create model for performing these operations is a collection.
3.2.2 Solution Requirements tree
traversal. The solution:
Must ensure that a collection has been made (i.e. that it
responds to method is invoked on the INDEX method) as opposed collection, which then
performs the method on itself before propagating the method to a non-
collection resource.
all its internal members and propagate external members. If a collection could not be made, it
must indicate a failure to the principal.
Requires that
these are non-collection resources, the server MAY, request method is
processed. However, if necessary, create any
intermediate collections so that the underlying storage
medium request is self-consistent.
3.2.3 Request
The MKCOL propagated to another
collection, then the propagation begins again. This sequence of
actions causes the method creates to be propagated as a new collection resource at tree traversal of
the
location specified by members of the Request-URI. If collections. It is incumbent upon the Request-URI
exists then MKCOL must fail.
During MKCOL processing, a server MAY add the Request-URI client
to
one or more collections within the server’s controlled
namespace.
3.2.3.1 MKCOL Without Request Body
When MKCOL is invoked without a request body then perform any locking operation on the collection created has no members.
3.2.3.2 MKCOL With Request Body
A MKCOL request message MAY contain a message body. The
behavior of a MKCOL request when the body is present is
limited to creating collections, or subordinate
members that it deems necessary in order to maintain state
consistency during the execution of a collection,
bodies of members such methods.
3.1.2 Creation and properties on the collections or
members. If Retrieval of Collection Resources
Since the server receives existing HTTP methods for creating (PUT, POST) and
retrieving (GET) a MKCOL request entity type resource were defined for non-collection
resources, it does is not support or understand it MUST respond with a 415
(Unsupported Media Type) status code.
3.2.3.3 Creating Multiple Collections
The server MAY create intermediate collections if they surprising that the semantics of these
methods do not already exist. transfer well to collections. For example, if the PUT
method is defined to store the request entity under the Request-
URI. While a description format for a collection
http://server/a/ already exists in can readily be
constructed that could be used with PUT, the server’s namespace,
then while performing implications of
sending such a MKCOL description to create http://server/a/b/c/ the server may also create are undesirable. For
example, if a description of a collection at
http://server/a/b/.
3.2.4 Response
Responses from that omitted some
existing resources were PUT to a MKCOL request are not cacheable, since
MKCOL has non-idempotent semantics.
201 (Created) - The structured resource was created in its
entirety.
403 (Forbidden) - The server does not allow the creation of
collections at the given location in its namespace.
415 (Unsupported Media Type)– The server does not support
the request type of the body.
416 (Unprocessable Entity) - A new status code. The server
understands 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 content type semantics of the request entity, but was
unable PUT, and makes it difficult to process the contained instructions.
3.2.5 Example
This example creates a container collection called
/webdisc/xfiles/
control DELETE functionality with an access control scheme based
on methods.
While the server www.server.org.
MKCOL /webdisc/xfiles/ HTTP/1.1
Host: www.server.org
HTTP/1.1 201 Created
3.3 INDEX Method
3.3.1 Problem Description
A mechanism POST method is needed to discover if sufficiently open-ended that a resource is "create a
collection" POST command could be constructed, this is
undesirable because it would be difficult to provide separate
access control for collection creation and other uses of POST if so, list its members.
3.3.2 Solution Requirements
they both use the same method.
The solution:
must allow a client GET method when applied to discover collections is also problematic.
While it might seem desirable to have GET return a listing of the
members of a collection
must always provide a machine-readable description of collection, this is foiled by the
membership existence of the
"index.html" de-facto standard namespace redirection, in which a collection
3.3.3 The Request
The INDEX method returns
GET request on a machine-readable representation collection is automatically redirected to the
index.html resource.
Because of the membership difficulty of the reusing some existing HTTP/1.1
methods for collections, two new resource at creation/retrieval
methods are needed. This specification introduces the MKCOL
method for creating collection resources, and the Request-URI. For a
collection, INDEX MUST return method
for retrieving the contents of a machine-readable list collection.
The exact definition of its
members. the behavior of GET and PUT on
collections is defined later in this draft.
3.1.3 Source Resources and Output Resources
For other many resources, the information entity returned by
INDEX is undefined, and MAY vary. The request message body
of an INDEX request SHOULD be ignored.
The Depth header can be used to indicate how much GET exactly matches
the persistent state of a
result can be generated for the response. The specific
values allowed resource, for example, a GIF file
stored on a disk. For this simple case, the depth header when used with the INDEX
method are 1 and infinity. The 1 value indicates that the
internal and external member resources should be reported in URL at which a
resource is accessed is identical to the result, infinity indicates that all internal and
external member resources and all their descendants should
be in URL at which the result. If source
(the persistent state) of the Depth header resource is not given, then 1 accessed. This is assumed. Servers MUST honor a depth of 1. Servers MAY
honor infinity. If also
the server does case for HTML source files that are not support processed by the value of
server prior to transmission.
However, HTML files can sometimes be processed by the depth header then server
before being transmitted as a 412 (Precondition failed) MUST be
returned.
3.3.4 The Response
200 (OK) – The server MUST send an application/xml response return entity which describes body. Server-side-
include directives within an HTML file instruct a server to
replace the collection.
404 (Not Found) - Same behavior directive with another value, such as HTTP 1.1. The server
never had the resource, or current
date. In this case, what is returned by GET (HTML plus date)
differs from the server permanently deleted persistent state of the resource and has (HTML plus
directive). Typically there is no knowledge that it ever existed. This
error code implies that, essentially, way to access the server has no
information about HTML file
containing the unprocessed directive.
Sometimes the Request URI.
3.3.5 Response Message Body
The default INDEX response for a resource is an
application/xml HTTP entity (i.e., an Extensible Markup
Language (XML) document) returned by GET is the output of a data-
producing process that contains is described by one or more source
resources (that may not even have a location in the URL
namespace). A single XML element
called collectionresource which describes data-producing process may dynamically
generate the collection,
and state of a set potentially large number of XML elements called memberesource which
describe the members output
resources. An example of the collection.
The response from INDEX this is cacheable, and SHOULD be
accompanied by an ETag header (see section 13.3.4 a CGI script that describes a
"finger" gateway process that maps part of RFC
2068). If GET and INDEX return different entities for the
same resource state, they MUST return different entity tags.
The server MUST transmit the following XML elements for each
member resource namespace of a collection: Ref, IsCollection, Content-
Type, External. The
server MUST transmit into finger requests, such as
http://www.foo.bar.org/finger_gateway/user@host.
In the following XML
elements if it can generate any meaningful values absence of distributed authoring capability, the fact that
the source resource(s) for them:
Creation-Date, Last-Modified, DisplayName, Content-Language.
The server SHOULD transmit Etag XML elements for each
member (see section 13.3.4 of RFC 2068).
The value of content-type, last-modified, and etag XML
elements MUST be identical generated output do not have a
mapping to the value URI namespace is not a problem, and has desirable
security benefits. However, if remote editing of the response
header field source
resource(s) is desired, they should be given a location in the
URI namespace. This source location should not be one of the same name
locations at which the generated output is retrievable, since in
general it is impossible for the HTTP/1.1 specification.
Since server to differentiate requests
for source resources from requests for process output resources.
There is often a many-to-many relationship between source
resources and output resources. For DAV compliant servers all
output resources which have a single source resource (and that
source resource has a URI), the HTTP/1.1 header fields are described in terms URI of the on-the-wire entity, the values presented by INDEX are
those that would source resource SHOULD
be generated if stored in a single link on the output resource was accessed
using with type
http://www.ietf.org/standards/dav/link/Source. Note that by
storing the GET method without content negotiation.
3.3.5.1 CollectionResource
Name: http://www.ietf.org/standards/dav/collectionresource
Purpose: Describes a collection
Schema: http://www.ietf.org/standards/dav/
Parent: <XML>
Value:MemberResource
3.3.5.2 MemberResource
Name: http://www.ietf.org/standards/dav/memberresource
Purpose: Describes a member source URI in links on the output resources, the
burden of a collection
Schema: http://www.ietf.org/standards/dav/
Parent: CollectionResource
Value:Ref, IsCollection, Content-Type, External, Creation-
Date, Last-Modified, ETag, DisplayName (other XML elements
MAY also be present)
3.3.5.3 Ref
See XML definition.
3.3.5.4 IsCollection
Name: http://www.ietf.org/standards/dav/iscollection
Purpose: This is a boolean value which is set to “true” if discovering the entry source is a collection
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value:(“true” | “false”)
3.3.5.5 Content-Type
Name: http://www.ietf.org/standards/dav/content-type
Purpose: The content-type of placed on the member resource.
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value:media-type ; defined in Section 3.7 authoring
client.
In the general case, a large number of [HTTP11] source resources can
comprise a data-producing process that generates many output
resources, creating a many-to-many relationship between output
resources and source resources. If no meaningful content-type each output resource had links
back to every source resource in the data-producing process,
there can be generated, then an
empty value MUST be given.
3.3.5.6 External
Name: http://www.ietf.org/standards/dav/external
Purpose: If present, this element indicates a potentially large number of such links. Due to the resource is
an external member
potentially large number of links, and the lack of a policy for
ordering access to multiple sources, explicit storage of source
relationships is limited to cases with only a single source
resource.
3.2 MKCOL Method
3.2.1 Problem Description
The client needs a way to create a collection. If
3.2.2 Solution Requirements
The solution:
- Must ensure that a collection has been made (i.e. that it
responds to the value is
“propagate,” INDEX method) as opposed to a non-collection
resource. If a collection could not be made, it is must indicate a propagate member,
failure to the principal.
- The server MAY, if necessary, create any intermediate
collections so that the value is “no-
propagate,” it underlying storage medium is a no-propagate member.
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value:(“propagate” | “no-propagate”)
3.3.5.7 Creation-Date
Name: http://www.ietf.org/standards/dav/creation-date
Purpose: self-
consistent.
-
3.2.3 Request
The date the MKCOL method creates a new collection resource was created.
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value:The date MUST be given in RFC 1123 format (rfc-1123
production, defined in section 3.3.1 of [HTTP11]
3.3.5.8 Last-Modified
Name: http://www.ietf.org/standards/dav/last-modified
Purpose: The date at the resource was last modified.
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value:The date MUST be given in RFC 1123 format (rfc-1123
production, defined in section 3.3.1 of [HTTP11]
3.3.5.9 ETag
Name: http://www.ietf.org/standards/dav/etag
Purpose: The entity tag of
location specified by the resource.
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value:entity-tag ; defined in Section 3.11 of [HTTP11]
3.3.5.10 DisplayName
Name: http://www.ietf.org/standards/dav/displayname
Purpose: A name for Request-URI. If the resource that is suitable for
presentation Request-URI exists
then MKCOL must fail.
During MKCOL processing, a server MAY add the Request-URI to one
or more collections within the server’s controlled namespace.
3.2.3.1 MKCOL Without Request Body
When MKCOL is invoked without a person
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value:Any valid XML character data (from XML specification)
3.3.5.11 Content-Language
Name: http://www.ietf.org/standards/dav/content-language
Purpose: Describes request body then the natural language(s) collection
created has no members.
3.2.3.2 MKCOL With Request Body
A MKCOL request message MAY contain a message body. The behavior
of a MKCOL request when the intended
audience for the resource.
Schema: http://www.ietf.org.standards/dav/
Parent: MemberResource
Value: 1#language-tag ;language-tag body is defined in section
14.13 present is limited to
creating collections, members of RFC 2068
3.3.6 Example
INDEX /user/yarong/dav_drafts/ HTTP/1.1
Host: www.microsoft.com
Depth: 1
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: xxx
Last-Modified: xxx
ETag: “fooyyybar”
<XML>
<XML:Namespace><Ref>http://www.ietf.org/standards/dav/<
/><As>D</></>
<D:CollectionResource>
<MemberResource>
<XML:Ref>namespace.doc</>
<IsCollection>false</>
<Content-Type>application/msword</>
<External>false</>
<Creation-Date>Thu, 20 Mar 1997 23:05:25
GMT</>
<Last-Modified>Fri, 22 Aug 1997 18:22:56
GMT</>
<Etag>8675309</>
<DisplayName>WebDAV Name Space Operations
Draft</>
<Content-Language>en</>
</> </>
</>
This example shows the result of the INDEX method applied to
the collection resource
http://www.microsoft.com/er/yarong/dav_drafts/. It returns a response body in XML format, which gives information about
the container’s sole member,
http://www.microsoft.com/users/yarong/dav_drafts/namespace.d
oc.
3.4 Behavior collection, bodies of RFC 2068 Methods members
and properties on Collections
With the introduction of collections or members. If the collection resource server
receives a MKCOL request entity type to the
HTTP object model, it is necessary to define the behavior of
the existing methods (defined in RFC 2068) when invoked on does not support or
understand it MUST respond with a
collection 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.4.1 GET, HEAD for 415 (Unsupported Media Type)
status code.
3.2.3.3 Creating Multiple Collections
The semantics of GET are unchanged when applied to a
collection, since GET is defined as, “retrieve whatever
information (in server MAY create intermediate collections if they do not
already exist. For example, if the form of an entity) is identified by collection http://server/a/
already exists in the
Request-URI” [HTTP11]. GET when applied server’s namespace, then while performing a
MKCOL to create http://server/a/b/c/ the server may also create a
collection MAY
return the contents of an “index.html” resource, at http://server/a/b/.
3.2.4 Response
Responses from a human-
readable view of MKCOL request are not cacheable, since MKCOL has
non-idempotent semantics.
201 (Created) - The structured resource was created in its
entirety.
403 (Forbidden) - The server does not allow the contents creation of
collections at the collection, or
something else altogether, and hence it is possible the
result of a GET on a collection will bear no correlation to given location in its namespace.
415 (Unsupported Media Type)- The server does not support the state
request type of the collection.
Similarly, since body.
416 (Unprocessable Entity) - A new status code. The server
understands the definition content type of HEAD is a GET without a
response message body, the semantics of HEAD do not require
any modification when applied request entity, but was
unable to collection resources.
3.4.2 POST for Collections
Since by definition the actual function performed by POST is
determined by process the server and often depends contained instructions.
3.2.5 Example
This example creates a container collection called
/webdisc/xfiles/ on the particular
resource, the behavior of POST when applied to collections
cannot be modified because it server www.server.org.
MKCOL /webdisc/xfiles/ HTTP/1.1
Host: www.server.org
HTTP/1.1 201 Created
3.3 INDEX Method
3.3.1 Problem Description
A mechanism is largely undefined. Thus
the semantics of POST do not require any modification when
applied needed to discover if a collection.
3.4.3 PUT for Collections
In HTTP/1.1, PUT stores the request entity under the
Request-URI, resource is a collection
and hence if so, list its semantics are limited members.
3.3.2 Solution Requirements
The solution:
- must allow a client to non- discover the members of a collection resources. If
- must always provide a PUT is invoked on machine-readable description of the
membership of a collection
-
3.3.3 The Request
The INDEX method returns a machine-readable representation of the
membership of the resource it MUST fail.
When at the PUT operation creates Request-URI. For a new non-collection
resource, collection,
INDEX MUST return a server MAY add that resource’s URI to one or
more collections within machine-readable list of its members. For
other resources, the server’s controlled namespace.
3.4.4 DELETE for Collections
When DELETE information returned by INDEX is applied undefined,
and MAY vary. The request message body of an INDEX request
SHOULD be ignored.
The Depth header can be used to indicate how much of a collection resource, all
internal members MUST result can
be recursively deleted. generated for the response. The
dav:link/propagate specific values allowed for
the depth header when used with the INDEX method are 1 and
infinity. The 1 value indicates that the internal and external members MUST
member resources should be deleted reported in the result, infinity
indicates that all internal and
their links must be removed. dav:link/nopropagate external
members MUST have only their link removed; the member resources
MUST not and all
their descendants should be deleted.
The in the result. If the Depth header does is
not apply to the DELETE method. It
cannot be used to limit the extent of the operation. If it given, then 1 is present it assumed. Servers MUST be ignored.
When applied to any resource, the DELETE method deletes all
properties on the Request-URI.
During DELETE processing, honor a server depth of 1.
Servers MAY remove honor infinity. If the URI of server does not support the
deleted resource(s) from collections within its controlled
namespace.
3.4.4.1 New Response Codes for DELETE
207 (Partial Success) Only some
value of the member resources were
deleted. The response entity will describe any errors.
500 (Server Error) The resource was in such depth header then a state that it
could not 412 (Precondition failed) MUST
be deleted. returned.
3.3.4 The response entity will describe
reason for the error.
3.5 COPY Method
3.5.1 Problem Description
Currently, in order to create a copy of a resource, the
client must GET Response
200 (OK) - The server MUST send an application/xml response
entity and then PUT that entity to which describes the
desired destination. This requires (1) an entity to be
transmitted to and from collection.
404 (Not Found) - Same behavior as HTTP 1.1. The server never had
the resource, or the server and (2) that permanently deleted the resource
be expressible as an entity with complete fidelity. and
has no knowledge that it ever existed. This is problematic because of error code implies
that, essentially, the network traffic involved
in making a copy, and because there is often server has no way to fully
express information about the
Request URI.
3.3.5 Response Message Body
The default INDEX response for a resource as is an application/xml
HTTP entity without a loss of fidelity.
3.5.2 Solution Requirements
The solution:
MUST allow a principal to create a copy of (i.e., an Extensible Markup Language (XML) document)
that contains a resource
without having to transmit single XML element called collectionresource
which describes the resource to collection, and from the
server.
3.5.3 The Request
The COPY method creates a duplicate set of XML elements called
memberesource which describe the source resource,
given by the Request-URI, in the destination resource, given
by members of the Destination header. collection.
The Destination header MUST response from INDEX is cacheable, and SHOULD be
present. The exact behavior accompanied
by an ETag header (see section 13.3.4 of RFC 2068). If GET and
INDEX return different entities for the COPY method depends on
the type of same resource state, they
MUST return different entity tags.
The server MUST transmit the source resource.
3.5.3.1 COPY following XML elements for HTTP/1.1 resources
When the source each
member resource is not a collection, and is not of a
property, collection: Ref, IsCollection, Content-Type,
External. The server MUST transmit the body following XML elements if
it can generate any meaningful values for them: Creation-Date,
Last-Modified, DisplayName, Content-Language. The server SHOULD
transmit Etag XML elements for each member (see section 13.3.4 of the destination resource
RFC 2068).
The value of content-type, last-modified, and etag XML elements
MUST be
octet-for-octet identical to the body value of the source
resource. Alterations to the destination resource do not
modify the source resource. Alterations to the source
resource do not modify the destination resource. Thus, all
copies are performed “by-value”.
If the Duplicate-Properties response header is “false,” then
properties SHOULD NOT be copied to field of
the destination resource.
If same name in the Duplicate-Properties header is “false” and HTTP/1.1 specification. Since the
Enforce-Live-Properties HTTP/1.1
header is also present, the request
MUST fail with a 412 (Precondition Failed) status code.
[Ed. Note: what if resource to be copied has no properties,
and no properties fields are explicitly named described in terms of the header?]
All properties on a source resource SHOULD be duplicated on
the destination resource following the definition for
copying properties.
3.5.3.2 COPY for Properties
Live properties SHOULD be duplicated as identically behaving
live properties at on-the-wire entity,
the destination resource. Since they values presented by INDEX are
live properties, the server determines those that would be generated
if the syntax and
semantics (hence value) of these properties. Properties
named by the Enforce-Live-Properties header MUST be live on
the destination resource, or resource was accessed using the GET method MUST fail. If without content
negotiation.
3.3.5.1 CollectionResource
Name: http://www.ietf.org/standards/dav/collectionresource
Purpose: Describes a
property is not named by Enforce-Live-Properties and cannot collection
Schema: http://www.ietf.org/standards/dav/
Parent: <XML>
Value: MemberResource
3.3.5.2 MemberResource
Name: http://www.ietf.org/standards/dav/memberresource
Purpose: Describes a member of a collection
Schema: http://www.ietf.org/standards/dav/
Parent: CollectionResource
Value: Ref, IsCollection, Content-Type, External, Creation-
Date, Last-Modified, ETag, DisplayName (other XML elements MAY
also be copied live, then its present)
3.3.5.3 Ref
See XML definition.
3.3.5.4 IsCollection
Name: http://www.ietf.org/standards/dav/iscollection
Purpose: This is a boolean value MUST be duplicated in an
identically named, dead resource on the destination
resource.
For every dead property defined on the source resource,
there SHOULD be an octet-for-octet identical dead property
on which is set to "true" if the destination resource.
3.5.3.3 COPY for Collections
entry is a collection
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value: ("true" | "false")
3.3.5.5 Content-Type
Name: http://www.ietf.org/standards/dav/content-type
Purpose: The Depth and Overwrite headers govern the behavior content-type of COPY
for collections.
When performing a recursive copy, all HTTP/1.1 request
headers are duplicated on the propagated method request
except for the precondition headers If-Modified-Since, If-
Match, If-None-Match, If-Range, If-Unmodified-Since, which
should only be applied to the Request-URI member resource.
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value: media-type ; defined in order to
determine if the operation should Section 3.7 of [Fielding et
al., 1997]
If no meaningful content-type can be performed. The
Destination header generated, then an empty
value MUST be rewritten to preserve given.
3.3.5.6 External
Name: http://www.ietf.org/standards/dav/external
Purpose: If present, this element indicates the
membership resource is an
external member of the destination collection, i.e., by appending
the relative URI of collection. If the member to the URI of the destination
collection.
A Depth of “0” indicates the collection MUST duplicate all
of its external members in a new collection at the
Destination. Since the COPY method value is not propagated to its
members, no internal member resource "propagate,"
it is duplicated.
A Depth of “1” indicates the collection MUST a propagate member, if the
COPY to all internal, non-collection members. If the
Overwrite header value is "no-propagate," it is “true” a
no-propagate member.
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value: ("propagate" | "no-propagate")
3.3.5.7 Creation-Date
Name: http://www.ietf.org/standards/dav/creation-date
Purpose: The date the COPY method duplicates all of
its external members resource was created.
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value: The date MUST be given in a new collection at RFC 1123 format (rfc-1123
production, defined in section 3.3.1 of [Fielding et al., 1997]
3.3.5.8 Last-Modified
Name: http://www.ietf.org/standards/dav/last-modified
Purpose: The date the Destination.
If resource was last modified.
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value: The date MUST be given in RFC 1123 format (rfc-1123
production, defined in section 3.3.1 of [Fielding et al., 1997]
3.3.5.9 ETag
Name: http://www.ietf.org/standards/dav/etag
Purpose: The entity tag of the Overwrite header is “false” and resource.
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value: entity-tag ; defined in Section 3.11 of [Fielding et
al., 1997]
3.3.5.10 DisplayName
Name: http://www.ietf.org/standards/dav/displayname
Purpose: A name for the destination resource that is suitable for
presentation to a collection, person
Schema: http://www.ietf.org/standards/dav/
Parent: MemberResource
Value: Any valid XML character data (from XML specification)
3.3.5.11 Content-Language
Name: http://www.ietf.org/standards/dav/content-language
Purpose: Describes the COPY method does not duplicate
its external members, but is propagated to all internal,
non-collection members.
A Depth natural language(s) of “infinity” indicates the collection MUST
propagate the COPY method to all internal members. If intended
audience for the
Overwrite header resource.
Schema: http://www.ietf.org.standards/dav/
Parent: MemberResource
Value: 1#language-tag ;language-tag is “true,” the COPY method MUST duplicate
all of its external members defined in a new collection at the
Destination. If the Overwrite header is “false” and section
14.13 of RFC 2068
3.3.6 Example
INDEX /user/yarong/dav_drafts/ HTTP/1.1
Host: www.microsoft.com
Depth: 1
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: xxx
Last-Modified: xxx
ETag: "fooyyybar"
<XML>
<XML:Namespace><Ref>http://www.ietf.org/standards/dav/</><As
>D</></>
<D:CollectionResource>
<MemberResource>
<XML:Ref>namespace.doc</>
<IsCollection>false</>
<Content-Type>application/msword</>
<External>false</>
<Creation-Date>Thu, 20 Mar 1997 23:05:25 GMT</>
<Last-Modified>Fri, 22 Aug 1997 18:22:56 GMT</>
<Etag>8675309</>
<DisplayName>WebDAV Name Space Operations Draft</>
<Content-Language>en</>
</> </>
</>
This example shows the
destination resource is a collection, then result of the COPY INDEX method
does not duplicate its external members, but is propagated applied to all internal members.
3.5.3.4 Type Interactions
If the destination
collection resource identifies
http://www.microsoft.com/er/yarong/dav_drafts/. It returns a property and
response body in XML format, which gives information about the
source resource is not a property, then
container’s sole member,
http://www.microsoft.com/users/yarong/dav_drafts/namespace.doc.
3.4 Behavior of RFC 2068 Methods on Collections
With the copy SHOULD
fail.
If introduction of the destination resource identifies a collection and resource type to the
Overwrite header HTTP
object model, it is “true,” prior necessary to performing define the copy, behavior of the server MUST perform a DELETE operation
existing methods (defined in RFC 2068) when invoked on the
collection.
3.5.4 The Response
200 (OK) The source resource was successfully copied to a
pre-existing destination resource.
201 (Created) The source
collection resource was successfully copied. 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.4.1 GET, HEAD for Collections
The copy operation resulted in the creation semantics of GET are unchanged when applied to a new
resource.
207 (Partial Success) Only some of the member resources were
copied. The return entity body describes collection,
since GET is defined as, "retrieve whatever information (in the status code for
each resource.
412 (Precondition Failed) This status code MUST be returned
if
form of an entity) is identified by the server was unable Request-URI" [Fielding et
al., 1997]. GET when applied to maintain a collection MAY return the liveness
contents of an "index.html" resource, a human-readable view of
the
properties listed in contents of the Enforce-Live-Properties header, collection, or
if the Overwrite header is false, something else altogether, and
hence it is possible the state result of the
destination resource is non-null.
500 (Server Error) The resource was in such a GET on a collection will
bear no correlation to the state that it
could not be copied. This may occur if of the Destination
header indicated an external (from collection.
Similarly, since the point definition of view HEAD is a GET without a
response message body, the semantics of HEAD do not require any
modification when applied to collection resources.
3.4.2 POST for Collections
Since by definition the
server) resource and actual function performed by POST is
determined by the server has no capability to copy to
an external resource.
502 (Bad Gateway) - This may occur when copying to external
resources and often depends on the destination server refused to accept particular
resource, the
resource.
3.5.5 Examples
3.5.5.1 Overwrite Example
This example shows resource
http://www.ics.uci.edu/~fielding/index.html being copied behavior of POST when applied to collections cannot
be modified because it is largely undefined. Thus the location
http://www.ics.uci.edu/users/f/fielding/index.html. The
contents semantics
of POST do not require any modification when applied to a
collection.
3.4.3 PUT for Collections
In HTTP/1.1, PUT stores the 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
Overwrite: “true”
HTTP/1.1 200 OK
3.5.5.2 No Overwrite Example
The following example shows the same copy operation being
performed, except with request entity under the Overwrite header set Request-URI,
and hence its semantics are limited to “false.”
A response of 412, Precondition Failed, is returned because
the destination resource has non-collection resources.
If 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
HTTP/1.1 412 Precondition Failed
3.6 MOVE Method
3.6.1 Problem Description
The move operation PUT is invoked on a collection resource is it MUST fail.
When the logical equivalent
of PUT operation creates a copy followed by new non-collection resource, a delete.
In HTTP 1.1, the procedure could be performed in several
steps. First,
server MAY add that resource’s URI to one or more collections
within the client could issue a GET server’s controlled namespace.
3.4.4 DELETE for Collections
When DELETE is applied to retrieve a
representation of a collection resource, issue a all internal
members MUST be recursively deleted. The dav:link/propagate
external members MUST be deleted and their links must be removed.
dav:link/nopropagate external members MUST have only their link
removed; the resources MUST not be deleted.
The Depth header does not apply to the DELETE method. It cannot
be used to remove limit the
resource from extent of the server, then use PUT operation. If it is present it
MUST be ignored.
When applied to place any resource, the resource DELETE method deletes all
properties on the server with Request-URI.
During DELETE processing, a new URI. As is server MAY remove the case URI of the
deleted resource(s) from collections within its controlled
namespace.
3.4.4.1 New Response Codes for DELETE
207 (Partial Success) Only some of the member resources were
deleted. The response entity will describe any errors.
500 (Server Error) The resource was in such a state that it could
not be deleted. The response entity will describe reason for the
error.
3.5 COPY - Method
3.5.1 Problem Description
Currently, in order to create a copy of a resource, the client
must GET an entity and then PUT that entity to the desired
destination. This requires (1) an entity to be transmitted to and
from the server and (2) that the resource be expressible as an
entity with complete fidelity. This is problematic because of
the network traffic involved in making a move, copy, and because there
is often no way to fully express a resource as an entity without
a loss of fidelity fidelity.
3.5.2 Solution Requirements
The solution:
- server
move functionality is preferable.
With a DAV server, MUST allow a principal may accomplish this task by
issuing a COPY and then DELETE. Network load decreases, but
the server load may still be significant because the server
must to create a duplicate resource. Were copy of a server resource
without having to know
beforehand that a principal intended transmit the resource to perform COPY and
DELETE operations in succession, it could avoid the creation
of a duplicate resource.
3.6.2 Solution Requirements
The solution:
Must prevent the unneeded transfer of entity bodies from and
to the server.
Must prevent the unneeded creation of copies by the server.
3.6.3
3.5.3 The Request
The MOVE method is defined as the logical equivalent of a COPY followed by method creates a DELETE duplicate of the source resource, performed
atomically.
3.6.4 The Response
200 (OK) - The resource was moved. A successful response
must contain the Content-Location header, set equal to given
by the
URI Request-URI, in source. This lets caches properly flush any cached
entries for the source. Unfortunately destination resource, given by the Content-Location
Destination header. The Destination header only allows a single value so it is not possible for
caches unfamiliar with MUST be present. The
exact behavior of the MOVE COPY method to properly clear
their caches.
207 (Partial Success) Only some depends on the type of the member
source resource.
3.5.3.1 COPY for HTTP/1.1 resources were
moved. The return entity
When the source resource is not a collection, and is not a
property, the body will give of the status code for
each resource.
412 (Precondition Failed) This status code destination resource MUST be returned
if the server was unable octet-for-
octet identical to maintain the liveness body of the source resource. Alterations
to the destination resource do not modify the source resource.
Alterations to the source resource do not modify the destination
resource. Thus, all copies are performed "by-value".
If the Duplicate-Properties header is "false," then properties listed in
SHOULD NOT be copied to the Enforce-Live-Properties header, or
if destination resource. If the Overwrite
Duplicate-Properties header is false, "false" and the state of the
destination resource Enforce-Live-
Properties header is non-null.
501 (Not Implemented) - This may occur also present, the request MUST fail with a
412 (Precondition Failed) status code. [Ed. Note: what if
resource to be copied has no properties, and no properties are
explicitly named in the Destination
header specifies header?]
All properties on a source resource which is outside its domain of
control (e.g., stored SHOULD be duplicated on another server) the
destination resource and following the
server either refuses or is incapable of moving to an
external resource.
502 (Bad Gateway) - This may occur when moving to external
resources and definition for copying
properties.
3.5.3.2 COPY for Properties
Live properties SHOULD be duplicated as identically behaving live
properties at the destination server refused to accept the resource.
3.6.5 Examples
3.6.5.1 Overwrite Example
This example shows resource
http://www.ics.uci.edu/~fielding/index.html being moved to Since they are live
properties, the location
http://www.ics.uci.edu/users/f/fielding/index.html. The
contents of server determines 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
Overwrite: true
HTTP/1.1 200 OK
Content-Location:
http://www.ics.uci.edu/users/f/fielding/index.html
3.7 Multi-Status Response
3.7.1 Problem Definition
Certain methods (COPY, MOVE, syntax and DELETE) when applied to a
collection might be recursively applied to all sub-members semantics (hence
value) of these properties. Properties named by the collection. In this case, it Enforce-
Live-
Properties header MUST be live on the destination resource, or
the method MUST fail. If a property is possible that not named by Enforce-
Live-
Properties and cannot be copied live, then its value MUST be
duplicated in an identically named, dead resource on the
operation will succeed
destination resource.
For every dead property defined on some member resources and fail the source resource, there
SHOULD be an octet-for-octet identical dead property on
others, thus generating a 207 (Partial Success) status code.
A principal may need to know which members of the
collection succeeded and which failed.
3.7.2 Solution Requirements
destination resource.
3.5.3.3 COPY for Collections
The solution must:
- communicate the status code Depth and reason
- give Overwrite headers govern the URI behavior of the resource COPY for
collections.
When performing a recursive copy, all HTTP/1.1 request headers
are duplicated on which the propagated method was
invoked
- be consistent with other return body formats
3.7.3 Multi-Status Response
The default multi-status response body is an application/xml
HTTP entity that contains a single XML element called
multiresponse, which contains a set of XML elements called
response, one request except for each 200, 300, 400, and 500 series status
code generated during the method invocation. 100 series
status codes MUST NOT
precondition headers If-Modified-Since, If-Match, If-None-Match,
If-Range, If-Unmodified-Since, which should only be recorded applied to
the Request-URI in a response XML element.
Each response XML element contains two sub-entities, ref, order to determine if the operation should be
performed. The Destination header MUST be rewritten to preserve
the membership of the destination collection, i.e., by appending
the relative URI of the resource on which member to the method was invoked, and
status, which holds URI of the status-line from destination
collection.
A Depth of "0" indicates the collection MUST duplicate all of its
external members in a new collection at the Destination. Since
the COPY method
invocation. is not propagated to its members, no internal
member resource is duplicated.
A multi-status response Depth of "1" indicates the collection MUST be present when a 207 (Partial
Success) status code propagate the COPY
to all internal, non-collection members. If the Overwrite header
is returned by "true" the initial COPY method
invocation.
3.7.3.1 MultiResponse
Name:
http://www.ietf.org/standards/dav/multiresponse/multi
response
Purpose: Contains multiple response messages.
Schema: http://www.ietf.org/standards/dav/multiresponse/
Parent: <XML>
Value:1*Response
3.7.3.2 Response
Name:
http://www.ietf.org/standards/dav/multiresponse/respo
nse
Purpose: Holds duplicates all of its external members
in a single response
Schema: http://www.ietf.org/standards/dav/multiresponse/
Parent: MultiResponse
Value:Ref, Status
3.7.3.3 Status
Name:
http://www.ietf.org/standards/dav/multiresponse/statu
s
Purpose: Holds new collection at the Destination. If the Overwrite header
is "false" and the destination resource is a single HTTP status-line
Schema: http://www.ietf.org/standards/dav/multiresponse/
Parent: Response
Value:status-line ;status-line defined in [HTTP11]
3.7.4 Example collection, the COPY /users/jdoe/collection/ HTTP/1.1
Host: www.doecorp.com
Destination:
http://www.doecorp.com/users/jdoe/othercollection/
Depth: infinity
Overwrite: false
HTTP/1.1 207 Partial Success
Content-Type: application/xml
Content-Length: xxx
<XML>
<XML:Namespace><Ref>http://www.ietf.org/standards/dav/multir
esponse/</><As>R</></>
<R:MultiResponse>
<Response>
<XML:Ref>http://www.doecorp.com/users/jdoe/collection/i
ndex.html</>
<Status>HTTP/1.1 412 Precondition Failed</>
</>
<Response>
<XML:Ref>http://www.doecorp.com/users/jdoe/collection/r
eport.html</>
<Status>HTTP/1.1 200 OK</>
</>
</>
</>
3.8 ADDREF Method
3.8.1 Problem Definition
There needs to be a way to add 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 a body
3.8.3 The Request
The ADDREF
method adds the URI specified in the Collection-
Member header as an does not duplicate its external member members, but is propagated
to all internal, non-collection members.
A Depth of "infinity" indicates the collection
specified by MUST propagate the Request-URI. The value in
COPY method to all internal members. If the Collection-
Member Overwrite header MUST be an absolute URI meeting is
"true," the
requirements COPY method MUST duplicate all of an its external member URI. The propagation
type of
members in a new collection at the external URI Destination. If the Overwrite
header is specified in "false" and the Collection-
Member Header.
3.9 DELREF Method
3.9.1 Problem Definition
There needs to be destination resource is a way to remove an collection,
then the COPY method does not duplicate its external member from a
collection.
3.9.2 Solution Requirements
The solution must:
allow access control
allow referencing members, but
is propagated to URIs of external members all internal members.
3.5.3.4 Type Interactions
If the destination resource identifies a property and the source
resource is not require a body
3.9.3 The Request
The DELREF method removes property, then the URI specified in copy SHOULD fail.
If the
Collection-Member destination resource identifies a collection and the
Overwrite header from is "true," prior to performing the collection specified by copy, the Request-URI.
3.10 PATCH Method
3.10.1 Problem Definition
At present, if
server MUST perform a principal wishes DELETE operation on the collection.
3.5.4 The Response
200 (OK) The source resource was successfully copied to modify a resource, they
must issue a GET against the resource, modify their local pre-
existing destination resource.
201 (Created) The source resource was successfully copied. The
copy of operation resulted in the resource, and then issue creation of a PUT to place the
modified resource on the server. This procedure is
inefficient because new resource.
207 (Partial Success) Only some of the entire member resources were
copied. The return entity body describes the status code for a resource must each
resource.
412 (Precondition Failed) This status code MUST be
transmitted to and from returned if
the server in order was unable to make even
small changes. Ideally, maintain the update entity transmitted to liveness of the server should be proportional properties
listed in size to the
modifications.
3.10.2 Solution Requirements
The solution must:
allow partial modification of a resource without having to
transmit Enforce-Live-Properties header, or if 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, Overwrite
header is false, and replaced
3.10.3 The Request
The PATCH method contains a list of differences between the
original version state of the destination resource identified by is
non-
null.
500 (Server Error) The resource was in such a state that it could
not be copied. This may occur if the Request-
URI and Destination header indicated
an external (from the desired content point of view of the server) resource after and
the PATCH
action server has been applied. The list of differences is in a
format defined by the media type of the entity (e.g.,
"application/diff") and must include sufficient information no capability to allow copy to an external resource.
502 (Bad Gateway) - This may occur when copying to external
resources and the destination server refused to convert accept the original version
resource.
3.5.5 Examples
3.5.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 of the 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
Overwrite: "true"
HTTP/1.1 200 OK
3.5.5.2 No Overwrite Example
The following example shows the same copy operation being
performed, except with the Overwrite header set to "false." A
response of 412, Precondition Failed, is returned because the desired version.
Since
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
HTTP/1.1 412 Precondition Failed
3.6 MOVE Method
3.6.1 Problem Description
The move operation on a resource is the semantics logical equivalent of PATCH are non-idempotent, responses
to this method are not cacheable.
If a
copy followed by a delete.
In HTTP 1.1, the request appears (at least initially) to procedure could be
acceptable, performed in several steps.
First, the server MUST transmit an interim 100 response
message after receiving client could issue a GET to retrieve a representation
of a resource, issue a DELETE to remove the empty line terminating resource from the
request headers and continue processing
server, then use PUT to place the resource on the request.
While server support for PATCH is optional, if with a server does
support PATCH, it MUST support at least
new URI. As is the application/xml
diff format defined below. Support case for the VTML difference
format [VTML] is recommended, but not required.
3.10.4 application/XML elements for PATCH
The resourceupdate XML elementXML element contains a set COPY - because of
XML sub-entities that describe modification operations. The
name the network traffic
involved in making a move, and meaning of these XML elements because there is given below.
Processing of these directives MUST be performed in the
order encountered within the XML document. A directive
operates on the often no way to
fully express a resource as modified by all previous
directives (executed in sequential order).
3.10.4.1 ResourceUpdate
Name:
http://www.ietf.org/standards/dav/patch/resourceupdat
e
Purpose: Contains an ordered set entity without a loss of changes to fidelity
- server move functionality is preferable.
With a non-
collection, non-property resource.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: <XML>
Value:*(Insert | Delete | Replace)
3.10.4.2 Insert
Name: http://www.ietf.org/standards/dav/patch/insert
Purpose: Insert DAV server, a principal may accomplish this task by
issuing a COPY and then DELETE. Network load decreases, but the XML elementXML element’s contents
starting exactly at
server load may still be significant because the specified octet.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: ResourceUpdate
Value:The insert XML elementXML element MUST contain an
octet XML elementXML element server must
create a duplicate resource. Were a server to know beforehand
that specifies an octet
position within a principal intended to perform COPY and DELETE operations
in succession, it could avoid the body creation of a duplicate
resource. A value of “end”
specifies
3.6.2 Solution Requirements
The solution:
- Must prevent the end unneeded transfer of entity bodies from and
to the resource. The body server.
- Must prevent the unneeded creation of copies by the insert
XML elementXML element contains server.
3.6.3 The Request
The MOVE method is defined as the octets to be inserted.
3.10.4.3 Delete
Name: http://www.ietf.org/standards/dav/patch/delete
Purpose: Removes the specified range logical equivalent of octets.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: ResourceUpdate
Value:The Delete XML elementXML element MUST contain an
octet-range XML elementXML element. The value a COPY
followed by a DELETE of this XML
elementXML element is empty.
Discussion: The octets which are deleted are removed, which
means the source resource, performed
atomically.
3.6.4 The Response
200 (OK) - The resource is collapsed and was moved. A successful response must
contain the length of Content-Location header, set equal to the
resource is decremented by URI in
source. This lets caches properly flush any cached entries for
the size of source. Unfortunately the octet range. It Content-Location header only allows
a single value so it is not appropriate to replace deleted octets possible for caches unfamiliar 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 MOVE method to properly clear their caches.
207 (Partial Success) Only some of octets with the
contents of member resources were
moved. The return entity body will give the XML element. If status code for each
resource.
412 (Precondition Failed) This status code MUST be returned if
the number server was unable to maintain the liveness of octets the properties
listed in the
XML element is different from Enforce-Live-Properties header, or if the number of octets
specified, Overwrite
header is false, and 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. The contents state of the entity are destination resource is
non-
null.
501 (Not Implemented) - This may occur if the replacement
octets.
3.10.4.5 Octet-Range Attribute
Name:
http://www.ietf.org/standards/dav/patch/octet-range
Purpose: Specifies Destination header
specifies a range of octets resource which 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 with 0. If the octet
contains a single number then the operation is to begin at
that octet outside its domain of control
(e.g., stored on another server) resource and to continue for a length specified by the
operation. In the case server either
refuses or is incapable of a delete, this would mean moving to
delete but a single octet. In the case of an insert this
would mean external resource.
502 (Bad Gateway) - This may occur when moving to begin external
resources and the insertion at destination server refused to accept the specified octet and
resource.
3.6.5 Examples
3.6.5.1 Overwrite Example
This example shows resource
http://www.ics.uci.edu/~fielding/index.html being moved to continue for the length
location http://www.ics.uci.edu/users/f/fielding/index.html. The
contents of the included value, extending
the destination resource were overwritten, if necessary. In the case of replace, the
replace begins at the specified octet and overwrites all
that follow 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
Overwrite: true
HTTP/1.1 200 OK
Content-Location:
http://www.ics.uci.edu/users/f/fielding/index.html
3.7 ADDREF Method
3.7.1 Problem Definition
There needs to the length be a way to add an external member to a
collection.
3.7.2 Solution Requirements
The solution must:
- allow access control
- allow referencing to URIs of external members
- not require a body
3.7.3 The Request
The ADDREF method adds the included value. Octet
values MUST specify locations URI specified in the state of the resource
prior Collection-Member
header as an external member to the processing of collection specified by the PATCH method.
3.10.5
Request-URI. The Response
200 (OK) - The request entity body was processed without
error, resulting value in the Collection-Member header MUST be an update to
absolute URI meeting the state requirements of an external member URI.
The propagation type of the resource.
409 (Conflict) external URI is specified in the
Collection-Member Header.
3.8 DELREF Method
3.8.1 Problem Definition
There needs to be a way to remove an external member from a
collection.
3.8.2 Solution Requirements
The solution must:
- If allow access control
- allow referencing to URIs of external members
- not require a body
3.8.3 The Request
The DELREF method removes the update information URI specified in the request
message body does not make sense given Collection-
Member header from the current state collection specified by the Request-URI.
3.9 PATCH Method
3.9.1 Problem Definition
At present, if a principal wishes to modify a resource, they must
issue a GET against the resource, modify their local copy of the resource (e.g., an instruction
resource, and then issue a PUT to delete place the modified resource on
the server. This procedure is inefficient because the entire
entity for a non-existent
line), this status code MAY resource must be returned.
415 (Unsupported Media Type) - The server does not support transmitted to and from the content type of server
in order to make even small changes. Ideally, the update instructions in entity
transmitted to the request
message body.
416 (Unprocessable Entity) - A new status code. The server
understands should be proportional in size to the content type
modifications.
3.9.2 Solution Requirements
The solution must:
- allow partial modification of the request entity, but was
unable a resource without having to process
transmit the contained instructions.
3.10.6 Examples
3.10.6.1 HTML file modification 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, and replaced
3.9.3 The following example shows Request
The PATCH method contains a modification list of differences between the title
original version of the resource identified by the Request-URI
and
contents the desired content of the HTML resource
http://www.example.org/hello.html.
Before:
<HTML>
<HEAD>
<TITLE>Hello world HTML page</TITLE>
</HEAD>
<BODY>
<P>Hello, world!</P>
</BODY>
</HTML>
PATCH Request: Response: after the PATCH hello.html HTTP/1.1
Host: www.example.org
Content-Type: application/xml
Content-Length: xxx
HTTP/1.1 100 Continue
<XML>
<XML:Namespace><ref>http://www.ietf.org/standards/dav/p
atch/</><AS>D</></>
<D:ResourceUpdate>
<Replace><octet-range>14</>&003CTITLE&003ENew
Title&003C/TITLE&003E</>
<Delete><octet-range>38-50</>
<Insert><octet-range>86</>&003CP&003ENew
paragraph&003C/P&003E
</>
</></>
HTTP/1.1 200 OK
After:
<HTML>
<HEAD>
<TITLE>New Title</TITLE>
</HEAD>
<BODY>
<P>Hello, world!</P>
<P>New paragraph</P>
</BODY>
</HTML>
3.11 Headers
3.11.1 Depth action
has been applied. The Depth header determines the depth to which a method list of differences is
propagated on a resource’s children.
Depth = “Depth” “:” DepthToken
DepthToken = "0" | "1" | "infinity" | token
The optional token allows for extension. A server MUST
ignore a Depth header with an unknown value.
3.11.2 Destination
The Destination header specifies in a destination resource for
methods such as COPY format defined
by the media type of the entity (e.g., "application/diff") and MOVE, which take two URIs as
parameters.
Destination= “Destination” “:” URI
3.11.3 Enforce-Live-Properties
The Enforce-Live-Properties header specifies properties that
MUST be “live” after they are copied (moved)
must include sufficient information to allow the
destination resource server to
convert the original version of a copy (or move). If the value “*”
is given for resource to the header, then it designates all live
properties on desired
version.
Since the source resource.
EnforceLiveProperties = "Enforce-Live-Properties” “:"
(“*” | 1#( Property-Name ))
Property-Name = <“> URI <“>
3.11.4 Duplicate-Properties
The Duplicate-Properties header instructs the server whether semantics of PATCH are non-idempotent, responses to duplicate the source resource’s properties onto
this method are not cacheable.
If the
destination resource during a COPY or MOVE. A value of
“false” requires that request appears (at least initially) to be acceptable, the
server MUST NOT duplicate on the
destination resource any properties that are defined on transmit an interim 100 response message after
receiving the
source resource. By default, empty line terminating the value of this header is
“true,” and a client MAY omit this header from a request
when its value is “true.”
Duplicate-Properties = “Duplicate-Properties” “:”
(“true” | “false”)
3.11.5 Overwrite
The Overwrite header specifies whether headers and
continue processing the request.
While server should
overwrite the state of a non-null destination resource
during support for PATCH is optional, if a COPY or MOVE. A value of “false” states that the server does
support PATCH, it MUST NOT perform the COPY or MOVE operation if support at least the
state of application/xml diff
format defined below. Support for the destination resource VTML difference format
[VTML] is non-null. By default,
the value recommended, but not required.
3.9.4 application/XML elements for PATCH
The resourceupdate XML elementXML element contains a set of Overwrite is “false,” XML
sub-entities that describe modification operations. The name and a client MAY omit
this header from a request when its value
meaning of these XML elements is “false.” While
the Overwrite header appears to duplicate the functionality given below. Processing of these
directives MUST be performed in the If-Match: * header of HTTP/1.1, If-Match applies only
to order encountered within the Request-URI, and not to
XML document. A directive operates on the Destination resource as modified
by all previous directives (executed in sequential order).
3.9.4.1 ResourceUpdate
Name: http://www.ietf.org/standards/dav/patch/resourceupdate
Purpose: Contains an ordered set of changes to a COPY or
MOVE.
Overwrite = “Overwrite” “:” (“true” non-collection,
non-property resource.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: <XML>
Value: *(Insert | “false”)
3.11.6 Destroy Header
When deleting a resource Delete | Replace)
3.9.4.2 Insert
Name: http://www.ietf.org/standards/dav/patch/insert
Purpose: Insert the client often wishes to specify XML elementXML element’s contents starting
exactly what sort at the specified octet.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: ResourceUpdate
Value: The insert XML elementXML element MUST contain an octet
XML elementXML element that specifies an octet position within
the body of delete is being enacted. a resource. A value of "end" specifies the end of
the resource. The Destroy
header, used with PEP, allows body of the client insert XML elementXML element
contains the octets to specify be inserted.
3.9.4.3 Delete
Name: http://www.ietf.org/standards/dav/patch/delete
Purpose: Removes the end
result they desire. specified range of octets.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: ResourceUpdate
Value: The Destroy header Delete XML elementXML element MUST contain an
octet-
range XML elementXML element. The value of this XML elementXML
element is specified as
follows:
DestroyHeader = "Destroy" ":" #Choices
Choices = "VersionDestroy" | "NoUndelete" | "Undelete"
| Token empty.
Discussion: The Undelete token requests that, if possible, octets which are deleted are removed, which means
the resource
should be left in a state such that it can be undeleted. The
server is not required to honor this request.
The NoUndelete token requests that collapsed and the length of the resource MUST NOT be
left in a state such that it can be undeleted.
The VersionDestroy token includes is
decremented by the functionality size of the
NoUndelete token and extends it octet range. It is not
appropriate to include having the server
remove all versioning references to the resource that it has
control over.
3.11.7 Collection-Member Header
The Collection-Member header specifies the URI of an
external resource to be added/deleted to/from replace deleted octets with zeroed-out octets,
since zero is a collection.
CollectionMember = “Collection-Member” “:” PropType SP
URI
PropType = “propagation” “=” (“prop” | “noprop”)
3.12 Links
3.12.1 Source Link Property Type valid octet value.
3.9.4.4 Replace
Name: http://www.ietf.org/standards/dav/link/source http://www.ietf.org/standards/dav/patch/replace
Purpose: The destination Replaces the specified range of octets with the source link identifies
contents of the
resource that contains XML element. If the unprocessed source number of octets in the link’s
source. XML
element is different from the number of octets specified, the
update MUST be rejected.
Schema: http://www.ietf.org/standards/dav/link/ http://www.ietf.org/standards/dav/patch/
Parent: Any.
Value:An ResourceUpdate
Value: The Replace XML document with zero or more link element MUST contain an octet-range XML elements.
Discussion:
element. The source contents of the link (src) is typically entity are the
URI replacement octets.
3.9.4.5 Octet-Range Attribute
Name: http://www.ietf.org/standards/dav/patch/octet-
range
Purpose: Specifies a range of the output resource on octets which the link 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 with 0. If the octet contains
a single number then the operation is defined, to begin at that octet and
there is typically only one destination (dst)
to continue for a length specified by the operation. In the case
of a delete, this would mean to delete but a single octet. In the link,
which is
case of an insert this would mean to begin the URI where insertion at the unprocessed source
specified octet and to continue for the length of the included
value, extending the resource may be accessed. When more than one link
destination exists, DAV asserts no policy on partial
ordering.
4 State Tokens
4.1 Overview
4.1.1 Problem Description
There are times when a principal will want to predicate
successful execution of a method on if necessary. In the current state of a
resource. While HTTP/1.1 provides a mechanism for
conditional execution case of methods using entity tags via
replace, the
“If-Match” and “If-None-Match” headers, replace begins at the mechanism is not
sufficiently extensible to express conditional statements
involving more generic state indicators, such as lock
tokens.
The fundamental issue with entity tags is specified octet and overwrites
all that they can only
be generated by a resource. However there are times when a
client will want to be able to share state tokens between
resources, potentially on different servers, as well as be
able follow to generate certain types the length of lock tokens without first
having to communicate with a server.
For example, a principal may wish to require that resource B
have a certain state the included value. Octet
values MUST specify locations in order for a method to successfully
execute on resource A. If the client submits an e-tag from
resource B to resource A, then A has no way state of knowing that the e-tag is meant to describe resource B.
Another example occurs when a principal wishes prior
to predicate the successful completion processing of a method on the absence of any
locks on a resource. It is not sufficient to submit PATCH method.
3.9.5 The Response
200 (OK) - The request entity body was processed without error,
resulting in an “If-
None-Match: *” as this refers update to the existence of an entity,
not state of a lock.
This draft defines the term “state token” as an identifier
for a state of a resource. The sections below define
requirements for state tokens and provide a state token
syntax, along with two new headers which can accept
409 (Conflict) - If 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 a update information in the request message
body does not make sense given the current state token it is possible to
determine what sort of state token it is, what resource(s)
it applies to, and what state it represents.
This self-describing nature allows servers the resource
(e.g., an instruction to accept tokens
from other servers and potentially delete a non-existent line), this status
code MAY be able to coordinate
state information cross resource and cross site through
standardized protocols. For example, returned.
415 (Unsupported Media Type) - The server does not support the execution
content type of a the update instructions in the request on resource message
body.
416 (Unprocessable Entity) - A can be predicated on new status code. The server
understands the state content type of
resource B, where A and B are potentially on different
servers.
Client Generable. The state token syntax must allow, when
appropriate, for clients the request entity, but was
unable to generate a state token without
having first communicated with process the contained instructions.
3.9.6 Examples
3.9.6.1 HTML file modification
The following example shows a server.
One drawback modification of entity tags is that they are set by the
server, title and there is no interoperable algorithm for
calculating an entity tag. Consequently, a client cannot
generate an entity tag from a particular state of a
resource. However, a state token which encodes an MD5 state
hash could be calculated by a client based on a client-held
state
contents of a resource, and then submitted the HTML resource http://www.example.org/hello.html.
Before:
<HTML>
<HEAD>
<TITLE>Hello world HTML page</TITLE>
</HEAD>
<BODY>
<P>Hello, world!</P>
</BODY>
</HTML>
PATCH Request: Response:
PATCH hello.html HTTP/1.1
Host: www.example.org
Content-Type: application/xml
Content-Length: xxx
HTTP/1.1 100 Continue
<XML>
<XML:Namespace><ref>http://www.ietf.org/standards/dav/patch/
</><AS>D</></>
<D:ResourceUpdate>
<Replace><octet-range>14</>&003CTITLE&003ENew
Title&003C/TITLE&003E</>
<Delete><octet-range>38-50</>
<Insert><octet-range>86</>&003CP&003ENew
paragraph&003C/P&003E
</>
</></>
HTTP/1.1 200 OK
After:
<HTML>
<HEAD>
<TITLE>New Title</TITLE>
</HEAD>
<BODY>
<P>Hello, world!</P>
<P>New paragraph</P>
</BODY>
</HTML>
3.10 Headers
3.10.1 Depth
The Depth header determines the depth to which a server in a
conditional method invocation.
Another potential use for client generable state tokens is
propagated on a resource’s children.
Depth = "Depth" ":" DepthToken
DepthToken = "0" | "1" | "infinity" | token
The optional token allows for extension. A server MUST ignore a client to generate lock tokens
Depth header with wild card fields, an unknown value.
3.10.2 Destination
The Destination header specifies a destination resource for
methods such as COPY and hence MOVE, which take two URIs as parameters.
Destination= "Destination" ":" URI
3.10.3 Enforce-Live-Properties
The Enforce-Live-Properties header specifies properties that MUST
be able to express conditionals such as: “only
execute this GET if there "live" after they are no write locks on this
resource.”
4.1.2.2 Conditonals
Universal. A solution must be applicable copied (moved) to all requests.
Positive and Negative. Conditional expressions must allow
for the expression destination
resource of both positive and negative state
requirements.
4.2 State Token Syntax
State tokens are URLs employing a copy (or move). If the following syntax:
State-Token = “StateToken:” Type “:” Resources “:” State-
Info
Type = “Type” “=” Caret-encoded-URL
Resources = “Res” “=” Caret-encoded-URL
Caret-encoded-URL value "*" is given for the
header, then it designates all live properties on the source
resource.
EnforceLiveProperties = “^” Resource “^”
Resource "Enforce-Live-Properties" ":" ("*" |
1#( Property-Name ))
Property-Name = <A <"> URI where all “^” characters <">
3.10.4 Duplicate-Properties
The Duplicate-Properties header instructs the server whether to
duplicate the source resource’s properties onto the destination
resource during a COPY or MOVE. A value of "false" requires that
the server MUST NOT duplicate on the destination resource any
properties that are escaped>
State-Info = *(uchar | reserved) ; uchar, reserved defined
section 3.2.1 on the source resource. By default,
the value of RFC 2068
This proposal has created a new URL scheme for state tokens
because this header is "true," and a state token names client MAY omit this
header from a network resource using request when its
normal name, which value is typically state-invariant, along with
additional information that "true."
Duplicate-Properties = "Duplicate-Properties" ":" ("true" |
"false")
3.10.5 Overwrite
The Overwrite header specifies a particular whether the server should
overwrite the state of a non-null destination resource during a
COPY or MOVE. A value of "false" states that the resource. Encoding server MUST NOT
perform the state information into COPY or MOVE operation if the
native URL scheme state of the network
destination resource was not felt to be
safe, since freedom from name space collisions could not be
guaranteed. If is non-null. By default, the value of
Overwrite is "false," and a client MAY omit this proposal header from a
request when its value is accepted, "false." While the StateToken URL
scheme will need Overwrite header
appears to be defined and registered with IANA.
State Token URLs begin with duplicate the URL scheme name “StateToken”
rather than the name functionality of the particular state token type they
represent in order If-Match: * header
of HTTP/1.1, If-Match applies only to make the URL self describing. Thus it
is possible Request-URI, and not to examine
the URL and know, at Destination of a minimum, that
it is COPY or MOVE.
Overwrite = "Overwrite" ":" ("true" | "false")
3.10.6 Destroy Header
When deleting a state token.
Labeled name/value pairs are used within resource the token to allow
new fields client often wishes to be added. Processors specify
exactly what sort of state tokens MUST be
prepared delete is being enacted. The Destroy header,
used with PEP [Connolly et al., 1997], allows the client to accept
specify the fields in whatever order they are
present and MUST ignore any fields end result they do not understand. desire. The “Type” field specifies the type of Destroy header is
specified as follows:
DestroyHeader = "Destroy" ":" #Choices
Choices = "VersionDestroy" | "NoUndelete" | "Undelete" |
Token
The Undelete token requests that, if possible, the state information
encoded resource
should be left in the a state token. A URL such that it can be undeleted. The
server is used in order not required to avoid
namespace collisions. honor this request.
The “Res” field identifies NoUndelete token requests that the resource for which the MUST NOT be left
in a state such that it can be undeleted.
The VersionDestroy token includes the functionality of the
NoUndelete token specifies a particular state. Since commas and spaces
are acceptable URL characters, a caret extends it to include having the server
remove all versioning references to the resource that it has
control over.
3.10.7 Mandatory header
The Mandatory header is used to delimit a
URL. Since indicate a caret is an acceptable URL character, any
instances list of it other header
field names which must be escaped using understood by the % escape
convention.
The State-Info production is expanded upon in descriptions receiver before the
contents of specific state token types, and is intended to contain the state description information for message can be stored, cached, or presented to 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 “>”)
The If-State-Match
user. This header is intended to have similar
functionality used to alert the If-Match header defined in section
14.25 of RFC 2068.
If receiver that, unlike the AND keyword is used and all
default behavior, it cannot safely ignore the semantics of the state tokens
identify
listed field-names if they are not understood.
Mandatory = "Mandatory" ":" 1#field-name
3.10.8 Collection-Member Header
The Collection-Member header specifies the state URI of an external
resource to be added/deleted to/from a collection.
CollectionMember = "Collection-Member" ":" PropType SP URI
PropType = "propagation" "=" ("prop" | "noprop")
3.11 Links
3.11.1 Source Link Property Type
Name: http://www.ietf.org/standards/dav/link/source
Purpose: The destination of the resource, then source link identifies the server MAY
perform
resource that contains the requested method. If unprocessed source of the OR keyword is used and
any 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: The source of the state tokens identifies link (src) is typically the current state URI of
the
resource, then server MAY perform output resource on which the requested method. If
neither link is defined, and there is
typically only one destination (dst) of the keyword requirements link, which is met, the server MUST
NOT perform
URI where 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 “>”)
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.
If any of the state tokens identifies the current state unprocessed source of the resource, the server MUST NOT perform the requested
method. Instead, if the request method was GET, HEAD,
INDEX, or GETMETA, the server SHOULD respond with resource may be accessed.
When more than one link destination exists, DAV asserts no policy
on partial ordering.
4 State Tokens
4.1 Overview
4.1.1 Problem Description
There are times when a 304 (Not
Modified) response, including the cache-related entity-
header fields (particularly ETag) principal will want to predicate
successful execution of a method on the current state of
the a
resource. For all other request methods, the server
MUST respond with While HTTP/1.1 provides a status of 412 (Precondition Failed).
If none of the state tokens identifies the current state mechanism for conditional
execution of methods using entity tags via the resource, the server MAY perform the requested method.
Note that the “AND” "If-Match" and “OR” keywords specified with
"If-
None-Match" headers, the If-
State-Match header are intentionally not defined for If-
None-State-Match, because this functionality mechanism 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 sufficiently extensible
to the etag header defined in section 14.20 of
RFC 2068. express conditional statements involving more generic state
indicators, such as lock tokens.
The purpose of the tag fundamental issue with entity tags is to return state tokens
defined on a resource in that they can only be
generated by a response. The contents of the
state-token resource. However there are not guaranteed times when a client
will want to be exhaustive and are
generally used able to return a new share state token that has been
defined tokens between resources,
potentially on different servers, as the result well as be able to generate
certain types of lock tokens without first having to communicate
with a method. server.
For example, if a LOCK principal may wish to require that resource B have
a certain state in order for a method were to successfully executed execute on a
resource A. If the response
would include a state token header with the lock state token
included.
4.5 E-Tags
E-tags have already been deployed using the If-Match and If-
None-Match headers. Introducing two mechanisms to express
e-tags would only confuse matters, therefore e-tags should
continue client submits an e-tag from resource B to be expressed using quoted strings and
resource A, then A has no way of knowing that the If-
Match and If-None-Match headers.
5 Locking
5.1 Problem Description - Overview
Locking e-tag is used to arbitrate access meant
to a describe resource amongst
principals that have equal access rights to that resource.
This draft allows locks B.
Another example occurs when a principal wishes to vary over two parameters, the
number of principals involved and predicate the type
successful completion of access to be
granted. This draft will only provide for a method on the definition absence of
locking for one access type, write. However, the syntax any locks on
a resource. It is
extensible enough not sufficient to submit an "If-None-Match: *"
as this refers to allow for the specification existence of other
access types. It is a goal an entity, not of this proposal that it use a lock.
This draft defines the
same access verbs term "state token" as will be defined in the access control
draft.
5.1.1 Exclusive Vs. Shared Locks
The most basic form of LOCK is an exclusive lock. This is identifier for a
lock where the access right in question is only granted to
state of a
single principal. resource. The need sections below define requirements for this arbitration results from
state tokens and provide a desire to avoid having to constantly merge results. In
fact, many users so dislike having to merge state token syntax, along with two
new headers which can accept 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 they would
rather serialize their access to
upon inspecting a resource rather than have state token it is possible to constantly perform merges.
However, there are times when the goal determine what
sort of a lock is not state token it is, what resource(s) it applies to, and
what state it represents.
This self-describing nature allows servers to
exclude others accept tokens from exercising an access right but rather
other servers and potentially be able to
provide coordinate state
information cross resource and cross site through standardized
protocols. For example, the execution of a mechanism for principals to indicate that they
intend to exercise their access right. Shared locks are
provided for this case. request on resource A shared lock allows multiple
principals to receive a lock, hence any principal with
appropriate access
can get be predicated on the lock.
With shared locks there state of resource B, where A and B are two trust sets that affect a
resource.
potentially on different servers.
Client Generable. The first trust set is created by access
permissions. Principals who are trusted, state token syntax must allow, when
appropriate, for example, may
have permission to write the resource, those who are not,
don't. Among those who have access permission clients to write the
resource, the set of principals who have taken out generate a shared
lock also must trust each other, creating state token without having
first communicated with a (probably)
smaller trust server.
One drawback of entity tags is that they are set within the access permission write set.
Starting with every possible principal on the Internet, in
most situations by the vast majority of these principals will
not have write access to server,
and there is no interoperable algorithm for calculating an entity
tag. Consequently, a given resource. Of the small
number who do have write access, some principals may decide
to guarantee their edits are free client cannot generate an entity tag from overwrite conflicts
by using exclusive write locks in conjunction with a
precondition header (If-State-Match) that checks for
existence
particular state of the lock prior to writing the a resource. Others
may decide they trust their collaborators (the potential set
of collaborators being the set of principals who have write
permission) and use However, a shared lock, state token which informs their
collaborators that
encodes an MD5 state hash could be calculated by a principal is potentially working client based
on the
resource.
The WebDAV extensions to HTTP do not need to provide all a client-held state of
the communications paths necessary for principals a resource, and then submitted to
coordinate their activities. When using shared locks,
principals may a
server in a conditional method invocation.
Another potential use any out of band communication channel to
coordinate their work (e.g., face-to-face interaction,
written notes, post-it notes on the screen, telephone
conversation, email). The intent of for client generable state tokens is for a shared
client to generate lock is tokens with wild card fields, and hence
be able to let
collaborators know who else is potentially working on a
resource..
Why not use exclusive express conditionals such as: "only execute this GET
if there are no write locks 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 the time? Experience
from initial Web distributed authoring systems has indicated
that exclusive write locks
expression of both positive and negative state requirements.
4.2 State Token Syntax
State tokens are often too rigid. An
exclusive write lock URLs employing 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 = <A URI where all "^" characters are escaped>
State-Info = *(uchar | reserved) ; uchar, reserved defined
section 3.2.1 of RFC 2068
This proposal has created a new URL scheme for state tokens
because a state token names a network resource using its normal
name, which is used to enforce typically state-invariant, along with additional
information that specifies a particular editing
process: take out exclusive write lock, read the resource,
perform edits, write state of the resource, release resource.
Encoding the lock. What
happens if state information into the lock isn't released? While native URL scheme of the time-out
mechanism provides one solution, if you need
network resource was not felt to force the
release of a lock immediately, it doesn't help much.
Granted, an administrator can release the lock for you, but
this could become a significant burden for large sites.
Further, what if the administrator can't be reached
immediately?
Despite their potential problems, exclusive write locks are
extremely useful, safe, since often a guarantee of freedom from
overwrite conflicts is exactly what name
space collisions could not be guaranteed. If this proposal is needed. The
solution: provide exclusive write locks, but also provide a
less strict mechanism in
accepted, the form of shared locks which can
be used by a set of people who trust each other and who have
access to a communications channel external StateToken URL scheme will need to HTTP which
can be used to negotiate writing to defined and
registered with IANA.
State Token URLs begin with the resource.
5.1.2 Required Support
A DAV compliant server is not required to support locking URL scheme name "StateToken"
rather than the name of the particular state token type they
represent in
any form. If order to make the server does support locking URL self describing. Thus it may choose is
possible to support any combination of exclusive examine the URL and shared locks for
any access types.
The reason for this flexibility is that server implementers
have said know, at a minimum, that they it is a
state token.
Labeled name/value pairs are willing used within the token to accept minimum
requirements on all services but locking. Locking policy
strikes allow new
fields to the very heart be added. Processors of their resource management and
versioning systems and they require control over what sort
of locking will state tokens MUST be made available. For example, some systems
only support shared write locks while others only provide
support for exclusive write locks. As each system is
sufficiently different prepared
to merit exclusion of certain locking
features, accept the authors fields in whatever order they are proposing that locking be allowed
as present and MUST
ignore any fields they do not understand.
The "Type" field specifies the sole axis type of negotiation within DAV.
5.2 LOCK Method
5.2.1 Operation
A lock method invocation creates the lock specified by the
Lock-Info header on state information
encoded in the request-URI. Lock method requests
SHOULD NOT have a request body. A user-agent SHOULD submit
an Owner header field with a lock request. state token. A successful response URL is used in order to a lock invocation MUST include a
Lock-Token header. If avoid
namespace collisions.
The "Res" field identifies the server supports a time based lock
removal mechanism on resource for which the resource, a successful lock
invocation SHOULD return state token
specifies a Time-Out header.
5.2.2 The Effect of Locks on Properties particular state. Since commas and Containers
By default spaces are
acceptable URL characters, a lock affects the entire state of the resource,
including its associated properties. As such it caret is illegal used to specify a lock on delimit a property. For containers, URL.
Since a lock also
affects the ability to add or remove members. The nature caret is an acceptable URL character, any instances of it
must be escaped using the effect depends % escape convention.
The State-Info production is expanded upon the type in descriptions of access control involved.
The Depth header expresses the general semantics of a LOCK
method request when invoked on a collection (note that
specific lock types may restrict state token types, and is intended to contain the effect of a lock, state
description information for
example limiting the allowable values of 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 ">")
The If-State-Match header is intended to have similar
functionality to the Depth header):
A Depth If-Match header (defined defined in section 14.25 of
RFC 2068.
If the namespace draft) may be used
on a LOCK method when the LOCK method AND keyword is applied to a
collection resource. The legal values for Depth on a LOCK
are 0, 1, used and Infinity. A Depth all of 0 instructs the
resource to just lock the container. As previously
mentioned, depending on state tokens identify
the type state of lock, the lock affects resource, then the ability to add or remove members of server MAY perform the container.
@.A Depth of 1 means that
requested method. If the container OR keyword is locked used and a LOCK
is executed on the container’s propagate members with a
Depth any of 0 and If-Range, If-Modified-Since, If-Unmodified-
Since, If-Match and If-None-Match headers are dropped.
However, the effects state
tokens identifies the current state of the LOCK MUST be atomic in that
either resource, then server
MAY perform the container and all of its members are locked or
no lock is granted. The result requested method. If neither of a Depth 1 lock the keyword
requirements is a
single lock token which represents met, the lock on server MUST NOT perform the
container requested
method, and all of its members. This lock token may be
used in an If-State-Match or If-Not-State-Match 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 ">")
The If-None-State-Match header
against is intended to have similar
functionality to the If-None-Match header defined in section
14.26 of RFC 2068.
If any of the resources covered by the lock. Since state tokens identifies the lock token represents a lock on all current state of the resources, an
UNLOCK using that token will remove
resource, the lock from all
included resources, not just server MUST NOT perform the resource requested method.
Instead, if the UNLOCK request method was
executed on.
@.A Depth of infinity means that GET, HEAD, INDEX, or GETMETA,
the LOCK is recursively
executed, server SHOULD respond with a Depth 304 (Not Modified) response,
including the cache-related entity-header fields (particularly
ETag) of infinity, on the collection and
all current state of its propagate members and the resource. For all of their propagate
members. As other
request methods, the server MUST respond with a Depth status of 412
(Precondition Failed).
If none of 1, the LOCK must be granted in
total or not at all. Otherwise the lock operates in state tokens identifies the
same manner as a Depth current state of 1 lock.
The default behavior when locking a container is to act as
if a “Depth: 0” header had been placed on the method.
5.2.3 Locking Replicated Resources
Some servers automatically replicate resources across
multiple URLs. In such a circumstance
resource, the server MAY only
accept a lock on one of the URLs if perform the server can guarantee requested method.
Note that the lock will be honored across all the URLs.
5.2.4 Interaction "AND" and "OR" keywords specified with other Methods
Only two methods, MOVE and DELETE, have side effects which
involve locks. When a resource is moved, its lock SHOULD be
moved with it. However the If-
State-
Match header are intentionally not defined for If-None-State-
Match, because this may functionality is not always be possible and
there required.
4.4 State Token Header
State-Token-Header = "State-Token" ":" 1#("<" State-Token ">")
The State Token header is currently no proposal intended to create a header which
would specify that the lock request should fail if the
resource’s locks can not be maintained. A COPY MUST NOT copy
any locks on the source resource over have similar functionality
to the destination
resource. Deleting a resource MUST remove all locks on the
resource.
5.2.5 Lock Compatibility Table etag header defined in section 14.20 of RFC 2068. The table below describes the behavior that occurs when a
lock request is made on a resource.
Current lock state/ Shared Lock Exclusive Lock
Lock request
None True True
Shared Lock True False
Exclusive Lock False False*
Legend: True = lock MAY be granted. False = lock MUST NOT
be granted. *=if the principal requesting the lock is the
owner
purpose of the lock, the lock MAY be regranted.
The current lock tag is to return state of tokens defined on a
resource is given in a response. The contents of the
leftmost column, state-token are not
guaranteed to be exhaustive and lock requests are listed in the first
row. The intersection of generally used to return a row and column gives
new state token that has been defined as the result of a lock request. method.
For example, if a shared lock is held LOCK method were successfully executed on a resource, and an exclusive lock is requested,
resource the table
entry is “false”, indicating response would include a state token header with the
lock must not be granted.
If an exclusive lock is re-requested by the principal who
owns the lock, state token included.
4.5 E-Tags
E-tags have already been deployed using the lock MAY If-Match and If-None-
Match headers. Introducing two mechanisms to express e-tags
would only confuse matters, therefore e-tags should continue to
be regranted. If expressed using quoted strings and the lock If-Match and If-None-
Match headers.
5 Locking
5.1 Problem Description - Overview
Locking is
regranted, the same lock token used to arbitrate access to a resource amongst
principals that have equal access rights to that was previously issued
MUST be returned.
5.2.6 Status Codes
412 “Precondition Failed” – The included state-token was not
enforceable on this resource.
416 “Locked” – The resource is locked so the method has been
rejected.
5.2.7 Example
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Lock-Info: LockType=Write LockScope=Exclusive
Owner: <http://www.ics.uci.edu/~ejw/contact.html>
HTTP/1.1 200 OK
State-Token: StateToken:Type=^DAV:/LOCK/DAVLOCK^:Res=^http:/
/www.ics.uci.edu/workspace/webdav/proposal.doc^:LockType=Wri
te:LockScope=Exclusive:ServerID=12382349AdfFFF
Time-Out: ClockType=Activity TimeType=second;604800
This example shows draft allows locks to vary over two parameters, the successful creation number
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 for principals involved and the owner type of the lock. The server
has an activity-based timeout policy in place on this
resource, which causes the lock access to automatically be removed
after 1 week (604800 seconds). The response has a Lock-Token
header that gives the state token URL granted. This
draft will only provide for the lock token
generated by this lock request.
5.2.8 Lock-Info Request Header
The Lock-Info header specifies the scope and type definition of a lock locking for a LOCK method request. The one
access type, write. However, the syntax specification below is
extensible, allowing new type and scope identifiers extensible enough to be
added.
LockInfo = “Lock-Info” “:” DAVLockType SP DAVLockScope CRLF
DAVLockType = “LockType” “=” DAVLockTypeValue
DAVLockTypeValue = (“Write” | *(uchar | reserved))
DAVLockScope = “LockScope” “=” DAVLockScopeValue
DAVLockScopeValue = (“Exclusive” |”Shared” | *(uchar |
reserved))
5.2.9 Owner Request Header
5.2.9.1 Problem Description
When discovering
allow for the list of owners specification of locks on a resource, other access types. It is a principal may want to be able to contact the owner
directly. For goal
of this to proposal that it use the same access verbs as will be possible
defined in the access control draft.
5.1.1 Exclusive Vs. Shared Locks
The most basic form of LOCK is an exclusive lock. This is a lock discovery
mechanism must provide enough information for
where the lock owner
to be contacted.
5.2.9.2 Solution Requirements
Not all systems have authentication procedures that provide
sufficient information to identify a particular user access right in a
way that question is meaningful only granted to a human. single
principal. The need for this arbitration results from a desire to
avoid having to constantly merge results. In addition, fact, many systems users so
dislike having to merge that do have sufficient information, such as they would rather serialize their
access to a name and e-
mail address, do not resource rather than have the ability to associate this
information with constantly perform
merges.
However, there are times when the lock discovery mechanism. Therefore goal of a
means lock is needed not to allow principals
exclude others from exercising an access right but rather to
provide
authentication in a manner which will be meaningful mechanism for principals to a
human.
The From header (defined in RFC 2068), which contains only
an email mailbox, is not sufficient for the purposes of
quick identification. When desperately looking indicate that they intend
to exercise their access right. Shared locks are provided for someone
this case. A shared lock allows multiple principals to remove receive a
lock, e-mail is often not sufficient. A
telephone number (cell number, pager number, etc.) would be
better. Furthermore, the email address in the From field may
or may not support including hence any principal with appropriate access can get the owners name and
lock.
With shared locks there are two trust sets that name
is often set to an alias anyway. Therefore affect a header more
flexible than From is required.
5.2.9.3 Syntax
Owner = "Owner" ":" ((“<” URI “>”) | quoted-string)
resource. The URI SHOULD provide a means first trust set is created by access permissions.
Principals who are trusted, for either directly
contacting example, may have permission to
write the principal (such as a telephone number or e-
mail URI), or for discovering resource, those who are not, don't. Among those who
have access permission to write the principal (such as resource, the
URL set of
principals who have taken out a homepage). The quoted string SHOULD provide shared lock also must trust each
other, creating a
means for directly contacting (probably) smaller trust set within the principal, such as a name
and telephone number.
5.2.10 Time-Out Header
5.2.10.1 Problem Description
In a perfect world principals take out locks, use access
permission write set.
Starting with every possible principal on the
resource as needed, and then remove Internet, in most
situations the lock when it is no
longer needed. However, this scenario is frequently vast majority of these principals will not
completed, leaving active but unused locks. Reasons for this
include client programs crashing and loosing information
about locks, users leaving their systems for the day and
forgetting have
write access to remove their locks, etc. As a result of this
behavior, servers need given resource. Of the small number who do
have write access, some principals may decide to establish a policy guarantee their
edits are free from overwrite conflicts by which they
can remove using exclusive write
locks in conjunction with a lock without input from precondition header (If-State-Match)
that checks for existence of the lock owner. Once
such a policy is instituted, the server also needs a
mechanism prior to inform writing the principal
resource. Others may decide they trust their collaborators (the
potential set of collaborators being the policy.
5.2.10.2 Solution Requirements
There are two basic lock removal policies, administrator set of principals who
have write permission) and
time based remove. In the first case use a shared lock, which informs their
collaborators that a principal other than is potentially working on the lock owner has sufficient access rights
resource.
The WebDAV extensions to order the
lock removed, even though they did HTTP do not take it out. User-
agents MUST assume that such a mechanism is available and
thus locks need to provide all of the
communications paths necessary for principals to coordinate their
activities. When using shared locks, principals may arbitrarily disappear at use any time. If their
actions require confirmation out
of band communication channel to coordinate their work (e.g.,
face-to-face interaction, written notes, post-it notes on the existence
screen, telephone conversation, email). The intent of a shared
lock then
the If-State headers are available.
The second solution, is the time based removal policy.
Activity based systems set to let collaborators know who else is potentially working
on a timer as soon as resource.
Why not use exclusive write locks all the time? Experience from
initial Web distributed authoring systems has indicated that
exclusive write locks are often too rigid. An exclusive write
lock is
taken out. Every time used to enforce a method is executed on particular editing process: take out
exclusive write lock, read the resource, perform edits, write the timer is reset. If
resource, release the timer runs out, lock. What happens if the lock is
removed.
Finally, some systems only allow locks isn't
released? While the time-out mechanism provides one solution, if
you need to exist for force the
duration release of a session, where lock immediately, it doesn't
help much. Granted, an administrator can release the lock for
you, but this could become a session is defined as significant burden for large sites.
Further, what if the
time when administrator can't be reached immediately?
Despite their potential problems, exclusive write locks are
extremely useful, since often a guarantee of freedom from
overwrite conflicts is exactly what is needed. The solution:
provide exclusive write locks, but also provide a less strict
mechanism in the HTTP connection that was form of shared locks which can be used by a set
of people who trust each other and who have access to take out the
lock remains connected. This mechanism is used a
communications channel external to allow
programs HTTP which are likely to can be improperly exited, such as
JAVA programs running used to
negotiate writing to the resource.
5.1.2 Required Support
A DAV compliant server is not required to support locking in a browser, any
form. If the server does support locking it may choose to take out locks
without leaving a lot support
any combination of ownerless exclusive and shared locks around when for any access
types.
The reason for this flexibility is that server implementers have
said that they are improperly exited.
5.2.10.3 Syntax
TimeOut = "Time-Out" ":" ((TimeOutType SP Session) |
TimeOutVal |
Session) CRLF
TimeOutType = ClockType SP TimeType
ClockType = “ClockType” “=” ClockTypeValue
ClockTypeValue = “Activity”
TimeType = “TimeType” “=” TimeTypeValue
TimeTypeValue = “Second” “;” DAVTimeOutVal
DAVTimeOutVal = 1*digit
Session = “Session” “=” (“Yes” | “No”)
The “Second” TimeType specifies willing to accept minimum requirements on all
services but locking. Locking policy strikes to the number very heart of seconds
their resource management and versioning systems and they require
control over what sort of locking will be made available. For
example, some systems only support shared write locks while
others only provide support for exclusive write locks. As each
system is sufficiently different to merit exclusion of certain
locking features, the authors are proposing that
may elapse before locking be
allowed as the sole axis of negotiation within DAV.
5.2 LOCK Method
5.2.1 Operation
A lock method invocation creates the lock is automatically removed. specified by the Lock-
Info header on the request-URI. Lock method requests SHOULD NOT
have a request body. A
server user-agent SHOULD submit an Owner header
field with a lock request.
A successful response to a lock invocation MUST not generate include a time out value for “second”
greater than 2^32-1. Lock-
Token header. If no the server supports a time based system is in use then lock removal
mechanism on the resource, a Time-Out header
MUST NOT be returned. The Time-Out header MUST only be
returned in successful lock invocation SHOULD
return a response to Time-Out header.
5.2.2 Effect of Locks on Properties and Containers
By default a LOCK request.When session lock affects the entire state of the resource,
including its associated properties. As such it is set illegal to yes then whatever clocktype and timetype is being used,
their effects are scoped within that particular session. So
an absolute
specify a lock with on a ten day expiration period will only
remain active so long as the session remains active. A
DAVTimeOutVal value must be greater than zero.
Clients MAY include TimeOut headers in their LOCK requests.
However property. For containers, a lock also affects
the server is not required ability to honor add or even consider remove members. The nature of the request. effect
depends upon the type of access control involved. The primary purpose in allowing clients to
submit a TimeOut Depth
header is to inform the server if expresses the
client is requesting general semantics of a session based lock. If LOCK method request
when invoked on a timeout is
associated with collection (note that specific lock types may
restrict the effect of a lock, for example limiting the server MUST return a TimeOut allowable
values of the Depth header):
· A Depth header with a valid value.
5.2.11 State-Token Header
5.2.11.1 Problem Definition
Program A, (defined in the namespace draft) may be used by User A, takes out a write lock
on a
resource. Program B, also run by User A, then proceeds LOCK method when the LOCK method is applied to
perform a PUT to the locked
collection
resource. The PUT will succeed
because locks are associated with a principal, not legal values for Depth on a
program, LOCK are 0, 1, and thus program B, because it is acting with
principal A’s credential, will be allowed
Infinity. A Depth of 0 instructs the resource to perform just lock the
PUT. In reality program B had no knowledge
container. As previously mentioned, depending on the type of
lock, the lock and
had it had such knowledge, would not have overwritten affects the
resource. Hence, a mechanism is needed ability to prevent different
programs from accidentally ignoring locks taken out by other
programs with add or remove members of
the same authorization.
5.2.11.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 container.
· A Depth of 1 means that clients guess what sorts the container is locked and a LOCK
is executed on the container’s propagate members with a Depth
of locks might be used
0 and use if-state-match If-Range, If-Modified-Since, If-Unmodified-Since, If-
Match
and If-None-Match headers with
wildcards to prevent collisions. The problem with trying to
“guess” which locks are being used is that new lock types
might be introduced, and dropped. However, the program would not know to
“guess them”. So, for example, a client might put effects of
the LOCK MUST be atomic in an if-
state-match header with a wildcard specifying that if any
write either the container and all of
its members are locked or no lock is outstanding then the operation should fail.
However a new read/write lock could be introduced which the
client would not know to put in the header.
5.2.11.3 State-Token Header granted. The State-Token header is returned in result of a successful response
to the LOCK method or
Depth 1 lock is used as a request header with the
UNLOCK method.
The State-Token header containing a single lock token owned by the
request principal is used by which represents the principal lock
on arbitrary
method to indicate that
the principal is aware container and all of the
specified lock. If the State-Token header with the
appropriate its members. This lock token is not included the request MUST may be
rejected, even though the requesting principal has
authorization to make modifications specified by
used
in an If-State-Match or If-Not-State-Match header against any
of
the lock
type. This injunction does not apply to methods that are not
affected resources covered by the principal’s lock.
For example, Program A, used by user A, takes out a write Since the lock on a resource. Program A then makes token
represents a number of PUT
requests lock on the locked resource, all the requests contain a
State-Token header which includes resources, an UNLOCK using that
token will remove the write lock state
token. Program B, also run by User A, then proceeds to
perform a PUT to from all included resources, not
just
the locked resource. However program B resource the UNLOCK was
not aware executed on.
· A Depth of infinity means that the existence LOCK is recursively
executed, with a Depth of infinity, on the lock collection and so does not
include the appropriate state-token header. The method is
rejected even though principal A is authorized to perform
the PUT. Program B can, if it so chooses, now perform lock
discovery all of
its propagate members and obtain all of their propagate members. As with
a Depth of 1, the lock token. Note that program A and
B can perform GETs without using LOCK must be granted in total or not at all.
Otherwise the state-token header
because lock operates in the ability to perform a GET is not affected by same manner as a
write Depth of 1
lock.
Note that having
The default behavior when locking a 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 container is used by the
server, not based to act as if a
"Depth: 0" header had been placed on the secrecy of the token values.
5.3 Write Lock
A write lock prevents method.
5.2.3 Locking Replicated Resources
Some servers automatically replicate resources across multiple
URLs. In such a principal without circumstance the lock from
successfully executing server MAY only accept a PUT, POST, DELETE, MKCOL,
PROPPATCH, PATCH, ADDREF or DELREF lock on
one of the locked resource.
All URLs if the server can guarantee that the lock will be
honored across all the URLs.
5.2.4 Interaction with other Methods
Only two methods, GET in particular, function independent
of the lock.
While those without MOVE and DELETE, have side effects which
involve locks. When a write resource is moved, its lock SHOULD be moved
with it. However this may not alter a property on
a resource it is still always be possible for the values of live
properties to change, even while locked, due to the
requirements of their schemas. Only dead properties and live
properties defined to respect locks are guaranteed to not
change while locked.
It there is possible
currently no proposal to assert create a write header which would specify that
the lock request should fail if the resource’s locks can not be
maintained. A COPY MUST NOT copy any locks on a null the source resource in
order
over to lock the name. Please note, however, that locking destination resource. Deleting a
null resource effectively makes MUST remove
all locks on the resource non-null as resource.
5.2.5 Lock Compatibility Table
The table below describes the
resource now has behavior that occurs when a lock related properties defined
request is made on it.
Write locking a container also prevents adding or removing
members of the container. This means that attempts to
PUT/POST a resource into the immediate name space of the
write locked container resource.
Current lock state/ Shared Lock Exclusive Lock
Lock request
None True True
Shared Lock True False
Exclusive Lock False False*
Legend: True = lock MAY be granted. False = lock MUST fail if NOT be
granted. *=if the principal requesting the action does not have the write lock on is the container. In
order to keep owner of
the behavior lock, the lock MAY be regranted.
The current lock state of locking containers consistent
all locks on containers MUST contain a Depth header equal to
infinity, any other value is illegal.
5.4 Lock Tokens
5.4.1 Problem Description
It resource is possible that once a lock has been granted it may be
removed without given in the leftmost
column, and lock owner’s knowledge. This can cause
serialization problems if the lock owner executes methods
thinking their lock is still requests are listed in effect. Thus a mechanism is
needed for a principal to predicate the successful execution
of a message upon the continuing existence of a lock.
5.4.2 Proposed Solution first row. The proposed solution is to provide
intersection of a lock token in row and column gives the
response result of a lock
request. The For example, if a shared lock token is held on a type of
state token resource,
and describes a particular lock. The same an exclusive lock is requested, the table entry is "false",
indicating the lock
token must never not be repeated on a particular resource. This
prevents problems with long held outstanding granted.
If an exclusive lock tokens
being confused with newer tokens. This uniqueness
requirement is re-requested by the same as for e-tags. This requirement also
allows for tokens to principal who owns
the lock, the lock MAY be submitted across resources and
servers without fear of confusion.
5.4.3 Lock Token Definition
The regranted. If the lock token is returned in the State-Token header in regranted,
the
response to a LOCK method. The same lock token can also that was previously issued MUST be
discovered through lock discovery returned.
5.2.6 Status Codes
412 "Precondition Failed" - The included state-token was not
enforceable on a this resource.
Lock-Token-URL = “StateToken:” Type “:” Resources “:” State-
Info
Type = “Type” “=” “^DAV:/LOCK/DAVLOCK^”
Resources = “Res” “=” 1*(“^” Caret-Encoded-URI “^”)
Caret-Encoded-URI = <This is a URI which has all “^”s %
encoded.>
State-Info = DAVLockScope “:” DAVLockType “:” ServerID ;
DAVLockScope, DAVLockType defined in Lock-Info header
ServerID = “ServerID” “=” *(uchar | reserved)
416 "Locked" - The ServerID resource is a field for use by locked so the server. Its most
basic purpose is to put in a unique identifier to guarantee
that a server will never confuse an old lock token with a
newer one. However the server is free to use the field to
record whatever information it deems fit. The field is
opaque to clients.
5.5 UNLOCK Method
5.5.1 Problem Definition
The UNLOCK method removes the lock identified by the lock
token in the State-Token header from the Request-URI.
5.5.2 has been
rejected.
5.2.7 Example
UNLOCK
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
State-Token: StateToken:Type=^DAV:/LOCK/DAVLOCK^:Res=^http:/
/www.ics.uci.edu/workspace/webdav/proposal.doc^:LockType=Wri
te:LockScope=Exclusive:ServerID=12382349AdfFFF
Lock-Info: LockType=Write LockScope=Exclusive
Owner: <http://www.ics.uci.edu/~ejw/contact.html>
HTTP/1.1 200 OK
In this example,
State-Token: StateToken:Type=^DAV:/LOCK/DAVLOCK^:Res=^http://www.
ics.uci.edu/workspace/webdav/proposal.doc^:LockType=Write:LockSco
pe=Exclusive:ServerID=12382349AdfFFF
Time-Out: ClockType=Activity TimeType=second;604800
This example shows the successful creation of an exclusive write
lock from example on resource
http://webdav.sb.aol.com/workspace/webdav/proposal.doc. The
resource http://www.ics.uci.edu/~ejw/contact.html contains
contact information for the owner of Section 2.9 is
removed from the resource at
http://webdav.sb.aol.com/workspace/webdav/proposal.doc
5.6 Discovery Mechanisms
5.6.1 Lock Type Discovery
5.6.1.1 Problem Definition
Since lock. The server has an
activity-based timeout policy in place on this resource, which
causes the lock support is optional, a client trying to
lock a resource on automatically be removed after 1 week (604800
seconds). The response has a server can either try Lock-Token header that gives the lock and hope
state token URL for the best or can perform some form of discovery to
determine what lock types token generated by this lock
request.
5.2.8 Lock-Info Request Header
The Lock-Info header specifies the server actually supports, then
formulate scope and type of a supported lock for a
LOCK method request. This The syntax specification below is known as lock type
discovery. Lock
extensible, allowing new type discovery is not the same as
discovering what access control types are supported, as
there may and scope identifiers to 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 of the lock types supported by added.
LockInfo = "Lock-Info" ":" DAVLockType SP DAVLockScope CRLF
DAVLockType = "LockType" "=" DAVLockTypeValue
DAVLockTypeValue = ("Write" | *(uchar | reserved))
DAVLockScope = "LockScope" "=" DAVLockScopeValue
DAVLockScopeValue = ("Exclusive" |"Shared" | *(uchar | reserved))
5.2.9 Owner Request Header
5.2.9.1 Problem Description
When discovering the resource.
Schema: http://www.ietf.org/standards/dav/
Values: An XML document containing zero or more LockEntry
XML elements.
Description: The SupportedLock property list of owners of locks on a resource
returns resource, a listing of the combinations of scope and access
types which
principal may want to be specified in a able to contact the owner directly. For
this to be possible the lock request on discovery mechanism must provide
enough information for the
resource. Note lock owner to be contacted.
5.2.9.2 Solution Requirements
Not all systems have authentication procedures that the actual contents are themselves
controlled by access controls so provide
sufficient information to identify a server particular user in a way
that is meaningful to a human. In addition, many systems that do
have sufficient information, such as a name and e-mail address,
do not required have the ability to
provide associate this information with the client
lock discovery mechanism. Therefore a means is not authorized needed 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 allow
principals to provide authentication in a DAVLockType/LockScope pair manner which may will be
legally used with
meaningful to a LOCK on the specified resource.
Schema: HYPERLINK 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 XML Element
Name: http://www.ietf.org/standards/dav/lockscope
Purpose: Lists a DAVLockScope
Schema: http://www.ietf.org/standards/dav/
Parent: LOCKENTRY
Values: DAVLockScopeValue
5.6.2 Active Lock Discovery
5.6.2.1 Problem Definition
If another principal locks a resource that a principal
wishes to access, it human.
The From header (defined in RFC 2068), which contains only an
email mailbox, is useful not sufficient for the second principal to
be able purposes of quick
identification. When desperately looking for someone to find out who the first principal is.
5.6.2.2 Solution Requirements
The lock discovery mechanism should provide remove a list of who
has
lock, e-mail is often not sufficient. A telephone number (cell
number, pager number, etc.) would be better. Furthermore, the resource locked, what locks they have, and what
their lock tokens are. The lock tokens are useful in shared
lock situations where two principals
email address in particular the From field may or may want
to guarantee that they do not overwrite each other. The lock
tokens are also useful for administrative purposes so support including
the owners name and that
an administrator can remove a lock by referring name is often set 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 an alias anyway.
Therefore a resource
Schema: http://www.ietf.org/standards/dav/
Values= An XML document containing zero or header more ActiveLock
XML elements.
Description: flexible than From is required.
5.2.9.3 Syntax
Owner = "Owner" ":" (("<" URI ">") | quoted-string)
The LOCKDISCOVERY property returns URI SHOULD provide a listing of
who has means for either directly contacting the
principal (such as a lock, what type telephone number or e-mail URI), or for
discovering the principal (such as the URL of lock they have, a homepage). The
quoted string SHOULD provide a means for directly contacting the time
principal, such as a name and telephone number.
5.2.10 Time-Out Header
5.2.10.1 Problem Description
In a perfect world principals take out
type locks, use the resource as
needed, and then remove the time remaining on lock when it is no longer needed.
However, this scenario is frequently not completed, leaving
active but unused locks. Reasons for this include client programs
crashing and loosing information about locks, users leaving their
systems for the time out, day and forgetting to remove their locks, etc. As
a result of this behavior, servers need to establish a policy by
which they can remove a lock without input from the
associated lock token. The server owner.
Once such a policy is free instituted, the server also needs a
mechanism to withhold any or
all inform the principal of this information if the requesting policy.
5.2.10.2 Solution Requirements
There are two basic lock removal policies, administrator and time
based remove. In the first case a principal does not
have other than the lock
owner has sufficient access rights to see order the requested data.
5.6.2.4 ACTIVELOCK XML Element
Name: http://www.ietf.org/standards/dav/activelock
Purpose: A multivalued XML element lock removed,
even though they did not take it out. User-agents MUST assume
that describes such a
particular active lock on mechanism is available and thus locks may arbitrarily
disappear at any time. If their actions require confirmation of
the existence of a resource
Schema: http://www.ietf.org/standards/dav/
Parent: A LOCKDISCOVERY entry
Values= LOCKTYPE LOCKSCOPE 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 lock then the timeout associated
with If-State headers are available.
The second solution, is the time based removal policy. Activity
based systems set a timer as soon as the lock
Schema: http://www.ietf.org/standards/dav/
Parent: ACTIVELOCK
Values= CLOCKTYPE TIMETYPE TIMEOUTVAL
5.6.2.7 CLOCKTYPE XML Element
Name: http://www.ietf.org/standards/dav/clocktype
Purpose: Returns is taken out. Every
time a method is executed on the resource, the timer is reset. If
the timer runs out, the clock type used with this lock
Schema: http://www.ietf.org/standards/dav/
Parent: TIMEOUT
Values= ClockTypeValue
5.6.2.8 TIMETYPE XML Element
Name: http://www.ietf.org/standards/dav/clocktype
Purpose: Returns is removed.
Finally, some systems only allow locks to exist for the duration
of a session, where a session is defined as the time type when the
HTTP connection that was used with this to take out the lock
Schema: http://www.ietf.org/standards/dav/
Parent: TIMEOUT
Values= remains
connected. This mechanism is used to allow programs which are
likely to be improperly exited, such as JAVA programs running in
a browser, to take out locks without leaving a lot of ownerless
locks around when they are improperly exited.
5.2.10.3 Syntax
TimeOut = "Time-Out" ":" ((TimeOutType SP Session) | TimeOutVal |
Session) CRLF
TimeOutType = ClockType SP TimeType
ClockType = "ClockType" "=" ClockTypeValue
ClockTypeValue = "Activity"
TimeType = "TimeType" "=" TimeTypeValue
5.6.2.9 TIMEOUTVAL XML Element
Name: http://www.ietf.org/standards/dav/timeoutval
Purpose: Returns
TimeTypeValue = "Second" ";" DAVTimeOutVal
DAVTimeOutVal = 1*digit
Session = "Session" "=" ("Yes" | "No")
The "Second" TimeType specifies the amount number of time left on seconds that may
elapse before the lock
Schema: http://www.ietf.org/standards/dav/
Parent: TIMEOUT
Values= is automatically removed. A server MUST
not generate a time out value for "second" greater than 2^32-1.
If no time based system is in use then a Time-Out header MUST NOT
be returned. The Time-Out header MUST only be returned in a
response to a LOCK request.When session is set to yes then
whatever clocktype and timetype is being used, their effects are
scoped within that particular session. So an absolute lock with a
ten day expiration period will only remain active so long as the
session remains active. A DAVTimeOutVal
5.6.2.10 LOCKTOKEN XML Element
Name: http://www.ietf.org/standards/dav/statetoken
Purpose: Returns value must be greater
than zero.
Clients MAY include TimeOut headers in their LOCK requests.
However the server is not required to honor or even consider the
request. The primary purpose in allowing clients to submit a
TimeOut header is to inform the server if the client is
requesting a session based lock. If a timeout is associated with
the lock, the server MUST return a TimeOut header with a valid
value.
5.2.11 State-Token Header
5.2.11.1 Problem Definition
Program A, used by User A, takes out a write lock token
Schema: http://www.ietf.org/standards/dav/
Parent: ACTIVELOCK
Values= XML:REF
Description: on a resource.
Program B, also run by User A, then proceeds to perform a PUT to
the locked resource. The REF contains PUT will succeed because locks are
associated with a Lock-Token-URL.
6 Version Control
[TBD]
7 Internationalization Support
[TBD]
8 Security Considerations
[TBD]
9 Acknowledgements
Roy Fielding, Richard Taylor, Larry Masinter, Henry Sanders,
Judith Slein, Dan Connolly, David Durand, Henrik Nielsen,
Paul Leach. Kenji Ota, Kenji Takahashi. Jim Cunningham.
Others, TBD.
10 References
[Berners-Lee, 1997] T. Berners-Lee, "Metadata Architecture."
Unpublished white paper, January 1997.
http://www.w3.org/pub/WWW/DesignIssues/Metadata.html.
[Bray, 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, 1997] D. Connolly, R. Khare, H.F. Nielsen, “PEP -
an Extension Mechanism for HTTP”, Internet draft, work-in-
progress. draft-ietf-http-pep-03.txt,
ftp://ds.internic.net/internet-drafts/draft-ietf-http-pep-
03.txt.
[Lasher, Cohen, 1995] R. Lasher, D. Cohen, "A Format for
Bibliographic Records," RFC 1807. Stanford, Myricom. June,
1995.
[Maloney, 1996] M. Maloney, "Hypertext Links in HTML."
Internet draft (expired), work-in-progress, January, 1996.
[MARC, 1994] Network Development principal, not a program, and MARC Standards, Office,
ed. 1994. "USMARC Format for Bibliographic Data", 1994.
Washington, DC: Cataloging Distribution Service, Library thus program B,
because it is acting with principal A’s credential, will be
allowed to perform the PUT. In reality program B had no knowledge
of
Congress.
[Miller et.al., 1996] J. Miller, T. Krauskopf, P. Resnick,
W. Treese, "PICS Label Distribution Label Syntax the lock and
Communication Protocols" Version 1.1, W3C Recommendation
REC-PICS-labels-961031. http://www.w3.org/pub/WWW/TR/REC-
PICS-labels-961031.html.
[WebDAV, 1997] WEBDAV Design Team. “A Proposal for Web
Metadata Operations.” Unpublished manuscript.
http://www.ics.uci.edu/~ejw/authoring/proposals/metadata.htm
l
[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, had it had such knowledge, would not have
overwritten the resource. Hence, a transformation format mechanism is needed to prevent
different programs from accidentally ignoring locks taken out by
other programs with the same authorization.
5.2.11.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 Unicode
locks might be used 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.
11 Authors' Addresses
Yaron Y. Goland
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Email yarong@microsoft.com
E. J. Whitehead, Jr.
Dept. Of Information use if-state-match headers with wildcards
to prevent collisions. The problem with trying to "guess" which
locks are being used is that new lock types might be introduced,
and Computer Science
University the program would not know to "guess them". So, for example,
a client might put 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 the client would not know to put in the header.
5.2.11.3 State-Token Header
The State-Token header is returned in a successful response to
the LOCK method or is used as a request header with the UNLOCK
method.
The State-Token header containing a lock token owned by the
request principal is used by the principal on arbitrary method to
indicate that the principal is aware of California, Irvine
Irvine, CA 92697-3425
Email: ejw@ics.uci.edu
Asad Faizi
Netscape
685 East Middlefield Road
Mountain View, CA 94043
Email: asad@netscape.com
Stephen R Carter
Novell
1555 N. Technology Way
M/S ORM F111
Orem, UT 84097-2399
Fax (801) 228 5176
Email srcarter@novell.com
Del Jensen
Novell
1555 N. Technology Way
M/S ORM F111
Orem, UT 84097-2399
Fax (801) 228 5176
Email dcjensen@novell.com
Appendix 1 - Content Type Application/XML the specified lock. If
the State-Token header with the appropriate lock token is not
included the request MUST be rejected, even though the requesting
principal has authorization to make modifications specified by
the lock type. This injunction does not apply to methods that are
not affected by the principal’s lock.
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 State-Token header
which includes the write lock state token. Program B, also run by
User A, then proceeds to perform a PUT to the locked resource.
However program B was not aware of the existence of the lock and
so does not include the appropriate state-token header. The
method is rejected even though principal A is authorized 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 the state-token header because
the ability to perform a GET is not affected by a write lock.
Note that having a 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 the secrecy of the token values.
5.3 Write Lock
A write lock prevents a principal without the lock from
successfully executing a digest PUT, POST, DELETE, MKCOL, PROPPATCH,
PATCH, ADDREF or DELREF on the locked resource. All other
methods, GET in particular, function independent of the XML data specification available at
http://www.w3.org/TR/WD-xml-lang.html
Syntax
The application/XML content type contains an XML document.
Its syntax lock.
While those without a write lock may not alter a property on a
resource it is as defined below.
XML = XMLStart *XMLEntity Close
XMLStart = “<” “XML” “>”
XMLEntity= Open *(XMLText | XMLEntity) Close
Close = “</>” | “<”“/”Entity-Name Markup“>”
Open = “<” Entity-Name *Attribute “>”
Attribute = Entity-Name “=” Quoted-String
XMLText = <An Octet Stream which uses XML encoding still possible for “<” the values of live properties
to change, even while locked, due to the requirements of their
schemas. Only dead properties and “>”>
Entity-Name = ([As-Tag “:”] Name) | (As-Tag “:”)
As-Tag = 1*Alpha
Name = (alpha | “_”) *(alpha | digit | “.” | “-“ | “_” |
other)
Other = <Other characters must be encoded>
XML element
An XML element, as live properties defined to
respect locks are guaranteed to not change while locked.
It is possible to assert a write lock on a null resource in order
to lock the BNF, is an open tag with
content followed by name. Please note, however, that locking a close tag. null
resource effectively makes the resource non-null as the resource
now has lock related properties defined on it.
Write locking a container also prevents adding or removing
members of the container. This means that attempts to PUT/POST a
resource into the immediate name space of the write locked
container MUST fail if the principal requesting the action does
not have the write lock on the container. In order to prevent
confusion with the term entity as used in HTTP, keep the term XML
element will be used.
The first XML element
behavior of a XML document locking containers consistent all locks on containers
MUST be the <XML>
XML element. This XML element tells the parser that it contain a Depth header equal to infinity, any other value is
dealing with an XML document. So long as this XML element
illegal.
5.4 Lock Tokens
5.4.1 Problem Description
It is
present the parser can be sure possible that it can parse the
document, even if XML once a lock has been extended. If XML is ever
altered in a manner that is not backwards compatible with
this specification then the content-type and the outer most
XML element MUST be changed.
Entity-Name
All XML element names must map to URIs. However due to
historical restrictions on what characters granted it may appear in an
XML element name, URIs cannot be expressed in an XML element
name. This issue is dealt with in more detail in section 10.
Entity-Names
removed without [AS] are relative URIs whose base is the enclosing Entity-Name. If lock owner’s knowledge. This can cause
serialization problems if the enclosing Entity-Name lock owner executes methods
thinking their lock is
<XML> then the Entity-Name MUST use an [AS].
Close
The close production marks the end of a XML element.
XML Encoding
In different contexts certain characters are reserved, for
example “/” can not be used in an XML element name and
“>”/”<” can not be used still in effect. Thus a value. As such these values
must be encoded as follows:
Encoding = Decimal | Hex4
Decimal = “&” Non-Zero *(“0” | Non-Zero)
Hex4 = “&u-“ 4(Hex)
Non-Zero = “1” | “2” | “3” | “4” | “5” | “6” | “7” | “8” |
“9”
Hex = “0” | Non-Zero | “A” | “B” | “C” | “D” | “E” | “F”
The numbers MUST map mechanism is
needed for a principal to predicate the UTF8 character encodings. Please
note that the “&” character must always be encoded.
Markup Modifier
The markup modifier, (“-”, after the end successful execution of an XML element)
instructs a
message upon the principal how continuing existence of a lock.
5.4.2 Proposed Solution
The proposed solution is to treat provide a XML element with an
unknown name. If lock token in the modifier response
of a lock request. The lock token is used a type of state token and the XML element
describes a particular lock. The same lock token must never be
repeated on a particular resource. This prevents problems with
long held outstanding lock tokens being confused with newer
tokens. This uniqueness requirement is
not recognized then the XML element name MUST same as for e-tags.
This requirement also allows for tokens to be stripped submitted across
resources and the XML element’s contents promoted one level servers without fear of confusion.
5.4.3 Lock Token Definition
The lock token is returned in the
parse tree. If State-Token header in the modifier
response to a LOCK method. The lock token can also be discovered
through lock discovery on a resource.
Lock-Token-URL = "StateToken:" Type ":" Resources ":" State-Info
Type = "Type" "=" "^DAV:/LOCK/DAVLOCK^"
Resources = "Res" "=" 1*("^" Caret-Encoded-URI "^")
Caret-Encoded-URI = <This is not used and a URI which has all "^"s % encoded.>
State-Info = DAVLockScope ":" DAVLockType ":" ServerID ;
DAVLockScope, DAVLockType defined in Lock-Info header
ServerID = "ServerID" "=" *(uchar | reserved)
The ServerID is a field for use by the XML element
name server. Its most basic
purpose is unknown then to put in a unique identifier to guarantee that a
server will never confuse an old lock token with a newer one.
However the XML element and its contents MUST
be ignored.
XML Syntax Shorthand server is free to use the field to record whatever
information it deems fit. The following template field is recommended for efficiently
providing a description of an XML element.
Name: opaque to clients.
5.5 UNLOCK Method
5.5.1 Problem Definition
The name of UNLOCK method removes the XML element
Purpose: A one line description of lock identified by the XML element’s
purpose.
Schema: The schema, if any, that lock token
in the XML element belongs to
Parent: XML elements that this XML element may be a child
of.
Values: A description, usually a BNF, of State-Token header from the simple and
compound values that Request-URI.
5.5.2 Example
UNLOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
State-Token: StateToken:Type=^DAV:/LOCK/DAVLOCK^:Res=^http://www.
ics.uci.edu/workspace/webdav/proposal.doc^:LockType=Write:LockSco
pe=Exclusive:ServerID=12382349AdfFFF
HTTP/1.1 200 OK
In this example, the XML element supports.
Description: Further information.
Example: An lock from example of Section 2.9 is removed
from the XML element’s use.
Appendix 2 - Parameter Syntax for Content-Type
Application/XML
HTTP 1.1 provides for resource at
http://webdav.sb.aol.com/workspace/webdav/proposal.doc
5.6 Discovery Mechanisms
5.6.1 Lock Type Discovery
5.6.1.1 Problem Definition
Since server lock support is optional, a mechanism client trying to include lock a parameter
with
resource on a content type. In order to prevent namespace
collisions server can either try the parameters lock and hope for application/XML must use the
following syntax:
Parameter = #(<”>URI<”> [“=” (token | Quoted-String)])
Schema Content-Type Parameter
Parameter = <”> http://www.w3.org/standards/xml/content-
type/schema <”> “=” <”> #URI <”>
The http://www.w3.org/standards/xml/content-type/schema/ URL
is used as a parameter to an application/xml content type.
The URL indicates that its value lists
best or can perform some subset form of discovery to determine what lock
types the
schemas defined in NameSpace parameters within server actually supports, then formulate a supported
request. This is known as lock type discovery. Lock type
discovery is not the enclosed
document. The URI can also same as discovering what access control
types are supported, as there may be used in requests to indicate
schemas that should appear in 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 of the result. lock types supported by the
resource.
Schema: http://www.ietf.org/standards/dav/
Values: An example XML document containing zero or more LockEntry XML
elements.
Description: The SupportedLock property of a resource returns a
listing of the use combinations of this parameter is to include it scope and access types which may
be specified in
an accept-type header on a lock request to indicate that on the
response should contain resource. Note that the specified namespace. Thus
actual contents are themselves controlled by access controls so a
server is not required to provide information the client is able not
authorized to inform see. If SupportedLock is available on "*" then it
MUST define the server of its support for a
particular set of namespaces. The server is not required to
return 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 result DAVLockType/LockScope pair which may be
legally used with a LOCK on the specified namespaces.
Appendix 3 – URI Path Encoding resource.
Schema: HYPERLINK 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 XML Element
Name: http://www.ietf.org/standards/dav/lockscope
Purpose: Lists a DAVLockScope
Schema: http://www.ietf.org/standards/dav/
Parent: LOCKENTRY
Values: DAVLockScopeValue
5.6.2 Active Lock Discovery
5.6.2.1 Problem Definition
A mechanism
If another principal locks a resource that a principal wishes to
access, it is needed useful for the second principal to refer be able to specific DAV properties find
out who the first principal is.
5.6.2.2 Solution Requirements
The lock discovery mechanism should provide a list of who has the
resource locked, what locks they have, and what their lock tokens
are. The lock tokens are useful in
a manner shared lock situations where
two principals in particular may want to guarantee that can handle simple, composite, and multivalued
DAV properties.
Solution Requirement they do
not overwrite each other. The reference mechanism must use the standard URL syntax lock tokens are also useful for
administrative purposes so
it can be used with both currently existing and future URLs.
For example, the syntax could be appended to that an HTTP URL to
specify administrator can remove a HTTP property
lock by referring 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 that URL.
Path Component
URIPath = “/” [segment]
Segment = (“(“ Abs-URI “)” | Rel-URI)[Index]*( “;” param)
Index = [“(“ [“-“]*digit “)”]
Abs-URI = < a resource
Schema: http://www.ietf.org/standards/dav/
Values= An absolute XML document containing zero or relative URI which more ActiveLock XML
elements.
Description: The LOCKDISCOVERY property returns a listing of who
has been URI-
Path encoded >
Rel-URI = < A relative URI for which URI-Encoding(Rel-URI)
== Rel-URI >
URI-Path encoding consists a lock, what type of lock they have, the following algorithm:
URL encode all “!” characters
Map all “/” characters to “!” characters
Please note that all relative URIs are relative to the URI
in the path segment preceding them. Hence the URI in the
first path segment MUST be an absolute URI.
The purpose of time out type and
the encoding is to allow URLs to be used as
segments without having to use % encoding time remaining on all the “/”
which produces a URL form which is extremely difficult for
humans to deal with, time out, and which changes the semantics of the
URL.
Appendix 4 - XML URI associated lock
token. The “XML” scheme server is free to be registered with IANA as a reserved
namespace that will be owned by withhold any or all of this
information if the XML group through requesting principal does not have sufficient
access rights to see the
W3C.
The new URI is defined as:
XML = “XML” “:” XML-Path
Appendix 5 - XML elements
Ref requested data.
5.6.2.4 ACTIVELOCK XML element Element
Name: XML:Ref http://www.ietf.org/standards/dav/activelock
Purpose: A multivalued XML element that indicates that its contents are describes a URI. particular
active lock on a resource
Schema: XML http://www.ietf.org/standards/dav/
Parent: Any
Value = URI
Namespace
Namespace A LOCKDISCOVERY entry
Values= LOCKTYPE LOCKSCOPE OWNER TIMEOUT LOCKTOKEN
5.6.2.5 OWNER XML element Element
Name: XML:Namespace http://www.ietf.org/standards/dav/lock/owner
Purpose: To inform the parser that a particular schema is in
use and to provide a shorthand name for referring to XML
elements related to that schema. Returns owner information
Schema: XML http://www.ietf.org/standards/dav/
Parent: Any
Value = (Ref [AS])
Description: This XML element contains two XML elements, Ref
and AS. The purpose of the XML element is to inform the
parser that a schema, identified by the value of the Ref XML
element, is in use and, when appropriate, to provide a
shorthand name to refer XML elements derived from that
schema using the AS XML element. The AS mechanism is needed
for efficiency reasons and because a URI can not be fully
specified in an XML open tag. The Namespace ACTIVELOCK
Values= XML:REF | {any valid XML element’s
scope is all siblings and their children.
AS string}
5.6.2.6 TIMEOUT XML element Element
Name: XML:AS http://www.ietf.org/standards/dav/timeout
Purpose: To provide a short name for the URI of Returns information about the schema
provided in timeout associated with
the Ref XML entity of a namespace XML entity. lock
Schema: XML http://www.ietf.org/standards/dav/
Parent: XML:Namespace
Value = 1*Alpha
Description: The AS XML entity is used to provide a
shorthand reference for the URI in the Ref XML entity of a
Namespace ACTIVELOCK
Values= CLOCKTYPE TIMETYPE TIMEOUTVAL
5.6.2.7 CLOCKTYPE XML entity. The value contained in Element
Name: http://www.ietf.org/standards/dav/clocktype
Purpose: Returns the AS clock type used with this lock
Schema: http://www.ietf.org/standards/dav/
Parent: TIMEOUT
Values= ClockTypeValue
5.6.2.8 TIMETYPE XML
entity is generated at Element
Name: http://www.ietf.org/standards/dav/clocktype
Purpose: Returns the time type used with this lock
Schema: http://www.ietf.org/standards/dav/
Parent: TIMEOUT
Values= TimeTypeValue
5.6.2.9 TIMEOUTVAL XML producer’s discretion, the
only requirement is that all AS values MUST be unique within
the contents of Element
Name: http://www.ietf.org/standards/dav/timeoutval
Purpose: Returns the parent amount of time left on the namespace element.
All lock
Schema: http://www.ietf.org/standards/dav/
Parent: TIMEOUT
Values= DAVTimeOutVal
5.6.2.10 LOCKTOKEN XML entity open tags contain a name of Element
Name: http://www.ietf.org/standards/dav/statetoken
Purpose: Returns the form As-
Tag:Name. lock token
Schema: http://www.ietf.org/standards/dav/
Parent: ACTIVELOCK
Values= XML:REF
Description: The As-Tag is the value defined in an AS XML
entity inside of a Namespace. To resolve the As-Tag:Name
into a properly formatted URI replace “As-Tag:” with the URI
provided in the Ref that the AS was defined with. Also note
that AS value also applies to any URIs defined in REF contains a Ref
inside Lock-Token-URL.
6 Version Control
[TBD]
7 Internationalization Support
[TBD]
8 Security Considerations
[TBD]
9 Acknowledgements
Terry Allen, Harald Alvestrand, Alan Babich, Dylan Barrell,
Bernard Chester, Dan Connolly, Jim Cunningham, Ron Daniel, Jr.,
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, Robert Thau, Sankar
Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, Lauren Wood
10 References
[Berners-Lee, 1997] T. Berners-Lee, "Metadata Architecture."
Unpublished white paper, January 1997.
http://www.w3.org/pub/WWW/DesignIssues/Metadata.html.
[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.
[Lasher, Cohen, 1995] R. Lasher, D. Cohen, "A Format for
Bibliographic Records," RFC 1807. Stanford, Myricom. June, 1995.
[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 Namespace.
For example,
<XML>
<XML:Namespace><Ref>http://blah;DAV/</><AS>B</></>
<XML:Namespace><Ref>B:(B:)/</><AS>C</></>
<C:Moo></>
</>
So B:(B:) translates to http://blah;DAV/(http:!!blah;DAV!)/ Congress.
[Miller et al., 1996] J. Miller, T. Krauskopf, P. Resnick, W.
Treese, "PICS Label Distribution Label Syntax and C:Moo translates to
http://blah;DAV/(http:!!blah;DAV!)/Moo.
Required XML element
Name: XML:Required
Purpose: To indicate that the read MUST understand the
associated Namespace in order to successfully process the
XML document.
Schema: XML
Parent: XML:Namespace
Value: None
The XML URI Communication
Protocols" Version 1.1, W3C Recommendation 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 Namespace
In order to prevent a logical loop the XML namespace is said
to be declared, with
Versioning on the AS value of “XML” as World Wide Web." Internet-draft, work-in-
progress, draft-ietf-webdav-requirements-02.txt,
ftp://ds.internic.net/internet-drafts/draft-ietf-webdav-
requirements-02.txt.
[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 consequence transformation format of the <XML> enclosing property.
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.
11 Authors' Addresses
Y. Y. Goland
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
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 Carter
Novell
1555 N. Technology Way
M/S ORM F111
Orem, UT 84097-2399
Email srcarter@novell.com
D. Jensen
Novell
1555 N. Technology Way
M/S ORM F111
Orem, UT 84097-2399
Email dcjensen@novell.com
----