--- 1/draft-ietf-webdav-protocol-07.txt 2006-02-05 02:11:16.000000000 +0100 +++ 2/draft-ietf-webdav-protocol-08.txt 2006-02-05 02:11:16.000000000 +0100 @@ -1,37 +1,38 @@ 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 August, 1998 March 6, 1998 +Expires September, 1998 April 7, 1998 Extensions for Distributed Authoring on the World Wide Web -- WEBDAV Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". - To learn the current status of any Internet-Draft, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), - munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or - ftp.isi.edu (US West Coast). + To view the entire list of current Internet-Drafts, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net + (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au + (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu + (US West Coast). Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WEBDAV) working group at , which may be joined by sending a message with subject "subscribe" to . Discussions of the WEBDAV working group are archived at . Abstract @@ -39,203 +40,229 @@ This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). Contents STATUS OF THIS MEMO..................................................1 ABSTRACT.............................................................1 CONTENTS.............................................................2 + 1 INTRODUCTION.......................................................7 + 2 NOTATIONAL CONVENTIONS.............................................8 + 3 DATA MODEL FOR RESOURCE PROPERTIES.................................8 3.1 The Resource Property Model.....................................8 3.2 Existing Metadata Proposals.....................................9 3.3 Properties and HTTP Headers....................................10 3.4 Property Values................................................10 3.5 Property Names.................................................10 3.6 Media Independent Links........................................11 + 4 COLLECTIONS OF WEB RESOURCES......................................11 4.1 Collection Resources...........................................11 4.2 Creation and Retrieval of Collection Resources.................12 4.3 HTTP URL Namespace Model.......................................12 4.4 Source Resources and Output Resources..........................12 + 5 LOCKING...........................................................13 5.1 Exclusive Vs. Shared Locks.....................................14 5.2 Required Support...............................................15 5.3 Lock Tokens....................................................15 5.4 opaquelocktoken Lock Token URI Scheme..........................15 5.5 Lock Capability Discovery......................................16 5.6 Active Lock Discovery..........................................16 5.7 Usage Considerations...........................................16 + 6 WRITE LOCK........................................................17 6.1 Methods Restricted by Write Locks..............................17 6.2 Write Locks and Properties.....................................18 6.3 Write Locks and Null Resources.................................18 6.4 Write Locks and Collections....................................18 6.5 Write Locks and the If Request Header..........................19 - 6.5.1Write Lock Example............................................19 -6.6 Write Locks and COPY/MOVE......................................19 + 6.5.1 Example - Write Lock .........................................19 +6.6 Write Locks and COPY/MOVE ......................................20 6.7 Refreshing Write Locks.........................................20 + 7 HTTP METHODS FOR DISTRIBUTED AUTHORING............................20 7.1 PROPFIND.......................................................21 - 7.1.1 Example: Retrieving Named Properties.........................22 - 7.1.2 Example: Using allprop to Retrieve All Properties............23 - 7.1.3 Example: Using propname to Retrieve all Property Names.......26 + 7.1.1 Example - Retrieving Named Properties ........................22 + 7.1.2 Example - Using allprop to Retrieve All Properties ...........23 + 7.1.3 Example - Using propname to Retrieve all Property Names ......25 7.2 PROPPATCH......................................................27 - 7.2.1 Status Codes for use with Multi-Status.......................28 - 7.2.2 Example......................................................28 + 7.2.1 Status Codes for use with Multi-Status .......................27 + 7.2.2 Example - PROPPATCH ..........................................28 7.3 MKCOL Method...................................................29 7.3.1 Request......................................................29 7.3.2 Response Codes...............................................30 - 7.3.3 Example......................................................30 + 7.3.3 Example - MKCOL ..............................................30 7.4 GET, HEAD for Collections......................................31 + 7.5 POST for Collections...........................................31 + 7.6 DELETE.........................................................31 7.6.1 DELETE for Non-Collection Resources..........................31 7.6.2 DELETE for Collections.......................................31 + 7.7 PUT............................................................32 7.7.1 PUT for Non-Collection Resources.............................32 7.7.2 PUT for Collections..........................................33 + 7.8 COPY Method....................................................33 7.8.1 COPY for HTTP/1.1 resources..................................33 7.8.2 COPY for Properties..........................................34 7.8.3 COPY for Collections.........................................34 7.8.4 COPY and the Overwrite Header................................35 7.8.5 Status Codes.................................................35 - 7.8.6 Overwrite Example............................................35 - 7.8.7 No Overwrite Example.........................................36 - 7.8.8 Collection Example...........................................36 + 7.8.6 Example - COPY with Overwrite ................................36 + 7.8.7 Example - COPY with No Overwrite .............................36 + 7.8.8 Example - COPY of a Collection ...............................36 + 7.9 MOVE Method....................................................37 7.9.1 MOVE for Properties..........................................37 7.9.2 MOVE for Collections.........................................38 7.9.3 MOVE and the Overwrite Header................................38 7.9.4 Status Codes.................................................39 - 7.9.5 Non-Collection Example.......................................39 - 7.9.6 Collection Example...........................................39 -7.10 LOCK Method....................................................40 + 7.9.5 Example - MOVE of a Non-Collection ...........................39 + 7.9.6 Example - MOVE of a Collection ...............................39 + +7.10 LOCK Method ...................................................40 7.10.1 Operation...................................................40 7.10.2 The Effect of Locks on Properties and Collections...........41 7.10.3 Locking Replicated Resources................................41 7.10.4 Depth and Locking...........................................41 7.10.5 Interaction with other Methods..............................42 7.10.6 Lock Compatibility Table....................................42 7.10.7 Status Codes................................................42 7.10.8 Example - Simple Lock Request...............................43 7.10.9 Example - Refreshing a Write Lock...........................44 7.10.10 Example - Multi-Resource Lock Request......................45 -7.11 UNLOCK Method..................................................46 - 7.11.1 Example.....................................................46 + +7.11 UNLOCK Method .................................................46 + 7.11.1 Example - UNLOCK ............................................46 + 8 HTTP HEADERS FOR DISTRIBUTED AUTHORING............................47 8.1 DAV Header.....................................................47 8.2 Depth Header...................................................47 8.3 Destination Header.............................................48 8.4 If Header......................................................48 8.4.1 No-tag-list Production.......................................49 8.4.2 Tagged-list Production.......................................49 8.4.3 not Production...............................................50 8.4.4 Matching Function............................................50 - 8.4.5 If Header and Non-DAV Compliant Proxies......................50 + 8.4.5 If Header and Non-DAV Compliant Proxies ......................51 8.5 Lock-Token Request Header......................................51 8.6 Overwrite Header...............................................51 8.7 Status-URI Response Header.....................................51 8.8 Timeout Request Header.........................................52 + 9 STATUS CODE EXTENSIONS TO HTTP/1.1................................53 9.1 102 Processing.................................................53 9.2 207 Multi-Status...............................................53 9.3 422 Unprocessable Entity.......................................53 9.4 423 Locked.....................................................53 9.5 424 Method Failure.............................................53 9.6 425 Insufficient Space on Resource.............................53 -10 MULTI-STATUS RESPONSE............................................53 + +10 MULTI-STATUS RESPONSE ............................................54 + 11 XML ELEMENT DEFINITIONS..........................................54 -11.1 activelock XML Element.........................................54 +11.1 activelock XML Element ........................................54 11.1.1 depth XML Element...........................................54 11.1.2 locktoken XML Element.......................................54 11.1.3 timeout XML Element.........................................54 -11.2 collection XML Element.........................................55 -11.3 href XML Element...............................................55 -11.4 link XML Element...............................................55 +11.2 collection XML Element ........................................55 +11.3 href XML Element ..............................................55 +11.4 link XML Element ..............................................55 11.4.1 dst XML Element.............................................55 11.4.2 src XML Element.............................................55 -11.5 lockentry XML Element..........................................56 -11.6 lockinfo XML Element...........................................56 -11.7 lockscope XML Element..........................................56 +11.5 lockentry XML Element .........................................56 +11.6 lockinfo XML Element ..........................................56 +11.7 lockscope XML Element .........................................56 11.7.1 exclusive XML Element.......................................56 11.7.2 shared XML Element..........................................56 -11.8 locktype XML Element...........................................56 +11.8 locktype XML Element ..........................................56 11.8.1 write XML Element...........................................57 -11.9 multistatus XML Element........................................57 +11.9 multistatus XML Element .......................................57 11.9.1 response XML Element........................................57 11.9.2 responsedescription XML Element.............................58 -11.10 owner XML Element.............................................58 -11.11 prop XML element..............................................58 -11.12 propertybehavior XML element..................................58 +11.10 owner XML Element ............................................58 +11.11 prop XML element .............................................58 +11.12 propertybehavior XML element .................................59 11.12.1 keepalive XML element......................................59 11.12.2 omit XML element...........................................59 -11.13 propertyupdate XML element....................................59 +11.13 propertyupdate XML element ...................................60 11.13.1 remove XML element.........................................60 11.13.2 set XML element............................................60 -11.14 propfind XML Element..........................................60 - 11.14.1 allprop XML Element........................................60 +11.14 propfind XML Element .........................................60 + 11.14.1 allprop XML Element ........................................61 11.14.2 propname XML Element.......................................61 + 12 DAV PROPERTIES...................................................61 -12.1 creationdate Property..........................................61 -12.2 displayname Property...........................................61 -12.3 getcontentlanguage Property....................................61 -12.4 getcontentlength Property......................................62 -12.5 getcontenttype Property........................................62 -12.6 getetag Property...............................................62 -12.7 getlastmodified Property.......................................63 -12.8 lockdiscovery Property.........................................63 - 12.8.1 Example.....................................................63 -12.9 resourcetype Property..........................................64 -12.10 source Property...............................................64 - 12.10.1 Example....................................................65 -12.11 supportedlock Property........................................66 - 12.11.1 Example....................................................66 +12.1 creationdate Property .........................................61 +12.2 displayname Property ..........................................61 +12.3 getcontentlanguage Property ...................................62 +12.4 getcontentlength Property .....................................62 +12.5 getcontenttype Property .......................................62 +12.6 getetag Property ..............................................62 +12.7 getlastmodified Property ......................................63 +12.8 lockdiscovery Property ........................................63 + 12.8.1 Example - Retrieving the lockdiscovery Property .............63 +12.9 resourcetype Property .........................................64 +12.10 source Property ..............................................65 + 12.10.1 Example - A source Property ................................65 +12.11 supportedlock Property .......................................66 + 12.11.1 Example - Retrieving the supportedlock Property ............66 + 13 DAV XML PROCESSING INSTRUCTIONS..................................67 + 14 DAV COMPLIANCE CLASSES...........................................67 -14.1 Class 1........................................................67 -14.2 Class 2........................................................68 +14.1 Class 1 .......................................................68 +14.2 Class 2 .......................................................68 + 15 INTERNATIONALIZATION CONSIDERATIONS..............................68 + 16 SECURITY CONSIDERATIONS..........................................69 -16.1 Authentication of Clients......................................69 -16.2 Denial of Service..............................................70 -16.3 Security through Obscurity.....................................70 -16.4 Privacy Issues Connected to Locks..............................70 -16.5 Privacy Issues Connected to Properties.........................70 -16.6 Reduction of Security due to Source Link.......................71 +16.1 Authentication of Clients .....................................69 +16.2 Denial of Service .............................................70 +16.3 Security through Obscurity ....................................70 +16.4 Privacy Issues Connected to Locks .............................71 +16.5 Privacy Issues Connected to Properties ........................71 +16.6 Reduction of Security due to Source Link ......................71 + 17 IANA CONSIDERATIONS..............................................71 18 TERMINOLOGY......................................................72 -19 COPYRIGHT........................................................72 +19 COPYRIGHT ........................................................73 20 INTELLECTUAL PROPERTY............................................73 -21 ACKNOWLEDGEMENTS.................................................73 +21 ACKNOWLEDGEMENTS .................................................74 22 REFERENCES.......................................................75 +22.1 Normative References ..........................................75 +22.2 Informational References ......................................75 23 AUTHORS' ADDRESSES...............................................77 24 APPENDICES.......................................................78 -24.1 Appendix 1 - WebDAV Document Type Definition...................78 -24.2 Appendix 2 - ISO 8601 Date and Time Profile....................79 -24.3 Appendix 3 - Notes on Processing XML Elements..................80 - 24.3.1 XML Syntax Error Example....................................80 - 24.3.2 Unknown XML Element Example.................................81 -24.4 Appendix 4 -- XML Namespaces for WebDAV........................82 +24.1 Appendix 1 - WebDAV Document Type Definition ..................78 +24.2 Appendix 2 - ISO 8601 Date and Time Profile ...................79 +24.3 Appendix 3 - Notes on Processing XML Elements .................80 + 24.3.1 Notes on Empty XML Elements .................................80 + 24.3.2 Notes on Illegal XML Processing .............................80 +24.4 Appendix 4 -- XML Namespaces for WebDAV .......................82 24.4.1 Introduction................................................82 24.4.2 Namespace Declaration PI....................................83 - 24.4.3 Prolog with Namespace Declarations..........................83 - 24.4.4 Well-Formedness Constraint - Unique Namespace Names.........83 - 24.4.5 Qualified Names.............................................83 - 24.4.6 Well-Formedness Constraint - Namespace Name Declared........83 - 24.4.7 Using Qualified Names.......................................84 - 24.4.8 Element Names...............................................84 - 24.4.9 Scope and Meaning of Qualified Names........................84 + 24.4.3 Placing Declarations in Documents ...........................84 + 24.4.4 Prolog with Namespace Declarations ..........................84 + 24.4.5 Qualified Names .............................................84 + 24.4.6 Universal Names .............................................85 + 24.4.7 Using Qualified Names .......................................85 + 24.4.8 Processing instruction ......................................85 + 24.4.9 Scope and Meaning of Qualified Names ........................85 1 Introduction This document describes an extension to the HTTP/1.1 protocol that allows clients to perform remote web content authoring operations. This extension provides a coherent set of methods, headers, request entity body formats, and response entity body formats that provide operations for: Properties: The ability to create, remove, and query information @@ -451,48 +477,49 @@ 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. 4.1 Collection Resources - A collection is a resource whose state consists of an unordered list - of internal members and a set of properties. 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]. + 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 + 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]. 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. WebDAV servers MUST treat HTTP URL namespaces as collections, regardless of whether they were created with the MKCOL method described in section 7.3. 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 location header in the response pointing to the URL - ending with the "/". For example, if a client invokes a method on - http://foo.bar/blah (no trailing slash), the resource + SHOULD return a content-location header in the response pointing to + the URL 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 location header - with http://foo.bar/blah/ in it. In general clients SHOULD use the - "/" form of collection names. + 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. 4.2 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 format for a collection can readily be constructed for use with PUT, @@ -554,32 +581,31 @@ namespace. In fact, preventing access to the source resource(s) has desirable security benefits. However, if remote editing of the source resource(s) is desired, the source resource(s) should be given a location in the URI namespace. This source location should not be one of the locations at which the generated output is retrievable, since in general it is impossible for the server to differentiate requests for source resources from requests for process output resources. There is often a many-to-many relationship between source resources and output resources. - On WebDAV compliant servers, for all output resources which have a - single source resource (and that source resource has a URI), the URI - of the source resource may be stored in a link on the output - resource with type DAV:source (see section 12.10 for a description - of the source link property). Storing the source URIs in links on - the output resources places the burden of discovering the source on - the authoring client. Note that the value of a source link is not - guaranteed to point to the correct source. Source links may break - or incorrect values may be entered. Also note that not all servers - will allow the client to set the source link value. For example a - server which generates source links on the fly for its CGI files - will most likely not allow a client to set the source link value. + On WebDAV compliant servers the URI of the source resource(s) may be + stored in a link on the output resource with type DAV:source (see + section 12.10 for a description of the source link property). + Storing the source URIs in links on the output resources places the + burden of discovering the source on the authoring client. Note that + the value of a source link is not guaranteed to point to the correct + source. Source links may break or incorrect values may be entered. + Also note that not all servers will allow the client to set the + source link value. For example a server which generates source + links on the fly for its CGI files will most likely not allow a + client to set the source link value. 5 Locking The ability to lock a resource provides a mechanism for serializing access to that resource. Using a lock, an authoring client can provide a reasonable guarantee that another principal will not modify a resource while it is being edited. In this way, a client can prevent the "lost update" problem. This specification allows locks to vary over two client-specified @@ -655,22 +682,23 @@ others only provide support for exclusive write locks while yet others use no locking at all. As each system is sufficiently different to merit exclusion of certain locking features, this specification leaves locking as the sole axis of negotiation within WebDAV. 5.3 Lock Tokens A lock token is a type of state token, represented as a URI, which identifies a particular lock. A lock token is returned by every - successful LOCK operation in the Lock-Token response header, and can - also be discovered through lock discovery on a resource. + successful LOCK operation in the lockdiscovery property in the + response body, and can also be found through lock discovery on a + resource. Lock token URIs MUST be unique across all resources for all time. This uniqueness constraint allows lock tokens to be submitted across resources and servers without fear of confusion. This specification provides a lock token URI scheme called opaquelocktoken that meets the uniqueness requirements. However resources are free to return any URI scheme so long as it meets the uniqueness requirements. @@ -800,35 +828,41 @@ While those without a write lock may not alter a property on a resource it is still possible for the values of live properties to change, even while locked, due to the requirements of their schemas. Only dead properties and live properties defined to respect locks are guaranteed not to change while write locked. 6.3 Write Locks and Null Resources It is possible to assert a write lock on a null resource in order to - lock the name. A write locked null resource acts in all ways as a - null resource, except that it MUST respond to a PROPFIND request and - MUST support the lockdiscovery and supportedlock properties. + lock the name. - Until a method such as PUT or MKCOL is executed, the resource MUST - stay in the null state with the exception of the behavior described - above. + A write locked null resource, referred to as a lock-null resource, + MUST respond with a 404 Not Found or 405 Method Not Allowed to any + HTTP/1.1 or DAV methods except for PUT, MKCOL, OPTIONS, PROPFIND, + LOCK, and UNLOCK. A lock-null resource MUST appear as a member of + its parent collection. Additionally the lock-null resource MUST + have defined on it all mandatory DAV properties. Most of these + properties, such as all the get* properties, will have no value as a + lock-null resource does not support the GET method. Lock-Null + resources MUST have defined values for lockdiscovery and + supportedlock properties. - If the resource is unlocked without a PUT, MKCOL, or similar method - having been executed then the resource MUST return to its original - NULL state. + Until a method such as PUT or MKCOL is successfully executed on the + lock-null resource the resource MUST stay in the lock-null state. + However, once a PUT or MKCOL is successfully executed on a lock-null + resource the resources ceases to be in the lock-null state. - A return to a full NULL state is generally interpreted as meaning - that any attempt to execute a method on the resource will result in - a 404 Not Found. + 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. 6.4 Write Locks and Collections A write lock on a collection 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. @@ -862,21 +896,21 @@ from accidentally ignoring locks taken out by other programs with the same authorization. In order to prevent these collisions a lock token MUST be submitted by an authorized principal in the If header for all locked resources that a method may interact with or the method MUST fail. For example, if a resource is to be moved and both the source and destination are locked then two lock tokens must be submitted, one for the source and the other for the destination. -6.5.1 Write Lock Example +6.5.1 Example - Write Lock >>Request COPY /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html If: () >>Response @@ -985,54 +1019,53 @@ 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. 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. -7.1.1 Example: Retrieving Named Properties +7.1.1 Example - Retrieving Named Properties >>Request - PROPFIND /files/ HTTP/1.1 + PROPFIND /file HTTP/1.1 Host: www.foo.bar - Depth: 0 Content-type: text/xml Content-Length: xyz - - + + >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxxx - - + + - http://www.foo.bar/files/ + http://www.foo.bar/file Box type A J.J. Johnson HTTP/1.1 200 OK @@ -1042,54 +1075,53 @@ HTTP/1.1 403 Forbidden The user does not have access to the DingALing property. There has been an access violation error. - In this example, PROPFIND is executed on the collection - http://www.foo.bar/files/. The specified depth is zero, hence the - PROPFIND applies only to the collection itself, and not to any of - its members. The propfind XML element specifies the name of four - properties whose values are being requested. In this case only two - properties were returned, since the principal issuing the request - did not have sufficient access rights to see the third and fourth - properties. + In this example, PROPFIND is executed on a non-collection resource + http://www.foo.bar/file. The propfind XML element specifies the + name of four properties whose values are being requested. In this + case only two properties were returned, since the principal issuing + the request did not have sufficient access rights to see the third -7.1.2 Example: Using allprop to Retrieve All Properties + and fourth properties. + +7.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 Content-Length: xxxxx - + >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxxx - - + + http://www.foo.bar/container/ Box type A Hadrian @@ -1183,57 +1214,55 @@ "bigbox" property type), DAV:creationdate, DAV:displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock. The DAV-specific properties assert that "front.html" was created on December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT (creationdate), has a name of "Example HTML resource" (displayname), a content length of 4525 bytes (getcontentlength), a MIME type of "text/html" (getcontenttype), an entity tag of "zzyzx" (getetag), was last modified on Monday, January 12, 1998, at 09:25:56 GMT - (getlastmodified), has an undefined resource type, meaning that it - is not a collection (resourcetype), and supports both exclusive - write and shared write locks (supportedlock). + (getlastmodified), has an empty resource type, meaning that it is + not a collection (resourcetype), and supports both exclusive write + and shared write locks (supportedlock). -7.1.3 Example: Using propname to Retrieve all Property Names +7.1.3 Example - Using propname to Retrieve all Property Names >>Request PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Content-Type: text/xml Content-Length: xxxxx - - + >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxx - - + + http://www.foo.bar/container/ - HTTP/1.1 200 OK http://www.foo.bar/container/front.html @@ -1279,22 +1308,22 @@ body to set and/or remove properties defined on the resource identified by the Request-URI. All DAV compliant resources MUST support the PROPPATCH method and MUST process instructions that are specified using the propertyupdate, set, and remove XML elements of the DAV schema. Execution of the directives in this method is, of course, subject to access control constraints. DAV compliant resources SHOULD support the setting of arbitrary dead properties. - The request message body of a PROPPATCH method MUST contain at least - one propertyupdate XML element. Instruction processing MUST occur in + The request message body of a PROPPATCH method MUST contain the + propertyupdate XML element. Instruction processing MUST occur in the order instructions are received (i.e., from top to bottom). Instructions MUST either all be executed or none executed. Thus if any error occurs during processing all executed instructions MUST be undone and a proper error result returned. Instruction processing details can be found in the definition of the set and remove instructions in section 11.13. 7.2.1 Status Codes for use with Multi-Status The following are examples of response codes one would expect to be @@ -1313,54 +1341,56 @@ not appropriate for the property. This includes trying to set read- only properties. 423 Locked - The specified resource is locked and the client either is not a lock owner or the lock type requires a lock token to be submitted and the client did not submit it. 425 Insufficient Space on Resource - The server did not have sufficient space to record the property. -7.2.2 Example +7.2.2 Example - PROPPATCH >>Request PROPPATCH /bar.html HTTP/1.1 Host: www.foo.com Content-Type: text/xml Content-Length: xxxx - - + + Jim Whitehead Roy Fielding >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxxx - - + + http://www.foo.com/bar.html HTTP/1.1 424 Method Failure HTTP/1.1 409 Conflict @@ -1428,21 +1458,21 @@ 409 Conflict - A collection cannot be made at the Request-URI until one or more intermediate collections have been created. 415 Unsupported Media Type- The server does not support the request type of the body. 425 Insufficient Space on Resource - The resource does not have sufficient space to record the state of the resource after the execution of this method. -7.3.3 Example +7.3.3 Example - MKCOL This example creates a collection called /webdisc/xfiles/ on the server www.server.org. >>Request MKCOL /webdisc/xfiles/ HTTP/1.1 Host: www.server.org >>Response @@ -1496,54 +1526,53 @@ resource to be deleted. When the DELETE method has completed processing it MUST return 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 Method Failure 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 Content is the default success code. -7.6.2.1 Example +7.6.2.1 Example - DELETE >>Request DELETE /container/ HTTP/1.1 Host: www.foo.bar >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxxx - + http://www.foo.bar/container/resource3 HTTP/1.1 423 Locked In this example the attempt to delete http://www.foo.bar/container/resource3 failed because it is locked, and no lock token was submitted with the request. Consequently, the attempt to delete http://www.foo.bar/container/ also failed. Thus the client knows that the attempt to delete - http://ww.foo.bar/container/ must have also failed since the parent + http://www.foo.bar/container/ must have also failed since the parent can not be deleted unless its child has also been deleted. Even though a Depth header has not been included, a depth of infinity is assumed because the method is on a collection. 7.7 PUT 7.7.1 PUT for Non-Collection Resources A PUT performed on an existing resource replaces the GET response entity of the resource. Properties defined on the resource may be @@ -1698,80 +1726,80 @@ 423 Locked - The destination resource was locked. 425 Insufficient Space on Resource - The destination resource does not have sufficient space to record the state of the resource after the execution of this method. 502 Bad Gateway - This may occur when the destination is on another server and the destination server refuses to accept the resource. -7.8.6 Overwrite Example +7.8.6 Example - COPY with Overwrite This example shows resource http://www.ics.uci.edu/~fielding/index.html being copied to the location http://www.ics.uci.edu/users/f/fielding/index.html. The 204 No Content status code indicates the existing resource at the destination was overwritten. >>Request COPY /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html >>Response HTTP/1.1 204 No Content -7.8.7 No Overwrite Example +7.8.7 Example - COPY with No Overwrite The following example shows the same copy operation being performed, but with the Overwrite header set to "F." A response of 412 Precondition Failed is returned because the destination resource has a non-null state. >>Request COPY /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html Overwrite: F >>Response HTTP/1.1 412 Precondition Failed -7.8.8 Collection Example +7.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 Content-Length: xxxxx - + * >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxxx - + 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 collection is to act as if a "Depth: infinity" header had been submitted. In this example most of the resources, along with the @@ -1870,68 +1898,68 @@ 412 Precondition Failed - The server was unable to maintain the liveness of the properties listed in the propertybehavior XML element or the Overwrite header is "F" and the state of the destination resource is non-null. 423 Locked - The source or the destination resource was locked. 502 Bad Gateway - This may occur when the destination is on another server and the destination server refuses to accept the resource. -7.9.5 Non-Collection Example +7.9.5 Example - MOVE of a Non-Collection This example shows resource http://www.ics.uci.edu/~fielding/index.html being moved to the location http://www.ics.uci.edu/users/f/fielding/index.html. The contents of the destination resource would have been overwritten if the destination resource had been non-null. In this case, since there was nothing at the destination resource, the response code is 201 Created. >>Request MOVE /~fielding/index.html HTTP/1.1 Host: www.ics.uci.edu Destination: http://www.ics.uci.edu/users/f/fielding/index.html >>Response HTTP/1.1 201 Created - Location: http://www.ics.uci.edu/users/f/fielding/index.html + Content-Location: http://www.ics.uci.edu/users/f/fielding/index.html -7.9.6 Collection Example +7.9.6 Example - MOVE of a Collection >>Request MOVE /container/ HTTP/1.1 Host: www.foo.bar Destination: http://www.foo.bar/othercontainer/ Overwrite: F If: () () Content-Type: text/xml Content-Length: xyz - + * >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: zzz - + 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 @@ -2021,41 +2049,35 @@ lock type. However, independent of lock type, a successful DELETE of a resource MUST cause all of its locks to be removed. 7.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. *=if the principal requesting the lock is the owner of the - lock, the lock must be refreshed. + 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 the lock must not be granted. - If an exclusive or shared lock is re-requested by the principal who - owns the lock, the lock MUST be refreshed. - 7.10.7 Status Codes 200 Success - The lock request succeeded and the value of the lockdiscovery property is included in the body. 412 Precondition Failed - The included lock token was not enforceable on this resource or the server could not satisfy the request in the lockinfo XML element. 423 Locked - The resource is locked, so the method has been @@ -2069,23 +2091,22 @@ Host: webdav.sb.aol.com Timeout: Infinite, Second-4100000000 Content-Type: text/xml Content-Length: xyz 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 200 OK @@ -2086,21 +2107,21 @@ >>Response HTTP/1.1 200 OK Content-Type: text/xml Content-Length: xxxxx - + Infinity http://www.ics.uci.edu/~ejw/contact.html @@ -2137,21 +2158,21 @@ uri="/workspace/webdav/proposal.doc", response="...", opaque="..." >>Response HTTP/1.1 200 OK Content-Type: text/xml Content-Length: xxxxx - + Infinity http://www.ics.uci.edu/~ejw/contact.html @@ -2178,76 +2199,85 @@ LOCK /webdav/ HTTP/1.1 Host: webdav.sb.aol.com Timeout: Infinite, Second-4100000000 Depth: infinity 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 Content-Length: xxxxx - + http://webdav.sb.aol.com/webdav/secret HTTP/1.1 403 Forbidden + + http://webdav.sb.aol.com/webdav/ + + + HTTP/1.1 424 Method Failure + + - This example shows a request for an exclusive write lock on a collection and all its children. In this request, the client has specified that it desires an infinite length lock, if available, otherwise a timeout of 4.1 billion seconds, if available. The request entity body contains the contact information for the principal taking out the lock, in this case a web page URL. The error is a 403 Forbidden response on the resource http://webdav.sb.aol.com/webdav/secret. Because this resource could - not be locked, none of the resources were locked. + not be locked, none of the resources were locked. Note also that + the lockdiscovery property for the Request-URI has been included as + required. In this example the lockdiscovery property is empty which + means that there are no outstanding locks on the resource. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header. 7.11 UNLOCK Method The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header from the Request-URI, and all other resources included in the lock. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail. Any DAV compliant resource which supports the LOCK method MUST support the UNLOCK method. -7.11.1 Example +7.11.1 Example - UNLOCK >>Request UNLOCK /workspace/webdav/info.doc HTTP/1.1 Host: webdav.sb.aol.com - Lock-Token: () + Lock-Token: Authorization: Digest username="ejw", realm="ejw@webdav.sb.aol.com", nonce="...", uri="/workspace/webdav/proposal.doc", response="...", opaque="..." >>Response HTTP/1.1 204 No Content In this example, the lock identified by the lock token @@ -2258,24 +2288,25 @@ resources included in the lock. The 204 status code is used instead of 200 OK because there is no response entity body. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header. 8 HTTP Headers for Distributed Authoring 8.1 DAV Header - DAV = "DAV" ":" "1" [",2"] ["," 1#extend] + DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend] This header indicates that the resource supports the DAV schema and protocol as specified. All DAV compliant resources MUST return the + DAV header on all OPTIONS responses. The value is a list of all compliance classes that the resource supports. Note that above a comma has already been added to the 2. This is because a resource can not be level 2 compliant unless it is also level 1 compliant. Please refer to section 14 for more details. In general, however, support for one compliance class does not entail support for any other. 8.2 Depth Header @@ -2367,28 +2398,29 @@ The If header's purpose is to describe a series of state lists. If the state of the resource to which the header is applied does not match any of the specified state lists then the request MUST fail with a 412 Precondition Failed. If one of the described state lists matches the state of the resource then the request may succeed. 8.4.1 No-tag-list Production The No-tag-list production describes a series of state tokens and e- tags. If multiple No-tag-list productions are used then only one + needs to match the state of the resource for the method to be allowed to continue. If a method, due to the presence of a Depth or Destination header, is applied to multiple resources then the No-tag-list production MUST be applied to each resource the method is applied to. - For example: +8.4.1.1 Example - No-tag-list If Header If: ( ["I am an e-tag"]) (["I am another e-tag"]) The previous header would require that any resources within the scope of the method must either be locked with the specified lock token and in the state identified by the "I am an e-tag" e-tag or in the state identified by the second e-tag "I am another e-tag". To put the matter more plainly one can think of the previous If header as being in the form (or (and ["I am @@ -2408,21 +2440,21 @@ resources match the operand resource(s) for the current method. If none of the resource productions match the current resource then the header MUST be ignored. If one of the resource productions does match the name of the resource under consideration then the list productions following the resource production MUST be applied to the resource in the manner specified in the previous section. The same URI MUST NOT appear more than once in a resource production in an If header. - For example: +8.4.2.1 Example - Tagged List If header COPY /resource1 HTTP/1.1 Host: www.foo.bar Destination: http://www.foo.bar/resource2 If: ( [W/"A weak e-tag"]) (["strong e-tag"]) (["another strong e-tag"]) In this example http://www.foo.bar/resource1 is being copied to http://www.foo.bar/resource2. When the method is first applied to @@ -2604,23 +2635,23 @@ was unable to process the contained instructions. 9.4 423 Locked The source or destination resource of a method is locked. 9.5 424 Method Failure The method was not executed on a particular resource within its scope because some part of the method's execution failed causing the - entire method to be aborted. For example, if a resource could not - be moved as part of a MOVE method, all the other resources would - fail with a 424 Method Failure. + entire method to be aborted. For example, if a command in a + PROPPATCH method fails then, at minimum, the rest of the commands + will also fail with 424 Method Failure. 9.6 425 Insufficient Space on Resource The resource does not have sufficient space to record the state of the resource after the execution of this method. 10 Multi-Status Response The default 207 Multi-Status response body is a text/xml HTTP entity that contains a single XML element called multistatus, which @@ -2658,21 +2689,21 @@ 11.1.2 locktoken XML Element Name: locktoken Namespace: DAV: Purpose: The lock token associated with a lock. Description: The href contains one or more opaque lock token URIs which all refer to the same lock (i.e., the OpaqueLockToken-URI production in section 5.4). - + 11.1.3 timeout XML Element Name: timeout Namespace: DAV: Purpose: The timeout associated with a lock Value: TimeType ;Defined in section 8.8 @@ -2817,25 +2850,26 @@ 11.9.1.1 propstat XML Element Name: propstat Namespace: DAV: Purpose: Groups together a prop and status element that is associated with a particular href element. - Description: The propstat XML element MUST contain one or more empty - prop XML elements representing the names of properties. Multiple - properties may be included if the same response applies to them all. + Description: The propstat XML element MUST contain one prop XML + element and one status XML element. The contents of the prop XML + element MUST only list the names of properties to which the result + in the status element applies. - + 11.9.1.2 status XML Element Name: status Namespace: DAV: Purpose: Holds a single HTTP status-line Value: status-line ;status-line defined in [Fielding et al., 1997] @@ -3121,42 +3150,43 @@ Purpose: Describes the active locks on a resource Description: The lockdiscovery property returns a listing of who has a lock, what type of lock he has, the timeout type and the time remaining on the timeout, and the associated lock token. The server is free to withhold any or all of this information if the requesting principal does not have sufficient access rights to see the requested data. -12.8.1 Example +12.8.1 Example - Retrieving the lockdiscovery Property >>Request PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Content-Length: xxxx Content-Type: text/xml - + + >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxxx - + http://www.foo.bar/container/ 0 @@ -3187,36 +3218,36 @@ compliant resources. The default value is empty. 12.10 source Property Name: source Namespace: DAV: Purpose: The destination of the source link identifies the resource that contains the unprocessed source of the link's source. - Description: The source of the link (src) is typically the URI of the output resource on which the link is defined, and there is typically only one destination (dst) of the link, which is the URI where the unprocessed source of the resource may be accessed. When more than one link destination exists, this specification asserts no policy on ordering. -12.10.1 Example +12.10.1 Example - A source Property - - + + + Source http://foo.bar/program http://foo.bar/src/main.c Library http://foo.bar/program http://foo.bar/src/main.lib @@ -3246,48 +3277,46 @@ Name: supportedlock Namespace: DAV: Purpose: To provide a listing of the lock capabilities supported by the resource. Description: The supportedlock property of a resource returns a listing of the combinations of scope and access types which may be specified in a lock request on the resource. Note that the actual contents are themselves controlled by access controls so a server is not required to provide information the client is not authorized to - see. -12.11.1 Example +12.11.1 Example - Retrieving the supportedlock Property >>Request PROPFIND /container/ HTTP/1.1 Host: www.foo.bar Content-Length: xxxx Content-Type: text/xml - + - >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: xxxxx - + http://www.foo.bar/container/ @@ -3568,27 +3597,32 @@ Live Property - A property whose semantics and syntax are enforced by the server. For example, a live "content-length" property would have its value, the length of the entity returned by a GET request, automatically calculated by the server. Dead Property - A property whose semantics and syntax are not enforced by the server. The server only records the value of a dead property; the client is responsible for maintaining the consistency of the syntax and semantics of a dead property. + Null Resource - A resource which responds with a 404 Not Found to + any HTTP/1.1 or DAV method except for PUT, MKCOL, OPTIONS and LOCK. + A NULL resource MUST NOT appear as a member of its parent + collection. + 19 Copyright The following copyright notice is copied from RFC 2026 [Bradner, 1996], section 10.4, and describes the applicable copyright for this document. - Copyright (C) The Internet Society March 6, 1998. All Rights + Copyright (C) The Internet Society April 5, 1998. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other @@ -3635,64 +3668,60 @@ this standard. Please address the information to the IETF Executive Director. 21 Acknowledgements A specification such as this thrives on piercing critical review and withers from apathetic neglect. The authors gratefully acknowledge the contributions of the following people, whose insights were so valuable at every stage of our work. - Terry Allen, Harald Alvestrand, Alan Babich, 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, Roy - Fielding, Mark Fisher, Alan Freier, George Florentine, Jim Gettys, - Phill Hallam-Baker, Dennis Hamilton, Steve Henning, Alex Hopmann, - Andre van der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen - MacArthur, Steven Martin, Larry Masinter, Michael Mealling, Keith - Moore, Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon - Radoff, Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith - Slein, Mike Spreitzer, Einar Stefferud, Ralph Swick, Kenji - Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar - Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and Lauren Wood. + 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, 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. We would also like to thank John Turner for developing the XML DTD. 22 References +22.1 Normative References + [Alvestrand, 1995] H. T. Alvestrand, "Tags for the Identification of Languages." RFC 1766. Uninett. March, 1995. [Alvestrand, 1998] H. T. Alvestrand, "IETF Policy on Character Sets and Languages." RFC 2277, BCP 18. Uninett. January, 1998. - [Bradner, 1996] S. Bradner, "The Internet Standards Process - - Revision 3." RFC 2026, BCP 9. Harvard University. October, 1996. - [Bradner, 1997] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, BCP 14. Harvard University. March, 1997. - [Bray, Hollander, Layman, 1998] T. Bray, D. Hollander, A. Layman, - "Name Spaces in XML" World Wide Web Consortium Note, - http://www.w3.org/TR/1998/NOTE-xml-names. - [Bray, Paoli, Sperberg-McQueen, 1998] T. Bray, J. Paoli, C. M. Sperberg-McQueen, "Extensible Markup Language (XML)." World Wide Web Consortium Recommendation REC-xml-19980210. http://www.w3.org/TR/1998/REC-xml-19980210. [Franks et al., 1997] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, and L. Stewart. "An Extension to HTTP : Digest Access Authentication" RFC 2069. Northwestern University, CERN, Spyglass Inc., Microsoft Corp., Netscape Communications Corp., Spyglass Inc., Open Market Inc. January 1997. @@ -3701,49 +3730,58 @@ Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." RFC 2068. U.C. Irvine, DEC, MIT/LCS. January, 1997. [ISO-639] ISO (International Organization for Standardization). ISO 639:1988. "Code for the representation of names of languages." [ISO-8601] ISO (International Organization for Standardization). ISO 8601:1988. "Data elements and interchange formats - Information interchange - Representation of dates and times." - [Lasher, Cohen, 1995] R. Lasher, D. Cohen, "A Format for - Bibliographic Records," RFC 1807. Stanford, Myricom. June, 1995. - [Leach, Salz, 1998] P. J. Leach, R. Salz, "UUIDs and GUIDs." Internet-draft, work-in-progress, February, 1998. ftp://ietf.org/internet-drafts/draft-leach-uuids-guids-01.txt + [Yergeau, 1998] F. Yergeau, "UTF-8, a transformation format of + Unicode and ISO 10646." RFC 2279. Alis Technologies. January, 1998. + +22.2 Informational References + + [Bradner, 1996] S. Bradner, "The Internet Standards Process - + Revision 3." RFC 2026, BCP 9. Harvard University. October, 1996. + + [Bray, Hollander, Layman, 1998] T. Bray, D. Hollander, A. Layman, + "Name Spaces in XML" World Wide Web Consortium Working Draft, + http://www.w3.org/TR/WD-xml-names. + + [Lasher, Cohen, 1995] R. Lasher, D. Cohen, "A Format for + Bibliographic Records," RFC 1807. Stanford, Myricom. June, 1995. + [MARC, 1994] Network Development and MARC Standards, Office, ed. 1994. "USMARC Format for Bibliographic Data", 1994. Washington, DC: Cataloging Distribution Service, Library of Congress. [Miller et al., 1996] J. Miller, T. Krauskopf, P. Resnick, W. Treese, "PICS Label Distribution Label Syntax and Communication Protocols" Version 1.1, World Wide Web Consortium Recommendation REC-PICS-labels-961031. http://www.w3.org/pub/WWW/TR/REC-PICS- labels-961031.html. [Slein et al., 1998] J. A. Slein, F. Vitali, E. J. Whitehead, Jr., D. Durand, "Requirements for Distributed Authoring and Versioning Protocol for the World Wide Web." RFC 2291. Xerox, Univ. of Bologna, U.C. Irvine, Boston Univ. February, 1998. [Weibel et al., 1995] S. Weibel, J. Godby, E. Miller, R. Daniel, "OCLC/NCSA Metadata Workshop Report." http://purl.oclc.org/metadata/dublin_core_report. - [Yergeau, 1998] F. Yergeau, "UTF-8, a transformation format of - Unicode and ISO 10646." RFC 2279. Alis Technologies. January, 1998. - 23 Authors' Addresses Y. Y. Goland Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Email: yarong@microsoft.com E. J. Whitehead, Jr. Dept. Of Information and Computer Science @@ -3796,34 +3834,34 @@ - + - + @@ -3881,270 +3920,346 @@ subtracting the offset from the local time. For example, 18:50:00- 04:00 is the same time as 22:58:00Z. If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs from an offset of "Z" which implies that UTC is the preferred reference point for the specified time. 24.3 Appendix 3 - Notes on Processing XML Elements +24.3.1 Notes on Empty XML Elements + + XML supports two mechanisms for indicating that an XML element does + not have any content. The first is to declare an XML element of the + form . The second is to declare an XML element of the form + . The two XML elements are semantically identical. + + It is a violation of the XML specification to use the form + if the associated DTD declares the element to be EMPTY (e.g., + ). If such a statement is included, then the + empty element format, must be used. If the element is not + delcared to be EMPTY, then either form or may be used + for empty elements. + +24.3.2 Notes on Illegal XML Processing + XML is a flexible data format that makes it easy to submit data that appears legal but in fact is not. The philosophy of "Be flexible in what you accept and strict in what you send" still applies, but it must not be applied inappropriately. XML is extremely flexible in dealing with issues of white space, element ordering, inserting new elements, etc. This flexibility does not require extension, especially not in the area of the meaning of elements. There is no kindness in accepting illegal combinations of XML elements. At best it will cause an unwanted result and at worst it can cause real damage. -24.3.1 XML Syntax Error Example +24.3.2.1 Example - XML Syntax Error The following request body for a PROPFIND method is illegal. - + - The definition of the propfind element only allows for the allprop or the propname element, not both. Thus the above is an error and must be responded to with a 400 Bad Request. Imagine, however, that a server wanted to be "kind" and decided to pick the allprop element as the true element and respond to it. A client running over a bandwidth limited line who intended to execute + a propname would be in for a big surprise if the server treated the command as an allprop. Additionally, if a server were lenient and decided to reply to this request, the results would vary randomly from server to server, with some servers executing the allprop directive, and others executing the propname directive. This reduces interoperability rather than increasing it. -24.3.2 Unknown XML Element Example +24.3.2.2 Example - Unknown XML Element The previous example was illegal because it contained two elements that were explicitly banned from appearing together in the propfind element. However, XML is an extensible language, so one can imagine new elements being defined for use with propfind. Below is the request body of a PROPFIND and, like the previous example, must be rejected with a 400 Bad Request by a server that does not understand the expired-props element. - - + + To understand why a 400 Bad Request is returned let us look at the request body as the server unfamiliar with expired-props sees it. - - + + As the server does not understand the expired-props element, by the rules of XML, it must ignore it. Thus the server sees an empty propfind, which by the definition of the propfind element is illegal. Please note that had the extension been additive it would not necessarily have resulted in a 400 Bad Request. For example, imagine the following request body for a PROPFIND: - - + + *boss* The previous example contains the fictitious element leave-out. Its purpose is to prevent the return of any property whose name matches the submitted pattern. If the previous example were submitted to a server unfamiliar with leave-out, the only result would be that the leave-out element would be ignored and a propname would be executed. 24.4 Appendix 4 -- XML Namespaces for WebDAV - [NOTE TO RFC EDITOR: If, as expected, the World Wide Web Consortium - issues XML namespaces as a W3C Recommendation before this document - is published as an RFC (i.e., after approval by the IESG, but before - appearing in the rfc directory), then the text of this appendix must - be changed to read: - - XML namespace functionality in this specification MUST conform to - W3C Recommendation, "Name Spaces in XML" REC-XML-NAMES-1998????. - ] - 24.4.1 Introduction To provide a unique space of XML element names which has decentralized extensibility, this specification uses a feature of XML known as XML "namespaces". This appendix provides a normative reference for XML namespace functionality for implementations of this specification. All DAV compliant systems MUST support the XML - namespace extension as specified in this appendix." + namespace extension as specified in this appendix. The remainder of this appendix is intended to match, as closely as - needed, the text in Note-xml-names-19980119, "Name Spaces in XML", - edited by Tim Bray, Dave Hollander, and Andrew Layman, - http://www.w3.org/TR/1998/NOTE-xml-names. To meet this goal, the - text in this appendix is mostly quoted verbatim from this source. - As future drafts of the XML namespace proposal are generated, this - appendix will be updated. To ensure this appendix reflects the - exact XML namespace proposal, the notational conventions and BNF - productions in this appendix match those of the XML specification - [Bray, Paoli, Sperberg-McQueen, 1998]. + needed, the text in WD-xml-names-19980327, "Namespaces in XML", + edited by Tim Bray, Dave Hollander, and Andrew Layman [Bray, + Hollander, Layman, 1998]. To meet this goal, the text in this + appendix is mostly quoted verbatim from that source. The notational + conventions and BNF productions in this appendix match those of the + XML specification [Bray, Paoli, Spreberg-McQueen, 1998] - XML Namespaces are based on the use of qualified names. Names are - permitted to contain a colon, separating the name into two parts, - the namespace name and the local name. The namespace name identifies - a schema's URI. The combination of the universally-managed URI - namespace and the local schema namespace produces names that are - guaranteed universally unique. + XML namespaces are based on the use of qualified names, which + contain a single colon, separating the name into a namespace prefix + and the local name. The prefix, which is mapped to a URI, selects a + namespace. The combination of the universally-managed URI namespace + and the local schema namespace produces names that are guaranteed + universally unique. - XML syntax does not allow direct use of a URI as a namespace name, - because URIs can contain characters not allowed in XML element - names. Consequently, the namespace name serves as a proxy for a URI. - A special processing instruction described below is used to declare - the association of the namespace name with a URI; software that - supports this namespace proposal MUST recognize and act on namespace - processing instructions. + URIs can contain characters not allowed in names, and so cannot be + used directly as namespace prefixes. Therefore, the namespace + prefix serves as a proxy for a URI. A special processing + instruction described below is used to declare the association of + the namespace prefix with a URI; software which supports this + namespace proposal must recognize and act on it. - A namespace is declared using a reserved processing instruction. + A namespace is declared using a reserved processing instruction as + follows: 24.4.2 Namespace Declaration PI - [1] NamespacePI ::= '' - [2] NSName ::= ' Name ' | " Name " + [1] NamespacePI ::= '' [ NSC: Required Parts ] + [2] NSDef ::= 'ns' Eq SystemLiteral [ NSC: No Fragments ] + [3] SrcDef ::= 'src' Eq SystemLiteral + [4] PrefixDef ::= 'prefix' Eq ("'" NCName "'" | '"' NCName '"') + [5] NCName ::= (Letter | '_') (NCNameChar)* /* An XML Name, minus + the ":" */ + [6] NCNameChar ::= Letter | Digit | '.' | '-' | '_' | + CombiningChar | Extender - The "name" SystemLiteral is a URI which uniquely identifies the - namespace. The "href" SystemLiteral is an optional URI which may be - used to retrieve the schema, if one is provided. Some namespaces + [Definition:] The SystemLiteral in the NSDef production is a URI + which functions as a namespace name to identify the namespace. The + SystemLiteral in the SrcDef production is an optional URI which may + be used to retrieve the schema, if one is provided. Some namespaces need no schemas; this specification does not depend on their existence, or on the use of any particular machine- or human- readable syntax in the schema. - The NSName gives the namespace name which will be used as a link to - associate names in an XML document with this schema. + [Definition:] The NCName in the PrefixDef production gives the + namespace prefix used to associate names in an XML document with + this namespace. - To accomplish this, the production for prolog is replaced as - follows: + Namespace Constraint: Required Parts -24.4.3 Prolog with Namespace Declarations + A namespace declaration must contain exactly one NSDef, exactly one + PrefixDef and zero or one SrcDef. - [3] prolog ::= XMLDecl? S? NamespacePI* Misc* (doctypedecl Misc*)? - [ wfc: Unique Namespace Names ] + Namespace Constraint: No Fragments -24.4.4 Well-Formedness Constraint - Unique Namespace Names + The SystemLiteral in the NSDef production must contain a URI, not + including an attached #-separated fragment identifier. - No namespace name may be declared more than once. + The namespace name, to serve its intended purpose, should have the + characteristics of uniqueness and persistence. It is not a goal + that it be directly usable for retrieval of a schema (if any + exists). + +24.4.2.1 Examples of namespace declarations: + + + + + +24.4.3 Placing Declarations in Documents + + Namespace declarations must be located in the prolog of an XML + document, after the XML Declaration (if any) and before the DTD (if + any). This effectively makes the scope of namespace prefixes global + to the whole document, including the DTD. It also means that should + a processor wish to insert its own qualified names, it need only + read the namespace declarations from the prolog to be sure of + generating a new, unique, namespace prefix. + + In XML documents conforming to this specification, the prolog must + match the following production: + +24.4.4 Prolog with Namespace Declarations + + [7] prolog ::= XMLDecl? (NamespacePI | Misc)* (doctypedecl Misc*)? + [ NSC: Unique Prefix ] + + Note that the namespace declarations are ordinary processing + instructions which the XML processor will pass to the application as + it does any other. + + Namespace Constraint: Unique Prefix + + A namespace prefix may not be declared more than once; i.e. there + may not be two PrefixDefs which contain the same NCName string. 24.4.5 Qualified Names - Within the document, some names (constructs corresponding to the - nonterminal Name) are replaced by qualified names, defined as - follows: + [Definition:] In XML documents conforming to this specification, + some names (constructs corresponding to the nonterminal Name) may be + given as qualified names, defined as follows: - [4] QName ::= (NSPart ':')? LocalPart - [5] NSPart ::= Name [ wfc: Namespace Name Declared ] - [6] LocalPart ::= Name + Qualified Name - The NSPart provides the namespace name part of the qualified name, - and may be associated with defining schema through the URI in the + [8] QName ::= (Prefix ':')? LocalPart + [9] Prefix ::= NCName [ NSC: Prefix Declared ] + [10] LocalPart ::= NCName + + The Prefix provides the namespace prefix part of the qualified name, + and must be associated with defining schema through the URI in the applicable namespace declaration. - The LocalPart provides the local name part of the qualified name. + [Definition:] The LocalPart provides the local name part of the + qualified name. -24.4.6 Well-Formedness Constraint - Namespace Name Declared + Namespace Constraint: Prefix Declared - The namespace name, unless it is "xml", must have been declared in a - namespace declaration. The namespace name xml is reserved, and - considered to have been implicitly declared. + The namespace prefix, unless it is "xml", must have been declared in + a namespace declaration. The namespace prefix xml is reserved and + considered to have been implicitly declared. No other prefix + beginning with the three-letter sequence x m, l, in any case + combination, is allowed. + +24.4.6 Universal Names + + [Definition:] For each qualified name, there is a corresponding + universal name, which is an ordered pair containing first, the + namespace name associated with its prefix, and second, its local + name. + + A universal name is independent of the prefix in use in any + particular XML document; thus, universal names provide a basis for + comparing named objects located in different XML documents. 24.4.7 Using Qualified Names - To enable the proper use of qualified names, it is necessary to - banish colons from all Names which are not qualified; two - productions are replaced as follows: + In XML documents conforming to this specification, element types are + given as qualified names, as follows. In the productions below, the + nonterminals (STag, ETag, EmptyElement, and Attribute) are taken + from the XML specification [XML]; the productions in all cases match + a subset of the strings matched by those of the same name in the XML + spec. - [7] Name ::= (Letter | '_' ) (NameChar)* - [8] MiscName ::= '.' | '-' | '_' | CombiningChar | Ignorable | - Extender + Start-tag + [11] STag ::= '<' QName (S Attribute)* S? '>' + [12] ETag ::= '' + [13] EmptyElement ::= '<' QName (S Attribute)* S? '/>' -24.4.8 Element Names +24.4.8 Processing instruction - Element types may be given as qualified names. To do this, the - productions for start-, end-, and empty-element tags (STag, ETag, - and EmptyElement) are replaced as follows: + Targets are given as qualified names, as follows: - [9] STag ::= '<' QName (S Attribute)* S? '>' - [10] ETag ::= '' - [11] EmptyElement ::= '<' QName (S Attribute)* S? '/>' + PI Target + + [15] PITarget ::= QName [ NSC: Declare Before Use ] + + Namespace Constraint: Declare Before Use + + When a PI target, aside from that in a namespace declaration PI, is + qualified with a prefix, that prefix must be declared at a location + in the document which precedes its use. 24.4.9 Scope and Meaning of Qualified Names - [Note to the reader: This section does not appear in NOTE-xml-names, - but is necessary to avoid ambiguity for WebDAV XML processors.] + [Note to the reader: This section does not appear in [Bray, + Hollander, Layman, 1998], but is necessary to avoid ambiguity for + WebDAV XML processors.] WebDAV compliant XML processors MUST interpret a qualified name as a URI constructed by appending the LocalPart to the schema URI of the namespace. The scope of a namespace in a qualified name is limited to a single element tag. Every start tag, end tag, or empty XML element from a namespace MUST include the namespace name in the tag. Scope Example - + Johnny Updraft In this example, the qualified element name "del:glider" is interpreted as the URL "http://www.del.jensen.org/glider". Since the scope of a namespace is limited to a single element, each start tag, end tag, and empty element tag in the example includes the short name of the namespace, "del" as part of the qualified name. - + Johnny Updraft Even though this example is syntactically different from the previous example, it is semantically identical. Each instance of the namespace name "bar" is replaced with "http://www.del.jensen.org/" and then appended to the local name for each element tag. The resulting tag names in this example are exactly the same as for the previous example. - + Johnny Updraft This example is semantically identical to the two previous ones. Each instance of the namespace name "foo" is replaced with "http://www.del.jensen.org/glide" which is then appended to the