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