draft-ietf-webdav-protocol-09.txt   draft-ietf-webdav-protocol-10.txt 
WEBDAV Working Group Y.Y. Goland, Microsoft WEBDAV Working Group Y.Y. Goland, Microsoft
INTERNET DRAFT E.J. Whitehead, Jr., UC Irvine INTERNET DRAFT E.J. Whitehead, Jr., UC Irvine
<draft-ietf-webdav-protocol-09> A. Faizi, Netscape <draft-ietf-webdav-protocol-10> A. Faizi, Netscape
S.R. Carter, Novell S.R. Carter, Novell
D. Jensen, Novell D. Jensen, Novell
Expires September, 1998 October 22, 1998 Expires April, 1999 November 16, 1998
HTTP Extensions for Distributed Authoring -- WEBDAV HTTP Extensions for Distributed Authoring -- WEBDAV
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 2, line 25 skipping to change at page 2, line 25
3 TERMINOLOGY ........................................................8 3 TERMINOLOGY ........................................................8
4 DATA MODEL FOR RESOURCE PROPERTIES .................................9 4 DATA MODEL FOR RESOURCE PROPERTIES .................................9
4.1 The Resource Property Model .....................................9 4.1 The Resource Property Model .....................................9
4.2 Existing Metadata Proposals ....................................10 4.2 Existing Metadata Proposals ....................................10
4.3 Properties and HTTP Headers ....................................10 4.3 Properties and HTTP Headers ....................................10
4.4 Property Values ................................................10 4.4 Property Values ................................................10
4.5 Property Names .................................................11 4.5 Property Names .................................................11
4.6 Media Independent Links ........................................11 4.6 Media Independent Links ........................................11
5 COLLECTIONS OF WEB RESOURCES ......................................11 5 COLLECTIONS OF WEB RESOURCES ......................................12
5.1 HTTP URL Namespace Model .......................................12 5.1 HTTP URL Namespace Model .......................................12
5.2 Collection Resources ...........................................12 5.2 Collection Resources ...........................................12
5.3 Creation and Retrieval of Collection Resources .................13 5.3 Creation and Retrieval of Collection Resources .................13
5.4 Source Resources and Output Resources ..........................14 5.4 Source Resources and Output Resources ..........................14
6 LOCKING ...........................................................15 6 LOCKING ...........................................................15
6.1 Exclusive Vs. Shared Locks .....................................15 6.1 Exclusive Vs. Shared Locks .....................................15
6.2 Required Support ...............................................16 6.2 Required Support ...............................................16
6.3 Lock Tokens ....................................................16 6.3 Lock Tokens ....................................................16
6.4 opaquelocktoken Lock Token URI Scheme ..........................17 6.4 opaquelocktoken Lock Token URI Scheme ..........................17
6.4.1 Node Field Generation Without the IEEE 802 Address ..........17 6.4.1 Node Field Generation Without the IEEE 802 Address ..........17
6.5 Lock Capability Discovery ......................................19 6.5 Lock Capability Discovery ......................................19
6.6 Active Lock Discovery ..........................................19 6.6 Active Lock Discovery ..........................................19
6.7 Usage Considerations ...........................................19 6.7 Usage Considerations ...........................................19
7 WRITE LOCK ........................................................20 7 WRITE LOCK ........................................................20
7.1 Methods Restricted by Write Locks ..............................20 7.1 Methods Restricted by Write Locks ..............................20
7.2 Write Locks and Lock Tokens ....................................20 7.2 Write Locks and Lock Tokens ....................................21
7.3 Write Locks and Properties .....................................20 7.3 Write Locks and Properties .....................................21
7.4 Write Locks and Null Resources .................................21 7.4 Write Locks and Null Resources .................................21
7.5 Write Locks and Collections ....................................21 7.5 Write Locks and Collections ....................................21
7.6 Write Locks and the If Request Header ..........................22 7.6 Write Locks and the If Request Header ..........................22
7.6.1 Example - Write Lock ........................................22 7.6.1 Example - Write Lock ........................................22
7.7 Write Locks and COPY/MOVE ......................................22 7.7 Write Locks and COPY/MOVE ......................................23
7.8 Refreshing Write Locks .........................................23 7.8 Refreshing Write Locks .........................................23
8 HTTP METHODS FOR DISTRIBUTED AUTHORING ............................23 8 HTTP METHODS FOR DISTRIBUTED AUTHORING ............................24
8.1 PROPFIND .......................................................24 8.1 PROPFIND .......................................................24
8.1.1 Example - Retrieving Named Properties .......................25 8.1.1 Example - Retrieving Named Properties .......................25
8.1.2 Example - Using allprop to Retrieve All Properties ..........26 8.1.2 Example - Using allprop to Retrieve All Properties ..........26
8.1.3 Example - Using propname to Retrieve all Property Names .....29 8.1.3 Example - Using propname to Retrieve all Property Names .....29
8.2 PROPPATCH ......................................................30 8.2 PROPPATCH ......................................................30
8.2.1 Status Codes for use with 207 (Multi-Status) ................31 8.2.1 Status Codes for use with 207 (Multi-Status) ................31
8.2.2 Example - PROPPATCH .........................................31 8.2.2 Example - PROPPATCH .........................................31
skipping to change at page 3, line 35 skipping to change at page 3, line 35
8.6 DELETE .........................................................34 8.6 DELETE .........................................................34
8.6.1 DELETE for Non-Collection Resources .........................34 8.6.1 DELETE for Non-Collection Resources .........................34
8.6.2 DELETE for Collections ......................................34 8.6.2 DELETE for Collections ......................................34
8.7 PUT ............................................................35 8.7 PUT ............................................................35
8.7.1 PUT for Non-Collection Resources ............................35 8.7.1 PUT for Non-Collection Resources ............................35
8.7.2 PUT for Collections .........................................36 8.7.2 PUT for Collections .........................................36
8.8 COPY Method ....................................................36 8.8 COPY Method ....................................................36
8.8.1 COPY for HTTP/1.1 resources .................................36 8.8.1 COPY for HTTP/1.1 resources .................................36
8.8.2 COPY for Properties .........................................36 8.8.2 COPY for Properties .........................................37
8.8.3 COPY for Collections ........................................37 8.8.3 COPY for Collections ........................................37
8.8.4 COPY and the Overwrite Header ...............................38 8.8.4 COPY and the Overwrite Header ...............................38
8.8.5 Status Codes ................................................38 8.8.5 Status Codes ................................................38
8.8.6 Example - COPY with Overwrite ...............................39 8.8.6 Example - COPY with Overwrite ...............................39
8.8.7 Example - COPY with No Overwrite ............................39 8.8.7 Example - COPY with No Overwrite ............................39
8.8.8 Example - COPY of a Collection ..............................39 8.8.8 Example - COPY of a Collection ..............................40
8.9 MOVE Method ....................................................40 8.9 MOVE Method ....................................................40
8.9.1 MOVE for Properties .........................................40 8.9.1 MOVE for Properties .........................................41
8.9.2 MOVE for Collections ........................................41 8.9.2 MOVE for Collections ........................................41
8.9.3 MOVE and the Overwrite Header ...............................42 8.9.3 MOVE and the Overwrite Header ...............................42
8.9.4 Status Codes ................................................42 8.9.4 Status Codes ................................................42
8.9.5 Example - MOVE of a Non-Collection ..........................42 8.9.5 Example - MOVE of a Non-Collection ..........................42
8.9.6 Example - MOVE of a Collection ..............................43 8.9.6 Example - MOVE of a Collection ..............................43
8.10 LOCK Method ....................................................43 8.10 LOCK Method ....................................................44
8.10.1 Operation ...................................................44 8.10.1 Operation ...................................................44
8.10.2 The Effect of Locks on Properties and Collections ...........44 8.10.2 The Effect of Locks on Properties and Collections ...........44
8.10.3 Locking Replicated Resources ................................44 8.10.3 Locking Replicated Resources ................................45
8.10.4 Depth and Locking ...........................................44 8.10.4 Depth and Locking ...........................................45
8.10.5 Interaction with other Methods ..............................45 8.10.5 Interaction with other Methods ..............................45
8.10.6 Lock Compatibility Table ....................................45 8.10.6 Lock Compatibility Table ....................................46
8.10.7 Status Codes ................................................46 8.10.7 Status Codes ................................................46
8.10.8 Example - Simple Lock Request ...............................46 8.10.8 Example - Simple Lock Request ...............................47
8.10.9 Example - Refreshing a Write Lock ...........................48 8.10.9 Example - Refreshing a Write Lock ...........................48
8.10.10 Example - Multi-Resource Lock Request ......................49 8.10.10 Example - Multi-Resource Lock Request ......................49
8.11 UNLOCK Method ..................................................50 8.11 UNLOCK Method ..................................................50
8.11.1 Example - UNLOCK ............................................50 8.11.1 Example - UNLOCK ............................................50
9 HTTP HEADERS FOR DISTRIBUTED AUTHORING ............................51 9 HTTP HEADERS FOR DISTRIBUTED AUTHORING ............................51
9.1 DAV Header .....................................................51 9.1 DAV Header .....................................................51
9.2 Depth Header ...................................................51 9.2 Depth Header ...................................................51
9.3 Destination Header .............................................52 9.3 Destination Header .............................................52
9.4 If Header ......................................................52 9.4 If Header ......................................................52
9.4.1 No-tag-list Production ......................................53 9.4.1 No-tag-list Production ......................................53
9.4.2 Tagged-list Production ......................................53 9.4.2 Tagged-list Production ......................................53
9.4.3 not Production ..............................................54 9.4.3 not Production ..............................................54
9.4.4 Matching Function ...........................................54 9.4.4 Matching Function ...........................................54
9.4.5 If Header and Non-DAV Compliant Proxies .....................55 9.4.5 If Header and Non-DAV Compliant Proxies .....................55
9.5 Lock-Token Header ..............................................55 9.5 Lock-Token Header ..............................................55
9.6 Overwrite Header ...............................................55 9.6 Overwrite Header ...............................................55
9.7 Status-URI Response Header .....................................55 9.7 Status-URI Response Header .....................................56
9.8 Timeout Request Header .........................................56 9.8 Timeout Request Header .........................................56
10 STATUS CODE EXTENSIONS TO HTTP/1.1 ..............................57 10 STATUS CODE EXTENSIONS TO HTTP/1.1 ..............................57
10.1 102 Processing .................................................57 10.1 102 Processing .................................................57
10.2 207 Multi-Status ...............................................57 10.2 207 Multi-Status ...............................................57
10.3 422 Unprocessable Entity .......................................57 10.3 422 Unprocessable Entity .......................................58
10.4 423 Locked .....................................................58 10.4 423 Locked .....................................................58
10.5 424 Failed Dependency ..........................................58 10.5 424 Failed Dependency ..........................................58
10.6 507 Insufficient Storage .......................................58 10.6 507 Insufficient Storage .......................................58
11 MULTI-STATUS RESPONSE ...........................................58 11 MULTI-STATUS RESPONSE ...........................................58
12 XML ELEMENT DEFINITIONS .........................................58 12 XML ELEMENT DEFINITIONS .........................................58
12.1 activelock XML Element .........................................58 12.1 activelock XML Element .........................................59
12.1.1 depth XML Element ...........................................59 12.1.1 depth XML Element ...........................................59
12.1.2 locktoken XML Element .......................................59 12.1.2 locktoken XML Element .......................................59
12.1.3 timeout XML Element .........................................59 12.1.3 timeout XML Element .........................................59
12.2 collection XML Element .........................................59 12.2 collection XML Element .........................................59
12.3 href XML Element ...............................................59 12.3 href XML Element ...............................................60
12.4 link XML Element ...............................................60 12.4 link XML Element ...............................................60
12.4.1 dst XML Element .............................................60 12.4.1 dst XML Element .............................................60
12.4.2 src XML Element .............................................60 12.4.2 src XML Element .............................................60
12.5 lockentry XML Element ..........................................60 12.5 lockentry XML Element ..........................................60
12.6 lockinfo XML Element ...........................................60 12.6 lockinfo XML Element ...........................................61
12.7 lockscope XML Element ..........................................61 12.7 lockscope XML Element ..........................................61
12.7.1 exclusive XML Element .......................................61 12.7.1 exclusive XML Element .......................................61
12.7.2 shared XML Element ..........................................61 12.7.2 shared XML Element ..........................................61
12.8 locktype XML Element ...........................................61 12.8 locktype XML Element ...........................................61
12.8.1 write XML Element ...........................................61 12.8.1 write XML Element ...........................................61
12.9 multistatus XML Element ........................................62 12.9 multistatus XML Element ........................................62
12.9.1 response XML Element ........................................62 12.9.1 response XML Element ........................................62
12.9.2 responsedescription XML Element .............................63 12.9.2 responsedescription XML Element .............................63
12.10owner XML Element ..............................................63 12.10 owner XML Element .............................................63
12.11prop XML element ...............................................63 12.11 prop XML element ..............................................63
12.12propertybehavior XML element ...................................63 12.12 propertybehavior XML element ..................................63
12.12.1 keepalive XML element ......................................64 12.12.1 keepalive XML element ......................................64
12.12.2 omit XML element ...........................................64 12.12.2 omit XML element ...........................................64
12.13propertyupdate XML element .....................................64 12.13 propertyupdate XML element ....................................64
12.13.1 remove XML element .........................................65 12.13.1 remove XML element .........................................65
12.13.2 set XML element ............................................65 12.13.2 set XML element ............................................65
12.14propfind XML Element ...........................................65 12.14 propfind XML Element ..........................................65
12.14.1 allprop XML Element ........................................65 12.14.1 allprop XML Element ........................................65
12.14.2 propname XML Element .......................................66 12.14.2 propname XML Element .......................................66
13 DAV PROPERTIES ..................................................66 13 DAV PROPERTIES ..................................................66
13.1 creationdate Property ..........................................66 13.1 creationdate Property ..........................................66
13.2 displayname Property ...........................................66 13.2 displayname Property ...........................................66
13.3 getcontentlanguage Property ....................................67 13.3 getcontentlanguage Property ....................................67
13.4 getcontentlength Property ......................................67 13.4 getcontentlength Property ......................................67
13.5 getcontenttype Property ........................................67 13.5 getcontenttype Property ........................................67
13.6 getetag Property ...............................................67 13.6 getetag Property ...............................................67
13.7 getlastmodified Property .......................................68 13.7 getlastmodified Property .......................................68
13.8 lockdiscovery Property .........................................68 13.8 lockdiscovery Property .........................................68
13.8.1 Example - Retrieving the lockdiscovery Property .............68 13.8.1 Example - Retrieving the lockdiscovery Property .............68
13.9 resourcetype Property ..........................................69 13.9 resourcetype Property ..........................................69
13.10source Property ................................................70 13.10 source Property ...............................................70
13.10.1 Example - A source Property ................................70 13.10.1 Example - A source Property ................................70
13.11supportedlock Property .........................................71 13.11 supportedlock Property ........................................71
13.11.1 Example - Retrieving the supportedlock Property ............71 13.11.1 Example - Retrieving the supportedlock Property ............71
14 INSTRUCTIONS FOR PROCESSING XML IN DAV ..........................72 14 INSTRUCTIONS FOR PROCESSING XML IN DAV ..........................72
15 DAV COMPLIANCE CLASSES ..........................................73 15 DAV COMPLIANCE CLASSES ..........................................73
15.1 Class 1 ........................................................73 15.1 Class 1 ........................................................73
15.2 Class 2 ........................................................73 15.2 Class 2 ........................................................73
16 INTERNATIONALIZATION CONSIDERATIONS .............................73 16 INTERNATIONALIZATION CONSIDERATIONS .............................73
skipping to change at page 8, line 48 skipping to change at page 8, line 48
[RFC2068]. Since this augmented BNF uses the basic production rules [RFC2068]. Since this augmented BNF uses the basic production rules
provided in section 2.2 of [RFC2068], these rules apply to this provided in section 2.2 of [RFC2068], these rules apply to this
document as well. document as well.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3 Terminology 3 Terminology
URI/URL - As defined in [RFC2396]. URI/URL - A Uniform Resource Identifier and Uniform Resource
Locator, respectively. These terms (and the distinction between
them) are defined in [RFC2396].
Collection - A resource that contains member resources and meets the Collection - A resource that contains a set of URIs, termed member
requirements in section 5 of this specification. URIs, which identify member resources and meets the requirements in
section 5 of this specification.
Member Resource - A resource contained by a collection. Member URI - A URI which is a member of the set of URIs contained by
a collection.
Internal Member Resource - A member resource of a collection whose Internal Member URI - A Member URI that is immediately relative to
URI is immediately relative to the URI of the collection. the URI of the collection (the definition of immediately relative is
given in section 5.2).
Property - A name/value pair that contains descriptive information Property - A name/value pair that contains descriptive information
about a resource. about a resource.
Live Property - A property whose semantics and syntax are enforced Live Property - A property whose semantics and syntax are enforced
by the server. For example, the live "getcontentlength" property by the server. For example, the live "getcontentlength" property
has its value, the length of the entity returned by a GET request, has its value, the length of the entity returned by a GET request,
automatically calculated by the server. automatically calculated by the server.
Dead Property - A property whose semantics and syntax are not Dead Property - A property whose semantics and syntax are not
skipping to change at page 10, line 12 skipping to change at page 10, line 16
property has its syntax and semantics enforced by the client; the property has its syntax and semantics enforced by the client; the
server merely records the value of the property verbatim. server merely records the value of the property verbatim.
4.2 Existing Metadata Proposals 4.2 Existing Metadata Proposals
Properties have long played an essential role in the maintenance of Properties have long played an essential role in the maintenance of
large document repositories, and many current proposals contain some large document repositories, and many current proposals contain some
notion of a property, or discuss web metadata more generally. These notion of a property, or discuss web metadata more generally. These
include PICS [REC-PICS], PICS-NG, XML, Web Collections, and several include PICS [REC-PICS], PICS-NG, XML, Web Collections, and several
proposals on representing relationships within HTML. Work on PICS-NG proposals on representing relationships within HTML. Work on PICS-NG
and Web Collections has been subsumed by the Resource Definition and Web Collections has been subsumed by the Resource Description
Framework (RDF) metadata activity of the World Wide Web Consortium. Framework (RDF) metadata activity of the World Wide Web Consortium.
RDF consists of a network-based data model and an XML representation RDF consists of a network-based data model and an XML representation
of that model. of that model.
Some proposals come from a digital library perspective. These Some proposals come from a digital library perspective. These
include the Dublin Core [RFC2413] metadata set and the Warwick include the Dublin Core [RFC2413] metadata set and the Warwick
Framework [Lagoze, 1996], a container architecture for different Framework [WF], a container architecture for different metadata
metadata schemas. The literature includes many examples of schemas. The literature includes many examples of metadata,
metadata, including MARC [USMARC], a bibliographic metadata format, including MARC [USMARC], a bibliographic metadata format, and a
and a technical report bibliographic format employed by the Dienst technical report bibliographic format employed by the Dienst system
system [RFC1807]. Additionally, the proceedings from the first IEEE [RFC1807]. Additionally, the proceedings from the first IEEE
Metadata conference describe many community-specific metadata sets. Metadata conference describe many community-specific metadata sets.
Participants of the 1996 Metadata II Workshop in Warwick, UK Participants of the 1996 Metadata II Workshop in Warwick, UK [WF],
[Lagoze, 1996], noted that "new metadata sets will develop as the noted that "new metadata sets will develop as the networked
networked infrastructure matures" and "different communities will infrastructure matures" and "different communities will propose,
propose, design, and be responsible for different types of design, and be responsible for different types of metadata." These
metadata." These observations can be corroborated by noting that observations can be corroborated by noting that many community-
many community-specific sets of metadata already exist, and there is specific sets of metadata already exist, and there is significant
significant motivation for the development of new forms of metadata motivation for the development of new forms of metadata as many
as many communities increasingly make their data available in communities increasingly make their data available in digital form,
digital form, requiring a metadata format to assist data location requiring a metadata format to assist data location and cataloging.
and cataloging.
4.3 Properties and HTTP Headers 4.3 Properties and HTTP Headers
Properties already exist, in a limited sense, in HTTP message Properties already exist, in a limited sense, in HTTP message
headers. However, in distributed authoring environments a headers. However, in distributed authoring environments a
relatively large number of properties are needed to describe the relatively large number of properties are needed to describe the
state of a resource, and setting/returning them all through HTTP state of a resource, and setting/returning them all through HTTP
headers is inefficient. Thus a mechanism is needed which allows a headers is inefficient. Thus a mechanism is needed which allows a
principal to identify a set of properties in which the principal is principal to identify a set of properties in which the principal is
interested and to set or retrieve just those properties. interested and to set or retrieve just those properties.
skipping to change at page 11, line 43 skipping to change at page 11, line 46
relating to hierarchical properties. relating to hierarchical properties.
Finally, it is not possible to define the same property twice on a Finally, it is not possible to define the same property twice on a
single resource, as this would cause a collision in the resource's single resource, as this would cause a collision in the resource's
property namespace. property namespace.
4.6 Media Independent Links 4.6 Media Independent Links
Although HTML resources support links to other resources, the Web Although HTML resources support links to other resources, the Web
needs more general support for links between resources of any media needs more general support for links between resources of any media
type. WebDAV provides such links. A WebDAV link is a special type type (media types are also known as MIME types, or content types).
of property value, formally defined in section 12.4, that allows WebDAV provides such links. A WebDAV link is a special type of
typed connections to be established between resources of any media property value, formally defined in section 12.4, that allows typed
type. The property value consists of source and destination Uniform connections to be established between resources of any media type.
Resource Locators (URLs); the property name identifies the link The property value consists of source and destination Uniform
Resource Identifiers (URIs); the property name identifies the link
type. type.
5 Collections of Web Resources 5 Collections of Web Resources
This section provides a description of a new type of Web resource, This section provides a description of a new type of Web resource,
the collection, and discusses its interactions with the HTTP URL the collection, and discusses its interactions with the HTTP URL
namespace. The purpose of a collection resource is to model namespace. The purpose of a collection resource is to model
collection-like objects (e.g., file system directories) within a collection-like objects (e.g., file system directories) within a
server's namespace. server's namespace.
All DAV compliant resources MUST support the HTTP URL namespace All DAV compliant resources MUST support the HTTP URL namespace
model specified herein. model specified herein.
5.1 HTTP URL Namespace Model 5.1 HTTP URL Namespace Model
The HTTP URL namespace is a hierarchical namespace where the The HTTP URL namespace is a hierarchical namespace where the
hierarchy is delimited with the "/" character. hierarchy is delimited with the "/" character.
An HTTP URL namespace is said to be consistent if it meets the An HTTP URL namespace is said to be consistent if it meets the
following rule: for every non-null resource A, there exists a non- following conditions: for every URL in the HTTP hierarchy there
null resource B that is a collection and has resource A as an exists a collection that contains that URL as an internal member.
internal member. The root of the namespace is exempt from the The root, or top-level collection of the namespace under
previous rule. consideration is exempt from the previous rule.
Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL
namespace be consistent. However, certain WebDAV methods are namespace be consistent. However, certain WebDAV methods are
prohibited from producing results that cause namespace prohibited from producing results that cause namespace
inconsistencies. inconsistencies.
Although implicit in [RFC2068] and [RFC2396], any resource,
including collection resources, MAY be identified by more than one
URI. For example, a resource could be identified by multiple HTTP
URLs.
5.2 Collection Resources 5.2 Collection Resources
A collection is a resource whose state consists of at least a list A collection is a resource whose state consists of at least a list
of internal members and a set of properties, but which may have of internal member URIs and a set of properties, but which may have
additional state such as entity bodies returned by GET. An internal additional state such as entity bodies returned by GET. An internal
member resource MUST have a URI that is immediately relative to the member URI MUST be immediately relative to a base URI of the
base URI of the collection. That is, the internal member's URI is collection. That is, the internal member URI is equal to a
equal to the parent collection's URI plus an additional segment containing collection's URI plus an additional segment for non-
where segment is defined in section 3.2.1 of RFC 2068 [Fielding et collection resources, or additional segment plus trailing slash "/"
al., 1996]. for collection resources, where segment is defined in section 3.3 of
[RFC2396].
Any given internal member MUST only belong to the collection once, Any given internal member URI MUST only belong to the collection
i.e., it is illegal to have multiple instances of the same URI in a once, i.e., it is illegal to have multiple instances of the same URI
collection. Properties defined on collections behave exactly as do in a collection. Properties defined on collections behave exactly
properties on non-collection resources. as do properties on non-collection resources.
For all WebDAV compliant resources A and B for which B is the parent For all WebDAV compliant resources A and B, identified by URIs U and
of A in the HTTP URL namespace hierarchy, B MUST be a collection V, for which U is immediately relative to V, B MUST be a collection
which has A as an internal member. So, if http://foo.com/bar/blah is that has U as an internal member URI. So, if the resource with URL
WebDAV compliant and if http://foo.com/bar/ is WebDAV compliant then http://foo.com/bar/blah is WebDAV compliant and if the resource with
http://foo.com/bar/ must be a collection and must contain URL http://foo.com/bar/ is WebDAV compliant then the resource with
URL http://foo.com/bar/ must be a collection and must contain URL
http://foo.com/bar/blah as an internal member. http://foo.com/bar/blah as an internal member.
Collection resources MAY list their non-WebDAV compliant children in Collection resources MAY list the URLs ofnon-WebDAV compliant
the HTTP URL namespace hierarchy as internal members but are not children in the HTTP URL namespace hierarchy as internal members but
required to do so. For example, if http://foo.com/bar/blah is not are not required to do so. For example, if the resource with URL
WebDAV compliant and http://foo.com/bar/ is a collection then http://foo.com/bar/blah is not WebDAV compliant and the URL
http://foo.com/bar/blah may or may not be listed as an internal http://foo.com/bar/ identifies a collection then URL
member of http://foo.com/bar/. http://foo.com/bar/blah may or may not be an internal member of the
collection with URL http://foo.com/bar/.
If a WebDAV compliant resource has no WebDAV compliant children in If a WebDAV compliant resource has no WebDAV compliant children in
the HTTP URL namespace hierarchy then the WebDAV compliant resource the HTTP URL namespace hierarchy then the WebDAV compliant resource
is not required to be a collection. is not required to be a collection.
There is a standing convention that when a collection is referred to There is a standing convention that when a collection is referred to
by its name without a trailing slash, the trailing slash is by its name without a trailing slash, the trailing slash is
automatically appended. Due to this, a resource may accept a URI automatically appended. Due to this, a resource may accept a URI
without a trailing "/" to point to a collection. In this case it without a trailing "/" to point to a collection. In this case it
SHOULD return a content-location header in the response pointing to SHOULD return a content-location header in the response pointing to
the URL ending with the "/". For example, if a client invokes a the URI ending with the "/". For example, if a client invokes a
method on http://foo.bar/blah (no trailing slash), the resource method on http://foo.bar/blah (no trailing slash), the resource
http://foo.bar/blah/ (trailing slash) may respond as if the http://foo.bar/blah/ (trailing slash) may respond as if the
operation were invoked on it, and should return a content-location operation were invoked on it, and should return a content-location
header with http://foo.bar/blah/ in it. In general clients SHOULD header with http://foo.bar/blah/ in it. In general clients SHOULD
use the "/" form of collection names. use the "/" form of collection names.
A resource MAY be a collection but not be WebDAV compliant. That A resource MAY be a collection but not be WebDAV compliant. That
is, the resource may comply with all the rules set out in this is, the resource may comply with all the rules set out in this
specification regarding how a collection is to behave without specification regarding how a collection is to behave without
necessarily supporting all methods that a WebDAV compliant resource necessarily supporting all methods that a WebDAV compliant resource
is required to support. In such a case the resource may return the is required to support. In such a case the resource may return the
dav:resourcetype property with the value dav:collection but MUST NOT DAV:resourcetype property with the value DAV:collection but MUST NOT
return a DAV header containing the value "1" on an OPTIONS response. return a DAV header containing the value "1" on an OPTIONS response.
5.3 Creation and Retrieval of Collection Resources 5.3 Creation and Retrieval of Collection Resources
This document specifies the MKCOL method to create new collection This document specifies the MKCOL method to create new collection
resources, rather than using the existing HTTP/1.1 PUT or POST resources, rather than using the existing HTTP/1.1 PUT or POST
method, for the following reasons: method, for the following reasons:
In HTTP/1.1, the PUT method is defined to store the request body at In HTTP/1.1, the PUT method is defined to store the request body at
the location specified by the Request-URI. While a description the location specified by the Request-URI. While a description
skipping to change at page 14, line 9 skipping to change at page 14, line 19
because it would be difficult to separate access control for because it would be difficult to separate access control for
collection creation from other uses of POST. collection creation from other uses of POST.
The exact definition of the behavior of GET and PUT on collections The exact definition of the behavior of GET and PUT on collections
is defined later in this document. is defined later in this document.
5.4 Source Resources and Output Resources 5.4 Source Resources and Output Resources
For many resources, the entity returned by a GET method exactly For many resources, the entity returned by a GET method exactly
matches the persistent state of the resource, for example, a GIF 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 file stored on a disk. For this simple case, the URI at which a
resource is accessed is identical to the URL at which the source resource is accessed is identical to the URI at which the source
(the persistent state) of the resource is accessed. This is also (the persistent state) of the resource is accessed. This is also
the case for HTML source files that are not processed by the server the case for HTML source files that are not processed by the server
prior to transmission. prior to transmission.
However, the server can sometimes process HTML resources before they However, the server can sometimes process HTML resources before they
are transmitted as a return entity body. For example, a server- are transmitted as a return entity body. For example, a server-
side-include directive within an HTML file might instruct a server side-include directive within an HTML file might instruct a server
to replace the directive with another value, such as the current to replace the directive with another value, such as the current
date. In this case, what is returned by GET (HTML plus date) date. In this case, what is returned by GET (HTML plus date)
differs from the persistent state of the resource (HTML plus differs from the persistent state of the resource (HTML plus
directive). Typically there is no way to access the HTML resource directive). Typically there is no way to access the HTML resource
containing the unprocessed directive. containing the unprocessed directive.
Sometimes the entity returned by GET is the output of a data- Sometimes the entity returned by GET is the output of a data-
producing process that is described by one or more source resources producing process that is described by one or more source resources
(that may not even have a location in the URL namespace). A single (that may not even have a location in the URI namespace). A single
data-producing process may dynamically generate the state of a data-producing process may dynamically generate the state of a
potentially large number of output resources. An example of this is potentially large number of output resources. An example of this is
a CGI script that describes a "finger" gateway process that maps a CGI script that describes a "finger" gateway process that maps
part of the namespace of a server into finger requests, such as part of the namespace of a server into finger requests, such as
http://www.foo.bar.org/finger_gateway/user@host. http://www.foo.bar.org/finger_gateway/user@host.
In the absence of distributed authoring capabilities, it is In the absence of distributed authoring capabilities, it is
acceptable to have no mapping of source resource(s) to the URI acceptable to have no mapping of source resource(s) to the URI
namespace. In fact, preventing access to the source resource(s) has namespace. In fact, preventing access to the source resource(s) has
desirable security benefits. However, if remote editing of the desirable security benefits. However, if remote editing of the
skipping to change at page 17, line 20 skipping to change at page 17, line 31
The opaquelocktoken URI scheme is designed to be unique across all The opaquelocktoken URI scheme is designed to be unique across all
resources for all time. Due to this uniqueness quality, a client resources for all time. Due to this uniqueness quality, a client
may submit an opaque lock token in an If header on a resource other may submit an opaque lock token in an If header on a resource other
than the one that returned it. than the one that returned it.
All resources MUST recognize the opaquelocktoken scheme and, at All resources MUST recognize the opaquelocktoken scheme and, at
minimum, recognize that the lock token does not refer to an minimum, recognize that the lock token does not refer to an
outstanding lock on the resource. outstanding lock on the resource.
In order to guarantee uniqueness across all resources for all time In order to guarantee uniqueness across all resources for all time
the opaquelocktoken requires the use of the globally unique the opaquelocktoken requires the use of the Universal Unique
identifier (GUID) mechanism, as described in [ISO-11578]. Identifier (UUID) mechanism, as described in [ISO-11578].
Opaquelocktoken generators, however, have a choice of how they Opaquelocktoken generators, however, have a choice of how they
create these tokens. They can either generate a new GUID for every create these tokens. They can either generate a new UUID for every
lock token they create or they can create a single GUID and then lock token they create or they can create a single UUID and then
add extension characters. If the second method is selected then the add extension characters. If the second method is selected then the
program generating the extensions MUST guarantee that the same program generating the extensions MUST guarantee that the same
extension will never be used twice with the associated GUID. extension will never be used twice with the associated UUID.
OpaqueLockToken-URI = "opaquelocktoken:" GUID [Extension] ; The OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The
GUID production is the string representation of a GUID, as defined UUID production is the string representation of a UUID, as defined
in [ISO-11578]. Note that white space (LWS) is not allowed between in [ISO-11578]. Note that white space (LWS) is not allowed between
elements of this production. elements of this production.
Extension = path ; path is defined in section 3.2.1 of RFC 2068 Extension = path ; path is defined in section 3.2.1 of RFC 2068
[Fielding et al., 1996] [RFC2068]
6.4.1 Node Field Generation Without the IEEE 802 Address 6.4.1 Node Field Generation Without the IEEE 802 Address
GUIDs, as defined in [ISO-11578], contain a "node" field which UUIDs, as defined in [ISO-11578], contain a "node" field that
contains one of the IEEE 802 addresses for the server machine. As contains one of the IEEE 802 addresses for the server machine. As
noted in section 17.8, there are several security risks associated noted in section 17.8, there are several security risks associated
with exposing a machine's IEEE 802 address. This section provides an with exposing a machine's IEEE 802 address. This section provides an
alternate mechanism for generating the "node" field of a GUID which alternate mechanism for generating the "node" field of a UUID which
does not employ an IEEE 802 address. WebDAV servers MAY use this does not employ an IEEE 802 address. WebDAV servers MAY use this
algorithm for creating the node field when generating GUIDs. The algorithm for creating the node field when generating UUIDs. The
text in this section is quoted from section 4 of draft-leach-uuids- text in this section isoriginally from an Internet-Draft by Paul
guids-01 (expired). Leach and Rich Salz, who are noted here to properly attribute their
work.
The ideal solution is to obtain a 47 bit cryptographic quality The ideal solution is to obtain a 47 bit cryptographic quality
random number, and use it as the low 47 bits of the node ID, with random number, and use it as the low 47 bits of the node ID, with
the most significant bit of the first octet of the node ID set to 1. the most significant bit of the first octet of the node ID set to 1.
This bit is the unicast/multicast bit, which will never be set in This bit is the unicast/multicast bit, which will never be set in
IEEE 802 addresses obtained from network cards; hence, there can IEEE 802 addresses obtained from network cards; hence, there can
never be a conflict between GUIDs generated by machines with and never be a conflict between UUIDs generated by machines with and
without network cards. without network cards.
If a system does not have a primitive to generate cryptographic If a system does not have a primitive to generate cryptographic
quality random numbers, then in most systems there are usually a quality random numbers, then in most systems there are usually a
fairly large number of sources of randomness available from which fairly large number of sources of randomness available from which
one can be generated. Such sources are system specific, but often one can be generated. Such sources are system specific, but often
include: include:
- the percent of memory in use - the percent of memory in use
- the size of main memory in bytes - the size of main memory in bytes
skipping to change at page 21, line 37 skipping to change at page 21, line 50
resource the resource ceases to be in the lock-null state. resource the resource ceases to be in the lock-null state.
If the resource is unlocked, for any reason, without a PUT, MKCOL, If the resource is unlocked, for any reason, without a PUT, MKCOL,
or similar method having been successfully executed upon it then the or similar method having been successfully executed upon it then the
resource MUST return to the null state. resource MUST return to the null state.
7.5 Write Locks and Collections 7.5 Write Locks and Collections
A write lock on a collection, whether created by a "Depth: 0" or A write lock on a collection, whether created by a "Depth: 0" or
"Depth: infinity" lock request, prevents the addition or removal of "Depth: infinity" lock request, prevents the addition or removal of
members of the collection by non-lock owners. As a consequence, member URIs of the collection by non-lock owners. As a consequence,
when a principal issues a request to create a new internal member of when a principal issues a PUT or POST request to create a new
a write locked collection using PUT or POST, or to remove an resource under a URI which needs to be an internal member of a write
existing internal member of a write locked collection using DELETE, locked collection to maintain HTTP namespace consistency, or issues
this request MUST fail if the principal does not have a write lock a DELETE to remove a resource which has a URI which is an existing
on the collection. internal member URI of a write locked collection, this request MUST
fail if the principal does not have a write lock on the collection.
However, if a write lock request is issued to a collection However, if a write lock request is issued to a collection
containing internal member resources that are currently locked in a containing member URIs identifying resources that are currently
manner which conflicts with the write lock, the request MUST fail locked in a manner which conflicts with the write lock, the request
with a 423 (Locked) status code. MUST fail with a 423 (Locked) status code.
If a lock owner causes a resource to be added as an internal member If a lock owner causes the URI of a resource to be added as an
of a locked collection then the new resource MUST be automatically internal member URI of a locked collection then the new resource
added to the lock. This is the only mechanism that allows a MUST be automatically added to the lock. This is the only mechanism
resource to be added to a write lock. Thus, for example, if the that allows a resource to be added to a write lock. Thus, for
collection /a/b/ is write locked and the resource /c is moved to example, if the collection /a/b/ is write locked and the resource /c
/a/b/c then /a/b/c will be added to the write lock. is moved to /a/b/c then resource /a/b/c will be added to the write
lock.
7.6 Write Locks and the If Request Header 7.6 Write Locks and the If Request Header
If a user agent is not required to have knowledge about a lock when If a user agent is not required to have knowledge about a lock when
requesting an operation on a locked resource, the following scenario requesting an operation on a locked resource, the following scenario
might occur. Program A, run by User A, takes out a write lock on a might occur. Program A, run by User A, takes out a write lock on a
resource. Program B, also run by User A, has no knowledge of the resource. Program B, also run by User A, has no knowledge of the
lock taken out by Program A, yet performs a PUT to the locked lock taken out by Program A, yet performs a PUT to the locked
resource. In this scenario, the PUT succeeds because locks are resource. In this scenario, the PUT succeeds because locks are
associated with a principal, not a program, and thus program B, associated with a principal, not a program, and thus program B,
skipping to change at page 24, line 7 skipping to change at page 24, line 19
parsers that are compliant with [REC-XML]. All XML used in either parsers that are compliant with [REC-XML]. All XML used in either
requests or responses MUST be, at minimum, well formed. If a server requests or responses MUST be, at minimum, well formed. If a server
receives ill-formed XML in a request it MUST reject the entire receives ill-formed XML in a request it MUST reject the entire
request with a 400 (Bad Request). If a client receives ill-formed request with a 400 (Bad Request). If a client receives ill-formed
XML in a response then it MUST NOT assume anything about the outcome XML in a response then it MUST NOT assume anything about the outcome
of the executed method and SHOULD treat the server as of the executed method and SHOULD treat the server as
malfunctioning. malfunctioning.
8.1 PROPFIND 8.1 PROPFIND
The PROPFIND method retrieves properties defined on the Request-URI, The PROPFIND method retrieves properties defined on the resource
if the resource does not have any internal members, or on the identified by the Request-URI, if the resource does not have any
Request-URI and potentially its member resources, if the resource internal members, or on the resource identified by the Request-URI
does have internal members. All DAV compliant resources MUST and potentially its member resources, if the resource is a
support the PROPFIND method and the propfind XML element (section collection that has internal member URIs. All DAV compliant
12.14) along with all XML elements defined for use with that resources MUST support the PROPFIND method and the propfind XML
element. element (section 12.14) along with all XML elements defined for use
with that element.
A client may submit a Depth header with a value of "0", "1", or A client may submit a Depth header with a value of "0", "1", or
"infinity" with a PROPFIND on a resource with internal members. DAV "infinity" with a PROPFIND on a collection resource with internal
compliant servers MUST support the "0", "1" and "infinity" member URIs. DAV compliant servers MUST support the "0", "1" and
behaviors. By default, the PROPFIND method without a Depth header "infinity" behaviors. By default, the PROPFIND method without a
MUST act as if a "Depth: infinity" header was included. Depth header MUST act as if a "Depth: infinity" header was included.
A client may submit a propfind XML element in the body of the A client may submit a propfind XML element in the body of the
request method describing what information is being requested. It request method describing what information is being requested. It
is possible to request particular property values, all property is possible to request particular property values, all property
values, or a list of the names of the resource's properties. A values, or a list of the names of the resource's properties. A
client may choose not to submit a request body. An empty PROPFIND client may choose not to submit a request body. An empty PROPFIND
request body MUST be treated as a request for the names and values request body MUST be treated as a request for the names and values
of all properties. of all properties.
All servers MUST support returning a response of content type All servers MUST support returning a response of content type
text/xml or application/xml that contains a multistatus XML element text/xml or application/xml that contains a multistatus XML element
that describes the results of the attempts to retrieve the various that describes the results of the attempts to retrieve the various
properties. properties.
If there is an error retrieving a property then a proper error If there is an error retrieving a property then a proper error
result MUST be included in the response. A request to retrieve the result MUST be included in the response. A request to retrieve the
value of a property which does not exist is an error and MUST be value of a property which does not exist is an error and MUST be
noted, if the response uses a multistatus XML element, with a noted, if the response uses a multistatus XML element, with a
response XML element which contains a 404 (Not Found) status value. response XML element which contains a 404 (Not Found) status value.
Consequently, the multistatus XML element for a resource with Consequently, the multistatus XML element for a collection resource
members MUST include a response XML element for each member of the with member URIs MUST include a response XML element for each member
resource, to whatever depth was requested. Each response XML element URI of the collection, to whatever depth was requested. Each
MUST contain an href XML element that identifies the resource on response XML element MUST contain an href XML element that gives the
which the properties in the prop XML element are defined. Results URI of the resource on which the properties in the prop XML element
for a PROPFIND on a resource with internal members are returned as a are defined. Results for a PROPFIND on a collection resource with
flat list whose order of entries is not significant. internal member URIs are returned as a flat list whose order of
entries is not significant.
In the case of allprop and propname, if a principal does not have In the case of allprop and propname, if a principal does not have
the right to know whether a particular property exists then the the right to know whether a particular property exists then the
property should be silently excluded from the response. property should be silently excluded from the response.
The results of this method SHOULD NOT be cached. The results of this method SHOULD NOT be cached.
8.1.1 Example - Retrieving Named Properties 8.1.1 Example - Retrieving Named Properties
>>Request >>Request
PROPFIND /file HTTP/1.1 PROPFIND /file HTTP/1.1
Host: www.foo.bar Host: www.foo.bar
Content-type: text/xml; charset="utf-8" Content-type: text/xml; charset="utf-8"
Content-Length: xyz Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"> <D:propfind xmlns:D="DAV:">
<D:prop xmlns:R="http://www.foo.bar/boxschema/"> <D:prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox/> <R:bigbox/>
<R:author/> <R:author/>
<R:DingALing/> <R:DingALing/>
<R:Random/> <R:Random/>
</D:prop> </D:prop>
</D:propfind> </D:propfind>
>>Response >>Response
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"> <D:multistatus xmlns:D="DAV:">
<D:response> <D:response>
<D:href>http://www.foo.bar/file</D:href> <D:href>http://www.foo.bar/file</D:href>
<D:propstat> <D:propstat>
<D:prop xmlns:R="http://www.foo.bar/boxschema/"> <D:prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox> <R:bigbox>
<R:BoxType>Box type A</R:BoxType> <R:BoxType>Box type A</R:BoxType>
</R:bigbox> </R:bigbox>
skipping to change at page 26, line 19 skipping to change at page 26, line 30
and fourth properties. and fourth properties.
8.1.2 Example - Using allprop to Retrieve All Properties 8.1.2 Example - Using allprop to Retrieve All Properties
>>Request >>Request
PROPFIND /container/ HTTP/1.1 PROPFIND /container/ HTTP/1.1
Host: www.foo.bar Host: www.foo.bar
Depth: 1 Depth: 1
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"> <D:propfind xmlns:D="DAV:">
<D:allprop/> <D:allprop/>
</D:propfind> </D:propfind>
>>Response >>Response
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"> <D:multistatus xmlns:D="DAV:">
<D:response> <D:response>
<D:href>http://www.foo.bar/container/</D:href> <D:href>http://www.foo.bar/container/</D:href>
<D:propstat> <D:propstat>
<D:prop xmlns:R="http://www.foo.bar/boxschema/"> <D:prop xmlns:R="http://www.foo.bar/boxschema/">
<R:bigbox> <R:bigbox>
<R:BoxType>Box type A</R:BoxType> <R:BoxType>Box type A</R:BoxType>
</R:bigbox> </R:bigbox>
skipping to change at page 29, line 12 skipping to change at page 29, line 12
not a collection (resourcetype), and supports both exclusive write not a collection (resourcetype), and supports both exclusive write
and shared write locks (supportedlock). and shared write locks (supportedlock).
8.1.3 Example - Using propname to Retrieve all Property Names 8.1.3 Example - Using propname to Retrieve all Property Names
>>Request >>Request
PROPFIND /container/ HTTP/1.1 PROPFIND /container/ HTTP/1.1
Host: www.foo.bar Host: www.foo.bar
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<propfind xmlns="DAV:"> <propfind xmlns="DAV:">
<propname/> <propname/>
</propfind> </propfind>
>>Response >>Response
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
skipping to change at page 31, line 53 skipping to change at page 32, line 4
<Z:authors> <Z:authors>
<Z:Author>Jim Whitehead</Z:Author> <Z:Author>Jim Whitehead</Z:Author>
<Z:Author>Roy Fielding</Z:Author> <Z:Author>Roy Fielding</Z:Author>
</Z:authors> </Z:authors>
</D:prop> </D:prop>
</D:set> </D:set>
<D:remove> <D:remove>
<D:prop><Z:Copyright-Owner/></D:prop> <D:prop><Z:Copyright-Owner/></D:prop>
</D:remove> </D:remove>
</D:propertyupdate> </D:propertyupdate>
>>Response >>Response
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:" <D:multistatus xmlns:D="DAV:"
xmlns:Z="http://www.w3.com/standards/z39.50"> xmlns:Z="http://www.w3.com/standards/z39.50">
<D:response> <D:response>
<D:href>http://www.foo.com/bar.html</D:href> <D:href>http://www.foo.com/bar.html</D:href>
<D:propstat> <D:propstat>
<D:prop><Z:Authors/></D:prop> <D:prop><Z:Authors/></D:prop>
<D:status>HTTP/1.1 424 Failed Dependency</D:status> <D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:propstat> </D:propstat>
skipping to change at page 34, line 32 skipping to change at page 34, line 32
Since by definition the actual function performed by POST is Since by definition the actual function performed by POST is
determined by the server and often depends on the particular determined by the server and often depends on the particular
resource, the behavior of POST when applied to collections cannot be resource, the behavior of POST when applied to collections cannot be
meaningfully modified because it is largely undefined. Thus the meaningfully modified because it is largely undefined. Thus the
semantics of POST are unmodified when applied to a collection. semantics of POST are unmodified when applied to a collection.
8.6 DELETE 8.6 DELETE
8.6.1 DELETE for Non-Collection Resources 8.6.1 DELETE for Non-Collection Resources
If the DELETE method is issued to a non-collection resource which is If the DELETE method is issued to a non-collection resource whose
an internal member of a collection, then during DELETE processing a URIs are an internal member of one or more collections, then during
server MUST remove the Request-URI from its parent collection. DELETE processing a server MUST remove any URI for the resource
identified by the Request-URI from collections which contain it as a
member.
8.6.2 DELETE for Collections 8.6.2 DELETE for Collections
The DELETE method on a collection MUST act as if a "Depth: infinity" The DELETE method on a collection MUST act as if a "Depth: infinity"
header was used on it. A client MUST NOT submit a Depth header with header was used on it. A client MUST NOT submit a Depth header with
a DELETE on a collection with any value but infinity. a DELETE on a collection with any value but infinity.
DELETE instructs that the collection specified in the Request-URI DELETE instructs that the collection specified in the Request-URI
and all its internal member resources are to be deleted. and all resources identified by its internal member URIs are to be
deleted.
If any member cannot be deleted then all of the member's ancestors If any resource identified by a member URI cannot be deleted then
MUST NOT be deleted, so as to maintain the namespace. all of the member's ancestors MUST NOT be deleted, so as to maintain
namespace consistency.
Any headers included with DELETE MUST be applied in processing every Any headers included with DELETE MUST be applied in processing every
resource to be deleted. resource to be deleted.
When the DELETE method has completed processing it MUST return a When the DELETE method has completed processing it MUST result in a
consistent namespace. consistent namespace.
If an error occurs with a resource other than the resource If an error occurs with a resource other than the resource
identified in the Request-URI then the response MUST be a 207 identified in the Request-URI then the response MUST be a 207
(Multi-Status). 424 (Failed Dependency) errors SHOULD NOT be in the (Multi-Status). 424 (Failed Dependency) errors SHOULD NOT be in the
207 (Multi-Status). They can be safely left out because the client 207 (Multi-Status). They can be safely left out because the client
will know that the ancestors of a resource could not be deleted when will know that the ancestors of a resource could not be deleted when
the client receives an error for the ancestor's progeny. the client receives an error for the ancestor's progeny.
Additionally 204 (No Content) errors SHOULD NOT be returned in the Additionally 204 (No Content) errors SHOULD NOT be returned in the
207 (Multi-Status). The reason for this prohibition is that 204 (No 207 (Multi-Status). The reason for this prohibition is that 204 (No
skipping to change at page 35, line 20 skipping to change at page 35, line 29
>>Request >>Request
DELETE /container/ HTTP/1.1 DELETE /container/ HTTP/1.1
Host: www.foo.bar Host: www.foo.bar
>>Response >>Response
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:"> <d:multistatus xmlns:d="DAV:">
<d:response> <d:response>
<d:href>http://www.foo.bar/container/resource3</d:href> <d:href>http://www.foo.bar/container/resource3</d:href>
<d:status>HTTP/1.1 423 Locked</d:status> <d:status>HTTP/1.1 423 Locked</d:status>
</d:response> </d:response>
</d:multistatus> </d:multistatus>
In this example the attempt to delete In this example the attempt to delete
skipping to change at page 36, line 23 skipping to change at page 36, line 29
the MKCOL method is defined to create collections. the MKCOL method is defined to create collections.
When the PUT operation creates a new non-collection resource all When the PUT operation creates a new non-collection resource all
ancestors MUST already exist. If all ancestors do not exist, the ancestors MUST already exist. If all ancestors do not exist, the
method MUST fail with a 409 (Conflict) status code. For example, if method MUST fail with a 409 (Conflict) status code. For example, if
resource /a/b/c/d.html is to be created and /a/b/c/ does not exist, resource /a/b/c/d.html is to be created and /a/b/c/ does not exist,
then the request must fail. then the request must fail.
8.8 COPY Method 8.8 COPY Method
The COPY method creates a duplicate of the source resource, given by The COPY method creates a duplicate of the source resource,
the Request-URI, in the destination resource, given by the identified by the Request-URI, in the destination resource,
Destination header. The Destination header MUST be present. The identified by the URI in the Destination header. The Destination
exact behavior of the COPY method depends on the type of the source header MUST be present. The exact behavior of the COPY method
resource. depends on the type of the source resource.
All WebDAV compliant resources MUST support the COPY method. All WebDAV compliant resources MUST support the COPY method.
However, support for the COPY method does not guarantee the ability However, support for the COPY method does not guarantee the ability
to copy a resource. For example, separate programs may control to copy a resource. For example, separate programs may control
resources on the same server. As a result, it may not be possible resources on the same server. As a result, it may not be possible
to copy a resource to a location that appears to be on the same to copy a resource to a location that appears to be on the same
server. server.
8.8.1 COPY for HTTP/1.1 resources 8.8.1 COPY for HTTP/1.1 resources
skipping to change at page 37, line 25 skipping to change at page 37, line 32
propertybehavior XML element is defined in section 12.12. propertybehavior XML element is defined in section 12.12.
8.8.3 COPY for Collections 8.8.3 COPY for Collections
The COPY method on a collection without a Depth header MUST act as The COPY method on a collection without a Depth header MUST act as
if a Depth header with value "infinity" was included. A client may if a Depth header with value "infinity" was included. A client may
submit a Depth header on a COPY on a collection with a value of "0" submit a Depth header on a COPY on a collection with a value of "0"
or "infinity". DAV compliant servers MUST support the "0" and or "infinity". DAV compliant servers MUST support the "0" and
"infinity" Depth header behaviors. "infinity" Depth header behaviors.
A COPY of depth infinity instructs that the collection specified in A COPY of depth infinity instructs that the collection resource
the Request-URI is to be copied to the location specified in the identified by the Request-URI is to be copied to the location
Destination header, and all its internal member resources are to be identified by the URI in the Destination header, and all its
copied to a location relative to it, recursively through all levels internal member resources are to be copied to a location relative to
of the collection hierarchy. it, recursively through all levels of the collection hierarchy.
A COPY of "Depth: 0" only instructs that the collection and its A COPY of "Depth: 0" only instructs that the collection and its
properties but not its internal members, are to be copied. properties but not resources identified by its internal member URIs,
are to be copied.
Any headers included with a COPY MUST be applied in processing every Any headers included with a COPY MUST be applied in processing every
resource to be copied with the exception of the Destination header. resource to be copied with the exception of the Destination header.
The Destination header only specifies the destination for the The Destination header only specifies the destination URI for the
Request-URI. When applied to members of the collection specified in Request-URI. When applied to members of the collection identified by
the Request-URI the value of Destination is to be modified to the Request-URI the value of Destination is to be modified to
reflect the current location in the hierarchy. So, if the Request- reflect the current location in the hierarchy. So, if the Request-
URI is /a/ and the destination is /b/ then when /a/c/d is processed URI is /a/ with Host header value http://fun.com/ and the
it must use a destination of /b/c/d. Destination is http://fun.com/b/ then when http://fun.com/a/c/d is
processed it must use a Destination of http://fun.com/b/c/d.
When the COPY method has completed processing it MUST have created a When the COPY method has completed processing it MUST have created a
consistent namespace at the destination (see section 5.1 for the consistent namespace at the destination (see section 5.1 for the
definition of namespace consistency). However, if an error occurs definition of namespace consistency). However, if an error occurs
while copying an internal member collection, the server MUST NOT while copying an internal collection, the server MUST NOT copy any
copy any members of this collection (i.e., the server must skip this resources identified by members of this collection (i.e., the server
subtree), as this would create an inconsistent namespace. After must skip this subtree), as this would create an inconsistent
detecting an error, the COPY operation SHOULD try to finish as much namespace. After detecting an error, the COPY operation SHOULD try
of the original copy operation as possible (i.e., the server should to finish as much of the original copy operation as possible (i.e.,
still attempt to copy other subtrees and their members, that are not the server should still attempt to copy other subtrees and their
descendents of an error-causing collection). So, for example, if an members, that are not descendents of an error-causing collection).
infinite depth copy operation is performed on collection /a/, which So, for example, if an infinite depth copy operation is performed on
contains collections /a/b/ and /a/c/, and an error occurs copying collection /a/, which contains collections /a/b/ and /a/c/, and an
/a/b/, an attempt should still be made to copy /a/c/. Similarly, error occurs copying /a/b/, an attempt should still be made to copy
after encountering an error copying a non-collection resource as /a/c/. Similarly, after encountering an error copying a non-
part of an infinite depth copy, the server SHOULD try to finish as collection resource as part of an infinite depth copy, the server
much of the original copy operation as possible. SHOULD try to finish as much of the original copy operation as
possible.
If an error in executing the COPY method occurs with a resource If an error in executing the COPY method occurs with a resource
other than the resource identified in the Request-URI then the other than the resource identified in the Request-URI then the
response MUST be a 207 (Multi-Status). response MUST be a 207 (Multi-Status).
The 424 (Failed Dependency) status code SHOULD NOT be returned in The 424 (Failed Dependency) status code SHOULD NOT be returned in
the 207 (Multi-Status) response from a COPY method. These responses the 207 (Multi-Status) response from a COPY method. These responses
can be safely omitted because the client will know that the progeny can be safely omitted because the client will know that the progeny
of a resource could not be copied when the client receives an error of a resource could not be copied when the client receives an error
for the parent. Additionally 201 (Created)/204 (No Content) status for the parent. Additionally 201 (Created)/204 (No Content) status
skipping to change at page 39, line 50 skipping to change at page 40, line 14
8.8.8 Example - COPY of a Collection 8.8.8 Example - COPY of a Collection
>>Request >>Request
COPY /container/ HTTP/1.1 COPY /container/ HTTP/1.1
Host: www.foo.bar Host: www.foo.bar
Destination: http://www.foo.bar/othercontainer/ Destination: http://www.foo.bar/othercontainer/
Depth: infinity Depth: infinity
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<d:propertybehavior xmlns:d="DAV:"> <d:propertybehavior xmlns:d="DAV:">
<d:keepalive>*</d:keepalive> <d:keepalive>*</d:keepalive>
</d:propertybehavior> </d:propertybehavior>
>>Response >>Response
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d="DAV:"> <d:multistatus xmlns:d="DAV:">
<d:response> <d:response>
<d:href>http://www.foo.bar/othercontainer/R2/</d:href> <d:href>http://www.foo.bar/othercontainer/R2/</d:href>
<d:status>HTTP/1.1 412 Precondition Failed</d:status> <d:status>HTTP/1.1 412 Precondition Failed</d:status>
</d:response> </d:response>
</d:multistatus> </d:multistatus>
The Depth header is unnecessary as the default behavior of COPY on a The Depth header is unnecessary as the default behavior of COPY on a
skipping to change at page 40, line 31 skipping to change at page 40, line 48
collection, were copied successfully. However the collection R2 collection, were copied successfully. However the collection R2
failed, most likely due to a problem with maintaining the liveness failed, most likely due to a problem with maintaining the liveness
of properties (this is specified by the propertybehavior XML of properties (this is specified by the propertybehavior XML
element). Because there was an error copying R2, none of R2's element). Because there was an error copying R2, none of R2's
members were copied. However no errors were listed for those members were copied. However no errors were listed for those
members due to the error minimization rules given in section 8.8.3. members due to the error minimization rules given in section 8.8.3.
8.9 MOVE Method 8.9 MOVE Method
The MOVE operation on a non-collection resource is the logical The MOVE operation on a non-collection resource is the logical
equivalent of a copy (COPY) followed by a delete of the source, equivalent of a copy (COPY), followed by consistency maintenance
where the actions are performed atomically. Consequently, the processing, followed by a delete of the source, where all three
Destination header MUST be present on all MOVE methods and MUST actions are performed atomically. The consistency maintenance step
follow all COPY requirements for the COPY part of the MOVE method. allows the server to perform updates caused by the move, such as
All DAV compliant resources MUST support the MOVE method. However, updating all URIs other than the Request-URI which identify the
support for the MOVE method does not guarantee the ability to move a source resource, to point to the new destination resource.
resource to a particular destination. Consequently, the Destination header MUST be present on all MOVE
methods and MUST follow all COPY requirements for the COPY part of
the MOVE method. All DAV compliant resources MUST support the MOVE
method. However, support for the MOVE method does not guarantee the
ability to move a resource to a particular destination.
For example, separate programs may actually control different sets For example, separate programs may actually control different sets
of resources on the same server. Therefore, it may not be possible of resources on the same server. Therefore, it may not be possible
to move a resource within a namespace that appears to belong to the to move a resource within a namespace that appears to belong to the
same server. same server.
If a resource exists at the destination, the destination resource If a resource exists at the destination, the destination resource
will be DELETEd as a side-effect of the MOVE operation, subject to will be DELETEd as a side-effect of the MOVE operation, subject to
the restrictions of the Overwrite header. the restrictions of the Overwrite header.
8.9.1 MOVE for Properties 8.9.1 MOVE for Properties
The behavior of properties on a MOVE, including the effects of the The behavior of properties on a MOVE, including the effects of the
propertybehavior XML element, MUST be the same as specified in propertybehavior XML element, MUST be the same as specified in
section 8.8.2. section 8.8.2.
8.9.2 MOVE for Collections 8.9.2 MOVE for Collections
A MOVE with "Depth: infinity" instructs that the collection A MOVE with "Depth: infinity" instructs that the collection
specified in the Request-URI be moved to the location specified in identified by the Request-URI be moved to the URI specified in the
the Destination header, and all its internal member resources are to Destination header, and all resources identified by its internal
be moved to locations relative to it, recursively through all levels member URIs are to be moved to locations relative to it, recursively
of the collection hierarchy. through all levels of the collection hierarchy.
The MOVE method on a collection MUST act as if a "Depth: infinity" The MOVE method on a collection MUST act as if a "Depth: infinity"
header was used on it. A client MUST NOT submit a Depth header on a header was used on it. A client MUST NOT submit a Depth header on a
MOVE on a collection with any value but "infinity". MOVE on a collection with any value but "infinity".
Any headers included with MOVE MUST be applied in processing every Any headers included with MOVE MUST be applied in processing every
resource to be moved with the exception of the Destination header. resource to be moved with the exception of the Destination header.
The behavior of the Destination header is the same as given for COPY The behavior of the Destination header is the same as given for COPY
on collections. on collections.
When the MOVE method has completed processing it MUST have created a When the MOVE method has completed processing it MUST have created a
consistent namespace on both the source and destination (see section consistent namespace at both the source and destination (see section
5.1 for the definition of namespace consistency). However, if an 5.1 for the definition of namespace consistency). However, if an
error occurs while moving an internal member collection, the server error occurs while moving an internal collection, the server MUST
MUST NOT move any members of the failed collection (i.e., the server NOT move any resources identified by members of the failed
must skip the error-causing subtree), as this would create an collection (i.e., the server must skip the error-causing subtree),
inconsistent namespace. In this case, after detecting the error, the as this would create an inconsistent namespace. In this case, after
move operation SHOULD try to finish as much of the original move as detecting the error, the move operation SHOULD try to finish as much
possible (i.e., the server should still attempt to move other of the original move as possible (i.e., the server should still
subtrees and their members, that are not descendents of an error- attempt to move other subtrees and the resources identified by their
causing collection). So, for example, if an infinite depth move is members, that are not descendents of an error-causing collection).
performed on collection /a/, which contains collections /a/b/ and So, for example, if an infinite depth move is performed on
/a/c/, and an error occurs moving /a/b/, an attempt should still be collection /a/, which contains collections /a/b/ and /a/c/, and an
made to try moving /a/c/. Similarly, after encountering an error error occurs moving /a/b/, an attempt should still be made to try
moving a non-collection resource as part of an infinite depth move, moving /a/c/. Similarly, after encountering an error moving a non-
the server SHOULD try to finish as much of the original move collection resource as part of an infinite depth move, the server
operation as possible. SHOULD try to finish as much of the original move operation as
possible.
If an error occurs with a resource other than the resource If an error occurs with a resource other than the resource
identified in the Request-URI then the response MUST be a 207 identified in the Request-URI then the response MUST be a 207
(Multi-Status). (Multi-Status).
The 424 (Failed Dependency) status code SHOULD NOT be returned in The 424 (Failed Dependency) status code SHOULD NOT be returned in
the 207 (Multi-Status) response from a MOVE method. These errors the 207 (Multi-Status) response from a MOVE method. These errors
can be safely omitted because the client will know that the progeny can be safely omitted because the client will know that the progeny
of a resource could not be moved when the client receives an error of a resource could not be moved when the client receives an error
for the parent. Additionally 201 (Created)/204 (No Content) for the parent. Additionally 201 (Created)/204 (No Content)
skipping to change at page 43, line 16 skipping to change at page 43, line 32
>>Request >>Request
MOVE /container/ HTTP/1.1 MOVE /container/ HTTP/1.1
Host: www.foo.bar Host: www.foo.bar
Destination: http://www.foo.bar/othercontainer/ Destination: http://www.foo.bar/othercontainer/
Overwrite: F Overwrite: F
If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>) If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
(<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>) (<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xyz Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<d:propertybehavior xmlns:d='DAV:'> <d:propertybehavior xmlns:d='DAV:'>
<d:keepalive>*</d:keepalive> <d:keepalive>*</d:keepalive>
</d:propertybehavior> </d:propertybehavior>
>>Response >>Response
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: zzz Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<d:multistatus xmlns:d='DAV:'> <d:multistatus xmlns:d='DAV:'>
<d:response> <d:response>
<d:href>http://www.foo.bar/othercontainer/C2/</d:href> <d:href>http://www.foo.bar/othercontainer/C2/</d:href>
<d:status>HTTP/1.1 423 Locked</d:status> <d:status>HTTP/1.1 423 Locked</d:status>
</d:response> </d:response>
</d:multistatus> </d:multistatus>
In this example the client has submitted a number of lock tokens In this example the client has submitted a number of lock tokens
with the request. A lock token will need to be submitted for every with the request. A lock token will need to be submitted for every
resource, both source and destination, anywhere in the scope of the resource, both source and destination, anywhere in the scope of the
method, that is locked. In this case the proper lock token was not method, that is locked. In this case the proper lock token was not
submitted for the destination http://www.foo.bar/othercontainer/C2/. submitted for the destination http://www.foo.bar/othercontainer/C2/.
This means that the resource /container/C2/ could not be moved. This means that the resource /container/C2/ could not be moved.
Because there was an error copying /container/C2/, none of Because there was an error copying /container/C2/, none of
/container/C2's members were copied. However no errors were listed /container/C2's members were copied. However no errors were listed
for those members due to the error minimization rules given in for those members due to the error minimization rules given in
section 8.8.3. User agent authentication has previously occurred section 8.8.3. User agent authentication has previously occurred
skipping to change at page 45, line 36 skipping to change at page 46, line 12
lock type. However, independent of lock type, a successful DELETE lock type. However, independent of lock type, a successful DELETE
of a resource MUST cause all of its locks to be removed. of a resource MUST cause all of its locks to be removed.
8.10.6 Lock Compatibility Table 8.10.6 Lock Compatibility Table
The table below describes the behavior that occurs when a lock The table below describes the behavior that occurs when a lock
request is made on a resource. request is made on a resource.
Current lock state/ | Shared Lock | Exclusive Current lock state/ | Shared Lock | Exclusive
Lock request | | Lock Lock request | | Lock
=====================+=================+=============== =====================+=================+==============
None | True | True None | True | True
---------------------+-----------------+--------------- ---------------------+-----------------+--------------
Shared Lock | True | False Shared Lock | True | False
---------------------+-----------------+--------------- ---------------------+-----------------+--------------
Exclusive Lock | False | False* Exclusive Lock | False | False*
------------------------------------------------------- ------------------------------------------------------
Legend: True = lock may be granted. False = lock MUST NOT be Legend: True = lock may be granted. False = lock MUST NOT be
granted. *=It is illegal for a principal to request the same lock granted. *=It is illegal for a principal to request the same lock
twice. twice.
The current lock state of a resource is given in the leftmost The current lock state of a resource is given in the leftmost
column, and lock requests are listed in the first row. The column, and lock requests are listed in the first row. The
intersection of a row and column gives the result of a lock request. intersection of a row and column gives the result of a lock request.
For example, if a shared lock is held on a resource, and an For example, if a shared lock is held on a resource, and an
exclusive lock is requested, the table entry is "false", indicating exclusive lock is requested, the table entry is "false", indicating
skipping to change at page 46, line 25 skipping to change at page 47, line 13
rejected. rejected.
8.10.8 Example - Simple Lock Request 8.10.8 Example - Simple Lock Request
>>Request >>Request
LOCK /workspace/webdav/proposal.doc HTTP/1.1 LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com Host: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000 Timeout: Infinite, Second-4100000000
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xyz Content-Length: xxxx
Authorization: Digest username="ejw", Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...", realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc", uri="/workspace/webdav/proposal.doc",
response="...", opaque="..." response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D='DAV:'> <D:lockinfo xmlns:D='DAV:'>
<D:lockscope><D:exclusive/></D:lockscope> <D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype> <D:locktype><D:write/></D:locktype>
<D:owner> <D:owner>
skipping to change at page 47, line 4 skipping to change at page 47, line 27
response="...", opaque="..." response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D='DAV:'> <D:lockinfo xmlns:D='DAV:'>
<D:lockscope><D:exclusive/></D:lockscope> <D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype> <D:locktype><D:write/></D:locktype>
<D:owner> <D:owner>
<D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href> <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
</D:owner> </D:owner>
</D:lockinfo> </D:lockinfo>
>>Response >>Response
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:"> <D:prop xmlns:D="DAV:">
<D:lockdiscovery> <D:lockdiscovery>
<D:activelock> <D:activelock>
<D:locktype><D:write/></D:locktype> <D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope> <D:lockscope><D:exclusive/></D:lockscope>
<D:depth>Infinity</D:depth> <D:depth>Infinity</D:depth>
<D:owner> <D:owner>
<D:href> <D:href>
skipping to change at page 48, line 22 skipping to change at page 48, line 31
If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>) If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
Authorization: Digest username="ejw", Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...", realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc", uri="/workspace/webdav/proposal.doc",
response="...", opaque="..." response="...", opaque="..."
>>Response >>Response
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:prop xmlns:D="DAV:"> <D:prop xmlns:D="DAV:">
<D:lockdiscovery> <D:lockdiscovery>
<D:activelock> <D:activelock>
<D:locktype><D:write/></D:locktype> <D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope> <D:lockscope><D:exclusive/></D:lockscope>
<D:depth>Infinity</D:depth> <D:depth>Infinity</D:depth>
<D:owner> <D:owner>
<D:href> <D:href>
skipping to change at page 49, line 14 skipping to change at page 49, line 19
8.10.10 Example - Multi-Resource Lock Request 8.10.10 Example - Multi-Resource Lock Request
>>Request >>Request
LOCK /webdav/ HTTP/1.1 LOCK /webdav/ HTTP/1.1
Host: webdav.sb.aol.com Host: webdav.sb.aol.com
Timeout: Infinite, Second-4100000000 Timeout: Infinite, Second-4100000000
Depth: infinity Depth: infinity
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxxx Content-Length: xxxx
Authorization: Digest username="ejw", Authorization: Digest username="ejw",
realm="ejw@webdav.sb.aol.com", nonce="...", realm="ejw@webdav.sb.aol.com", nonce="...",
uri="/workspace/webdav/proposal.doc", uri="/workspace/webdav/proposal.doc",
response="...", opaque="..." response="...", opaque="..."
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D="DAV:"> <D:lockinfo xmlns:D="DAV:">
<D:locktype><D:write/></D:locktype> <D:locktype><D:write/></D:locktype>
<D:lockscope><D:exclusive/></D:lockscope> <D:lockscope><D:exclusive/></D:lockscope>
<D:owner> <D:owner>
<D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href> <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
</D:owner> </D:owner>
</D:lockinfo> </D:lockinfo>
>>Response >>Response
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"> <D:multistatus xmlns:D="DAV:">
<D:response> <D:response>
<D:href>http://webdav.sb.aol.com/webdav/secret</D:href> <D:href>http://webdav.sb.aol.com/webdav/secret</D:href>
<D:status>HTTP/1.1 403 Forbidden</D:status> <D:status>HTTP/1.1 403 Forbidden</D:status>
</D:response> </D:response>
<D:response> <D:response>
<D:href>http://webdav.sb.aol.com/webdav/</D:href> <D:href>http://webdav.sb.aol.com/webdav/</D:href>
<D:propstat> <D:propstat>
skipping to change at page 52, line 33 skipping to change at page 52, line 40
for the Depth header that is not allowed by the method's definition. for the Depth header that is not allowed by the method's definition.
Thus submitting a "Depth: 1" on a COPY, even if the resource does Thus submitting a "Depth: 1" on a COPY, even if the resource does
not have internal members, will result in a 400 (Bad Request). The not have internal members, will result in a 400 (Bad Request). The
method should fail not because the resource doesn't have internal method should fail not because the resource doesn't have internal
members, but because of the illegal value in the header. members, but because of the illegal value in the header.
9.3 Destination Header 9.3 Destination Header
Destination = "Destination" ":" absoluteURI Destination = "Destination" ":" absoluteURI
The Destination header specifies a destination resource for methods The Destination header specifies the URI which identifies a
such as COPY and MOVE, which take two URIs as parameters. Note that destination resource for methods such as COPY and MOVE, which take
the absoluteURI production is defined in [RFC2396]. two URIs as parameters. Note that the absoluteURI production is
defined in [RFC2396].
9.4 If Header 9.4 If Header
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list) If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
No-tag-list = List No-tag-list = List
Tagged-list = Resource 1*List Tagged-list = Resource 1*List
Resource = Coded-url Resource = Coded-URL
List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")" List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
State-token = Coded-URL State-token = Coded-URL
Coded-URL = "<" absoluteURI ">" Coded-URL = "<" absoluteURI ">"
The If header is intended to have similar functionality to the If- The If header is intended to have similar functionality to the If-
Match header defined in section 14.25 of [RFC2068]. However the If Match header defined in section 14.25 of [RFC2068]. However the If
header is intended for use with any URI which represents state header is intended for use with any URI which represents state
information, referred to as a state token, about a resource as well information, referred to as a state token, about a resource as well
as ETags. A typical example of a state token is a lock token, and as ETags. A typical example of a state token is a lock token, and
lock tokens are the only state tokens defined in this specification. lock tokens are the only state tokens defined in this specification.
skipping to change at page 56, line 30 skipping to change at page 56, line 40
However, the server is not required to honor or even consider these However, the server is not required to honor or even consider these
requests. Clients MUST NOT submit a Timeout request header with any requests. Clients MUST NOT submit a Timeout request header with any
method other than a LOCK method. method other than a LOCK method.
A Timeout request header MUST contain at least one TimeType and may A Timeout request header MUST contain at least one TimeType and may
contain multiple TimeType entries. The purpose of listing multiple contain multiple TimeType entries. The purpose of listing multiple
TimeType entries is to indicate multiple different values and value TimeType entries is to indicate multiple different values and value
types that are acceptable to the client. The client lists the types that are acceptable to the client. The client lists the
TimeType entries in order of preference. TimeType entries in order of preference.
Timeout response valuse MUST use a Second value, Infinite, or a Timeout response values MUST use a Second value, Infinite, or a
TimeType the client has indicated familiarity with. The server may TimeType the client has indicated familiarity with. The server may
assume a client is familiar with any TimeType submitted in a Timeout assume a client is familiar with any TimeType submitted in a Timeout
header. header.
The "Second" TimeType specifies the number of seconds that will The "Second" TimeType specifies the number of seconds that will
elapse between granting of the lock at the server, and the automatic elapse between granting of the lock at the server, and the automatic
removal of the lock. The timeout value for timetype "Second" MUST removal of the lock. The timeout value for TimeType "Second" MUST
NOT be greater than 2^32-1. NOT be greater than 2^32-1.
The timeout counter SHOULD be restarted any time an owner of the The timeout counter SHOULD be restarted any time an owner of the
lock sends a method to any member of the lock, including unsupported lock sends a method to any member of the lock, including unsupported
methods, or methods which are unsuccessful. However the lock MUST methods, or methods which are unsuccessful. However the lock MUST
be refreshed if a refresh LOCK method is successfully received. be refreshed if a refresh LOCK method is successfully received.
If the timeout expires then the lock may be lost. Specifically, if If the timeout expires then the lock may be lost. Specifically, if
the server wishes to harvest the lock upon time-out, the server the server wishes to harvest the lock upon time-out, the server
SHOULD act as if an UNLOCK method was executed by the server on the SHOULD act as if an UNLOCK method was executed by the server on the
skipping to change at page 65, line 26 skipping to change at page 65, line 26
<!ELEMENT remove (prop) > <!ELEMENT remove (prop) >
12.13.2 set XML element 12.13.2 set XML element
Name: set Name: set
Namespace: DAV: Namespace: DAV:
Purpose: Lists the DAV property values to be set for a resource. Purpose: Lists the DAV property values to be set for a resource.
Description: The set XML element MUST contain only a prop XML Description: The set XML element MUST contain only a prop XML
element. The elements contained by the prop XML element inside the element. The elements contained by the prop XML element inside the
set XML element MUST specify the name and value of properties that set XML element MUST specify the name and value of properties that
are set on the Request-URI. If a property already exists then its are set on the resource identified by Request-URI. If a property
value is replaced. Language tagging information in the property's already exists then its value is replaced. Language tagging
value (in the "xml:lang" attribute, if present) MUST be persistently information in the property's value (in the "xml:lang" attribute, if
stored along with the property, and MUST be subsequently retrievable present) MUST be persistently stored along with the property, and
using PROPFIND. MUST be subsequently retrievable using PROPFIND.
<!ELEMENT set (prop) > <!ELEMENT set (prop) >
12.14 propfind XML Element 12.14 propfind XML Element
Name: propfind Name: propfind
Namespace: DAV: Namespace: DAV:
Purpose: Specifies the properties to be returned from a PROPFIND Purpose: Specifies the properties to be returned from a PROPFIND
method. Two special elements are specified for use with propfind, method. Two special elements are specified for use with propfind,
allprop and propname. If prop is used inside propfind it MUST only allprop and propname. If prop is used inside propfind it MUST only
skipping to change at page 69, line 8 skipping to change at page 69, line 8
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D='DAV:'> <D:propfind xmlns:D='DAV:'>
<D:prop><D:lockdiscovery/></D:prop> <D:prop><D:lockdiscovery/></D:prop>
</D:propfind> </D:propfind>
>>Response >>Response
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxxx Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D='DAV:'> <D:multistatus xmlns:D='DAV:'>
<D:response> <D:response>
<D:href>http://www.foo.bar/container/</D:href> <D:href>http://www.foo.bar/container/</D:href>
<D:propstat> <D:propstat>
<D:prop> <D:prop>
<D:lockdiscovery> <D:lockdiscovery>
<D:activelock> <D:activelock>
<D:locktype><D:write/></D:locktype> <D:locktype><D:write/></D:locktype>
skipping to change at page 72, line 7 skipping to change at page 72, line 7
Content-Length: xxxx Content-Length: xxxx
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:"> <D:propfind xmlns:D="DAV:">
<D:prop><D:supportedlock/></D:prop> <D:prop><D:supportedlock/></D:prop>
</D:propfind> </D:propfind>
>>Response >>Response
HTTP/1.1 207 Multi-Status HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"Content-Length: xxxxx Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"> <D:multistatus xmlns:D="DAV:">
<D:response> <D:response>
<D:href>http://www.foo.bar/container/</D:href> <D:href>http://www.foo.bar/container/</D:href>
<D:propstat> <D:propstat>
<D:prop> <D:prop>
<D:supportedlock> <D:supportedlock>
<D:lockentry> <D:lockentry>
<D:lockscope><D:exclusive/></D:lockscope> <D:lockscope><D:exclusive/></D:lockscope>
skipping to change at page 73, line 5 skipping to change at page 72, line 49
property values where unknown XML elements SHOULD be ignored unless property values where unknown XML elements SHOULD be ignored unless
the property's schema declares otherwise. the property's schema declares otherwise.
This restriction does not apply to setting dead DAV properties on This restriction does not apply to setting dead DAV properties on
the server where the server MUST record unknown XML elements. the server where the server MUST record unknown XML elements.
Additionally, this restriction does not apply to the use of XML Additionally, this restriction does not apply to the use of XML
where XML happens to be the content type of the entity body, for where XML happens to be the content type of the entity body, for
example, when used as the body of a PUT. example, when used as the body of a PUT.
Since XML can be transported as text/xml or application/xml, a DAV
server MUST accept DAV method requests with XML parameters
transported as either text/xml or application/xml, and DAV client
MUST accept XML responses using either text/xml or application/xml.
15 DAV Compliance Classes 15 DAV Compliance Classes
A DAV compliant resource can choose from two classes of compliance. A DAV compliant resource can choose from two classes of compliance.
A client can discover the compliance classes of a resource by A client can discover the compliance classes of a resource by
executing OPTIONS on the resource, and examining the "DAV" header executing OPTIONS on the resource, and examining the "DAV" header
which is returned. which is returned.
Since this document describes extensions to the HTTP/1.1 protocol, Since this document describes extensions to the HTTP/1.1 protocol,
minimally all DAV compliant resources, clients, and proxies MUST be minimally all DAV compliant resources, clients, and proxies MUST be
compliant with [RFC2068]. compliant with [RFC2068].
skipping to change at page 76, line 55 skipping to change at page 76, line 55
information via properties, servers are encouraged to develop access information via properties, servers are encouraged to develop access
control mechanisms that separate read access to the resource body control mechanisms that separate read access to the resource body
and read access to the resource's properties. This allows a user to and read access to the resource's properties. This allows a user to
control the dissemination of their property data without overly control the dissemination of their property data without overly
restricting access to the resource's contents. restricting access to the resource's contents.
17.6 Reduction of Security due to Source Link 17.6 Reduction of Security due to Source Link
HTTP/1.1 warns against providing read access to script code because HTTP/1.1 warns against providing read access to script code because
it may contain sensitive information. Yet WebDAV, via its source it may contain sensitive information. Yet WebDAV, via its source
link facility, can potentially provide a URL for script resources so link facility, can potentially provide a URI for script resources so
they may be authored. For HTTP/1.1, a server could reasonably they may be authored. For HTTP/1.1, a server could reasonably
prevent access to source resources due to the predominance of read- prevent access to source resources due to the predominance of read-
only access. WebDAV, with its emphasis on authoring, encourages only access. WebDAV, with its emphasis on authoring, encourages
read and write access to source resources, and provides the source read and write access to source resources, and provides the source
link facility to identify the source. This reduces the security link facility to identify the source. This reduces the security
benefits of eliminating access to source resources. Users and benefits of eliminating access to source resources. Users and
administrators of WebDAV servers should be very cautious when administrators of WebDAV servers should be very cautious when
allowing remote authoring of scripts, limiting read and write access allowing remote authoring of scripts, limiting read and write access
to the source resources to authorized principals. to the source resources to authorized principals.
skipping to change at page 77, line 45 skipping to change at page 77, line 45
There is also the scalability risk that would accompany a widely There is also the scalability risk that would accompany a widely
deployed application which made use of external XML entities. In deployed application which made use of external XML entities. In
this situation, it is possible that there would be significant this situation, it is possible that there would be significant
numbers of requests for one external XML entity, potentially numbers of requests for one external XML entity, potentially
overloading any server which fields requests for the resource overloading any server which fields requests for the resource
containing the external XML entity. containing the external XML entity.
17.8 Risks Connected with Lock Tokens 17.8 Risks Connected with Lock Tokens
This specification, in section 6.4, requires the use of Globally This specification, in section 6.4, requires the use of Universal
Unique Identifiers (GUIDs) for lock tokens, in order to guarantee Unique Identifiers (UUIDs) for lock tokens, in order to guarantee
their uniqueness across space and time. GUIDs, as defined in [ISO- their uniqueness across space and time. UUIDs, as defined in [ISO-
11578], contain a "node" field which "consists of the IEEE address, 11578], contain a "node" field which "consists of the IEEE address,
usually the host address. For systems with multiple IEEE 802 nodes, usually the host address. For systems with multiple IEEE 802 nodes,
any available node address can be used." Since a WebDAV server will any available node address can be used." Since a WebDAV server will
issue many locks over its lifetime, the implication is that it will issue many locks over its lifetime, the implication is that it will
also be publicly exposing its IEEE 802 address. also be publicly exposing its IEEE 802 address.
There are several risks associated with exposure of IEEE 802 There are several risks associated with exposure of IEEE 802
addresses. Using the IEEE 802 address: addresses. Using the IEEE 802 address:
* It is possible to track the movement of hardware from subnet to * It is possible to track the movement of hardware from subnet to
skipping to change at page 78, line 13 skipping to change at page 78, line 13
addresses. Using the IEEE 802 address: addresses. Using the IEEE 802 address:
* It is possible to track the movement of hardware from subnet to * It is possible to track the movement of hardware from subnet to
subnet. subnet.
* It may be possible to identify the manufacturer of the hardware * It may be possible to identify the manufacturer of the hardware
running a WebDAV server. running a WebDAV server.
* It may be possible to determine the number of each type of * It may be possible to determine the number of each type of
computer running WebDAV. computer running WebDAV.
Section 6.4.1 of this specification details an alternate mechanism Section 6.4.1 of this specification details an alternate mechanism
for generating the "node" field of a GUID without using an IEEE 802 for generating the "node" field of a UUID without using an IEEE 802
address, which alleviates the risks associated with exposure of IEEE address, which alleviates the risks associated with exposure of IEEE
802 addresses by using an alternate source of uniqueness. 802 addresses by using an alternate source of uniqueness.
18 IANA Considerations 18 IANA Considerations
This document defines two namespaces, the namespace of property This document defines two namespaces, the namespace of property
names, and the namespace of WebDAV-specific XML elements used within names, and the namespace of WebDAV-specific XML elements used within
property values. property values.
URLs are used for both names, for several reasons. Assignment of a URIs are used for both names, for several reasons. Assignment of a
URL does not require a request to a central naming authority, and URI does not require a request to a central naming authority, and
hence allow WebDAV property names and XML elements to be quickly hence allow WebDAV property names and XML elements to be quickly
defined by any WebDAV user or application. URLs also provide a defined by any WebDAV user or application. URIs also provide a
unique address space, ensuring that the distributed users of WebDAV unique address space, ensuring that the distributed users of WebDAV
will not have collisions among the property names and XML elements will not have collisions among the property names and XML elements
they create. they create.
This specification defines a distinguished set of property names and This specification defines a distinguished set of property names and
XML elements that are understood by all WebDAV applications. The XML elements that are understood by all WebDAV applications. The
property names and XML elements in this specification are all property names and XML elements in this specification are all
derived from the base URI DAV: by adding a suffix to this URI, for derived from the base URI DAV: by adding a suffix to this URI, for
example, DAV:creationdate for the "creationdate" property. example, DAV:creationdate for the "creationdate" property.
skipping to change at page 80, line 20 skipping to change at page 80, line 20
valuable at every stage of our work. valuable at every stage of our work.
Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan
Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners- Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-
Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith
Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee
Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan
Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis
Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van
der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur,
Steven Martin, Larry Masinter, Michael Mealling, Keith Moore, Henrik Steven Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas
Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen Narten, Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon
Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike Radoff, Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith
Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Slein, Mike Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick,
Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar Kenji Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar
Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and Lauren Wood. Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and Lauren Wood.
Two from this list deserve special mention. The contributions by Two from this list deserve special mention. The contributions by
Larry Masinter have been invaluable, both in helping the formation Larry Masinter have been invaluable, both in helping the formation
of the working group and in patiently coaching the authors along the of the working group and in patiently coaching the authors along the
way. In so many ways he has set high standards we have toiled to way. In so many ways he has set high standards we have toiled to
meet. The contributions of Judith Slein in clarifying the meet. The contributions of Judith Slein in clarifying the
requirements, and in patiently reviewing draft after draft, both requirements, and in patiently reviewing draft after draft, both
improved this specification and expanded our minds on document improved this specification and expanded our minds on document
management. management.
skipping to change at page 81, line 52 skipping to change at page 81, line 52
[ISO-8601] ISO (International Organization for Standardization). ISO [ISO-8601] ISO (International Organization for Standardization). ISO
8601:1988. "Data elements and interchange formats - 8601:1988. "Data elements and interchange formats -
Information interchange - Representation of dates and Information interchange - Representation of dates and
times." times."
[ISO-11578] ISO (International Organization for Standardization). [ISO-11578] ISO (International Organization for Standardization).
ISO/IEC 11578:1996. "Information technology - Open Systems ISO/IEC 11578:1996. "Information technology - Open Systems
Interconnection - Remote Procedure Call (RPC)" Interconnection - Remote Procedure Call (RPC)"
[RFC2141] R. Moats, "URN Syntax." RFC 2141. AT&T. May, 1997.
[UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode and [UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode and
ISO 10646." RFC 2279. Alis Technologies. January, 1998. ISO 10646." RFC 2279. Alis Technologies. January, 1998.
22.2 Informational References 22.2 Informational References
[RFC2026] S. Bradner, "The Internet Standards Process - Revision 3." [RFC2026] S. Bradner, "The Internet Standards Process - Revision 3."
RFC 2026, BCP 9. Harvard University. October, 1996. RFC 2026, BCP 9. Harvard University. October, 1996.
[WD-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Name Spaces in [WD-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Name Spaces in
XML" World Wide Web Consortium Working Draft, XML" World Wide Web Consortium Working Draft,
http://www.w3.org/TR/WD-xml-names. http://www.w3.org/TR/WD-xml-names.
[RFC1807] R. Lasher, D. Cohen, "A Format for Bibliographic Records," [RFC1807] R. Lasher, D. Cohen, "A Format for Bibliographic Records,"
RFC 1807. Stanford, Myricom. June, 1995. RFC 1807. Stanford, Myricom. June, 1995.
[WF] C. Lagoze, "The Warwick Framework: A Container
Architecture for Diverse Sets of Metadata", D-Lib
Magazine, July/August 1996.
http://www.dlib.org/dlib/july96/lagoze/07lagoze.html
[USMARC] Network Development and MARC Standards, Office, ed. 1994. [USMARC] Network Development and MARC Standards, Office, ed. 1994.
"USMARC Format for Bibliographic Data", 1994. Washington, "USMARC Format for Bibliographic Data", 1994. Washington,
DC: Cataloging Distribution Service, Library of Congress. DC: Cataloging Distribution Service, Library of Congress.
[REC-PICS] J. Miller, T. Krauskopf, P. Resnick, W. Treese, "PICS [REC-PICS] J. Miller, T. Krauskopf, P. Resnick, W. Treese, "PICS
Label Distribution Label Syntax and Communication Label Distribution Label Syntax and Communication
Protocols" Version 1.1, World Wide Web Consortium Protocols" Version 1.1, World Wide Web Consortium
Recommendation REC-PICS-labels-961031. Recommendation REC-PICS-labels-961031.
http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html. http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.
skipping to change at page 85, line 36 skipping to change at page 85, line 35
<!ELEMENT resourcetype ANY > <!ELEMENT resourcetype ANY >
<!ELEMENT source (link)* > <!ELEMENT source (link)* >
<!ELEMENT supportedlock (lockentry)* > <!ELEMENT supportedlock (lockentry)* >
]> ]>
24.2 Appendix 2 - ISO 8601 Date and Time Profile 24.2 Appendix 2 - ISO 8601 Date and Time Profile
The creationdate property specifies the use of the ISO 8601 date The creationdate property specifies the use of the ISO 8601 date
format [ISO-8601]. This section defines a profile of the ISO 8601 format [ISO-8601]. This section defines a profile of the ISO 8601
date format for use with this specification. This profile is quoted date format for use with this specification. This profile is quoted
verbatim from draft-newman-datetime-01.txt (expired). from an Internet-Draft by Chris Newman, and is mentioned here to
properly attribute his work.
date-time = full-date "T" full-time date-time = full-date "T" full-time
full-date = date-fullyear "-" date-month "-" date-mday full-date = date-fullyear "-" date-month "-" date-mday
full-time = partial-time time-offset full-time = partial-time time-offset
date-fullyear = 4DIGIT date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12 date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
month/year month/year
 End of changes. 

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