--- draft-ietf-webdav-rfc2518bis-latest.xml 2011-04-02 22:11:45.979133800 +0100 +++ draft-reschke-webdav-rfc2518bis-latest.xml 2011-04-02 22:13:16.371303900 +0100 @@ -5,9 +5,11 @@ + + + - - + @@ -28,7 +30,7 @@ - + Applications WebDAV webdav @@ -48,10 +50,248 @@ + + + + This is an experimental edit of the WebDAV working group's draft (as of + 2007-02-15), see for + details. All changes have been made by Julian Reschke; if a problem was + introduced by these changes, please blame Julian Reschke () + and not the authors of the working group draft. A + diff to the latest WG draft can be found at . + + + + + + + XML extensibility description. + + + + + + LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER. + + + + + + SHOULD_A_SERVER_DETERMINE_MIMETYPE_OF_CONTENT. + + + + + + EVALUATE_ALL_OF_IF_HEADER. + + + + + + Date header required? + + + + + + "PROPFIND status codes" section. + + + + + + DAV:error element. + + + + + + Move description of lock-null resources into appendix. + + + + + + Spec inconsistent on PROPFIND/Depth:infinity. + + + + + + GULP integration. + + + + + + Do status codes belong into pre/postcondition definitions? + + + + + + Collection state definition in conflict between BIND and RFC2518bis. + + + + + + GULP / Lock timeout discussion. + + + + + + Inconsistent requirements for dead properties. + + + + + + New attack scenario based on XmlHttpRequest object. + + + + + + PROPPATCH response format. + + + + + + Non-implementable requirements on DAV:getcontentlength. + + + + + + Update REC-XML and REC-XML-NAMES references. + + + + + + Inconsistency between PUT and DAV:getcontenttype. + + + + + + Questionable requirement on client behaviour after lock-null. + + + + + + Useless statement about 414 status. + + + + + + Incorrect description of "owner" element. + + + + + + DAV:getlastmodified description containing confusing statement. + + + + + + Statements about "local" COPY/MOVE operations. + + + + + + Incorrect statement about LWS handling. + + + + + + Misleading statement about MKCOL status code 415. + + + + + + Incorrect and confusing language in 9.10.1. + + + See also Erratum 1207. + + + + + + Inconsistent LNR requirements. + + + + + + Misleading statement about shared locks. + + + + + + Remove redundancy between 10.1 and 18. + + + + + + Updates 3253 (DAV:error) + + + + + + locking notifications underspecified + + + + + + Security considerations wrt to lock discovery. + + + + + + IANA:add RFC refs for registration procedures and register status codes. + + + + + + PROPFIND depth > 0 must be allowed to skip members. + + + + + + Umbrella issue for editorial fixes. + + + + + + Umbrella issue for WGLC issues. + + +
@@ -101,10 +341,17 @@ These abstractions are manipulated by the + WebDAV-specific HTTP methods and the extra HTTP headers used with WebDAV methods. General considerations for handling HTTP requests and responses in WebDAV are found in . + + WebDAV-specific HTTP methods and the newextra HTTP headers, defined in + (generic method handling), + (method definitions) and + (header definitions). + While the status codes provided by HTTP/1.1 are sufficient to @@ -123,9 +370,9 @@ WebDAV uses XML () for property names and some values, and also uses XML to marshal complicated requests and responses. This specification contains DTD and text definitions of all all properties - and all other XML elements used in marshalling. - WebDAV includes a few special rules on extending - WebDAV XML marshalling in backwards-compatible ways. + and all other XML elements used in marshalling. + WebDAV includes a few special rules on extendingextending + WebDAV XML marshalling in backwards-compatible ways (). Finishing off the specification are sections on what it means for a resource to be @@ -160,7 +407,7 @@
-
+
URI/URL - A Uniform Resource Identifier and Uniform Resource @@ -303,7 +550,7 @@ containing a property name element applies to the property value unless it has been overridden by a more locally scoped attribute. Note that a property only has - one value, in one language (or language MAY be left undefined), not + one value, in one language (or language MAY be left undefined), not; it does not have multiple values in different languages or a single value in multiple languages. @@ -589,6 +836,9 @@ PROPFIND result will select one of these equivalent segments to identify the mapping, so there will be one PROPFIND response element per mapping, not one per segment in the mapping. + + Servers SHOULD consistently use the same segment in PROPFIND responses. + Collection resources MAY have mappings to non-WebDAV compliant @@ -628,6 +878,7 @@ WebDAV collections. + A typical scenario in which mapped URLs do not appear as members of their parent collection is the case where a server allows links or redirects @@ -638,7 +889,22 @@ mapping from "/col/index.html", thus this resource might respond with a 200 OK to a GET request yet not appear as a member of "/col/". + +
+ + A typical scenario in which mapped URLs do not appear as members of + their parent collection is the case where a server allows links or redirects + to non-WebDAV resources. For instance, "/col/link" might not appear as a member of + "/col/", although the server would respond with a 302 status to a GET + request to "/col/link", thus the URL "/col/link" would indeed be + mapped. Similarly, a dynamically-generated page might have a URL + mapping from "/col/index.html", thus this resource might respond with + a 200 OK to a GET request yet not appear as a member of "/col/". + +
+ + Some mappings to even WebDAV-compliant resources might not appear in the parent collection. @@ -650,6 +916,21 @@ as equivalent, the server MUST expose only one preferred segment per mapping, consistently chosen, in PROPFIND responses. + +
+ + Some mappings to even WebDAV-compliant resources might not appear in the + parent collection. + An example for this case are servers that support multiple alias URLs + for each WebDAV compliant resource. A server may + implement case-insensitive URLs, thus "/col/a" and "/col/A" identify + the same resource, yet only either "a" or "A" are reported upon + listing the members of "/col". In cases where a server treats a set of segments + as equivalent, the server MUST expose only one preferred segment per mapping, + consistently chosen, in PROPFIND responses. + +
+
@@ -702,7 +983,14 @@ If a member resource is added to the collection, the new member resource MUST NOT already have a conflicting lock, - because the new resource MUST become indirectly locked by L. + because the new resource MUST become indirectly locked by L. + + So what happens if it has a conflicting lock? + + + Language? + + If a member resource stops being a member of the collection, then the resource MUST no longer be indirectly locked by L. @@ -738,7 +1026,7 @@ others from exercising an access right but rather to provide a mechanism for principals to indicate that they intend to exercise their access rights. Shared locks are provided for this case. A - shared lock allows multiple principals to receive a lock. Hence any + shared lock allows multiple principals to receive a distinct lock. Hence any principal that has both access privileges and a valid lock can use the locked resource. @@ -888,7 +1176,11 @@ If the timeout expires then the lock SHOULD be removed. In this case the server SHOULD act as if an UNLOCK method was executed by the server on the resource using the lock token of the timed-out lock, performed with - its override authority. + its override authority. + For instance, if the server implements some sort of logging and + notification system for locking-related events, a lock timeout should + be treated similar to an UNLOCK request. + Servers are advised to pay close attention to the values submitted by @@ -947,7 +1239,17 @@ support the DAV:lockdiscovery property.
- + + +
+ + A resource may be made available through more than one URI. A lock MUST + cover the resource as well as the URI to which the LOCK request was addressed. + The lock MAY cover other URIs mapped to the same resource as well. + + Section was removed in draft 15. Why? +
+ @@ -963,6 +1265,10 @@ any principal other than the lock creator and in any case where the lock token is not submitted (e.g. by a client process other than the one holding the lock). + + All of this is repeated in the next paragraph. Optimally remove + this one. + Clients MUST submit a lock-token they are authorized to use @@ -978,6 +1284,9 @@ any live property which is lockable (a live property is lockable unless otherwise defined.) + +So there are live properties which are lockable and may change their values while they are locked, and there are live properties which respect locks and must not change their values while they are locked? Is this really intended or is this section historical and should be dropped? +--Manfred Baedke For collections, any modification of an internal member URI. An internal member URI of a collection is considered to be modified @@ -1012,7 +1321,9 @@ change, even while locked, due to the requirements of their schemas. Only dead properties and live properties defined as lockable are guaranteed not to change while write locked. - +The whole paragraph doesn't seem to make sense anymore, +because it seems to say the same thing as the previous section, but uses different terminology. + @@ -1100,6 +1411,7 @@ Content-Language, thus the server will use defaults or empty values and rely on the subsequent PUT request for correct values. + A resource created with a LOCK is empty but otherwise behaves in every way as a normal @@ -1113,26 +1425,31 @@ Can be read, deleted, moved, copied, and in all ways behave as a regular non-collection resource. Appears as a member of its parent collection. - SHOULD NOT disappear when its lock goes away (clients must - therefore be responsible for cleaning up their own mess, as with - any other operation or any non-empty resource) - MAY NOT have values for properties like DAV:getcontentlanguage which - haven't been specified yet by the client. + SHOULD NOTWill not disappear when its lock goes away (clients must + therefore be responsible for cleaning up their own mess, as with + any other operation or any non-empty resource). + MAY NOTMay not have values for properties like DAV:getcontentlanguage which + haven't been specified yet by the client. Can be updated (have content added) with a PUT request. - MUST NOT be converted into a collection. The server MUST fail a MKCOL request - (as it would with a MKCOL request to any existing non-collection resource). - MUST have defined values for DAV:lockdiscovery and DAV:supportedlock - properties. - The response MUST indicate that a resource was created, by use of - the "201 Created" response code (a LOCK request to an existing - resource instead will result in 200 OK). The body must still - include the DAV:lockdiscovery property, as with a LOCK request to an - existing resource. + MUST NOTCan not be converted into a collection. The server MUSTwill fail a MKCOL request + (as it would with a MKCOL request to any existing non-collection resource). + MUSTWill have defined values for DAV:lockdiscovery and DAV:supportedlock + properties. + The response MUSTwill indicate that a resource was created, by use of + the "201 Created" response code (a LOCK request to an existing + resource instead will result in 200 OK). The body must still + include the DAV:lockdiscovery property, as with a LOCK request to an + existing resource. + - The client is expected to update the locked empty resource shortly - after locking it, using PUT and possibly PROPPATCH. + The client is expected to update the locked empty resource shortly + after locking it, using PUT and possibly PROPPATCH. + + + + Alternatively and for backwards compatibility to , servers MAY implement Lock-Null Resources (LNRs) instead (see definition in @@ -1154,7 +1471,7 @@ provides the same protection on that collection and also provides write lock protection on every member resource. - Expressed otherwise, a write lock protects any request that would create a new + Expressed otherwise, a write lock of either kind protects any request that would create a new resource in a write locked collection, any request that would remove an internal member URL of a write locked collection, and any request that would change the segment name of any internal member. @@ -1169,7 +1486,11 @@ MOVE to rename an internal member within a collection, COPY an internal member into a collection, and PUT or MKCOL request which would create a new internal member. - + + +... (or simply drop the list, since it does not contain anything new). +--Manfred Baedke + The collection's lock token is required in addition to the lock token on the internal member itself, if it is locked separately. @@ -1360,18 +1681,30 @@
+ A client MUST NOT submit the same write lock request twice. Note that a client is always aware it is resubmitting the same lock request because it must include the lock token in the If header in order to make the request for a resource that is already locked. + + IMHO all of this can go. This paragraph is just misleading; + repeating a LOCK request with an existing lock token in the If header + is going to fail for an exclusive lock anway. + + + However, a client may submit a LOCK request with an If header but without a body. A server receiving a LOCK request with no body MUST NOT create a new lock -- this form of the LOCK request is only to be used to "refresh" an existing lock (meaning, at minimum, that any timers associated with the lock MUST be re-set). + + Just point to the paragraph in the LOCK definition here. + + Clients may submit Timeout headers of arbitrary value with their lock refresh requests. Servers, as always, may ignore Timeout headers @@ -1380,10 +1713,13 @@ different than the previous timeout period used for the lock, provided it advertises the new value in the LOCK refresh response. + + If an error is received in response to a refresh LOCK request the client MUST NOT assume that the lock was refreshed. +
@@ -1484,7 +1820,7 @@ Identifiers for collections SHOULD end in a '/' character. -
+
Consider the collection http://example.com/sample/ with the internal member URL http://example.com/sample/a%20test and the PROPFIND request below: @@ -1529,8 +1865,10 @@ responses. Not all of these are appropriate in all situations and some interactions may be undefined. + Note that HTTP 1.1 requires the Date header in all responses if possible (see Section 14.18, ). + The server MUST do authorization checks before checking any HTTP conditional header. @@ -1575,7 +1913,8 @@ Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server SHOULD NOT change the ETag (or the Last-Modified time) for a resource that has an unchanged - body and location. The ETag represents the state of the body or contents of the + body and location. The ETag represents the state of the body or contents + entity body of the resource. There is no similar way to tell if properties have changed. @@ -1655,14 +1994,18 @@ with that element. - A client MUST submit a Depth header with a value of "0", "1", or + A client MUSTmay submit a Depth header with a value of "0", "1", or "infinity" with a PROPFIND request. Servers MUST support "0" and "1" depth requests on WebDAV-compliant resources and SHOULD support "infinity" requests. In practice, support for infinite depth requests MAY be disabled, due to the performance and security concerns associated with this behavior. + Since clients weren't required to include the Depth header in , - servers SHOULD treat such a request as if a "Depth: infinity" header was included. + servers SHOULD treat such a request as if a "Depth: infinity" header was included. + + 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 @@ -1682,6 +2025,18 @@ Request a list of names of all the properties defined on the resource, by using the 'propname' element. + + + The problem, however, is that there is no method to retrieve the +contents of a collection. You have to use PROPFIND with which you +can't request for an empty set of properties. You have to ask for +something, which means you always request the collection contents +together with information about its members. + + + Should we allow an empty <prop> element? + + A client may choose not to submit a request body. An empty PROPFIND request body MUST be treated as if it were an 'allprop' request. @@ -1743,10 +2098,11 @@ - 403 Forbidden - A server MAY reject - PROPFIND requests on collections with depth header of "Infinity", in + 403 Forbidden (with the condition code 'propfind-finite-depth' defined in ) - A server MAY reject + PROPFIND requests on collections with depth header of "Infinity", in which case it SHOULD use this error with the precondition code - 'propfind-finite-depth' inside the error body. + 'propfind-finite-depth' inside the error body.
@@ -2119,20 +2475,51 @@ The request message body of a PROPPATCH method MUST contain the propertyupdate XML element. - - Servers MUST process PROPPATCH instructions in - document order (an exception to the normal rule that ordering is + + + I think I know what 'document order' means but it isn't actually defined. + + + Actually, the statement is bogus, because we're not talking about + "PROPPATCH" instructions but the child elements of DAV:propertyupdate + in the request body. + + + See also Erratum 1371. + + + Fixed. + + + Servers MUST process PROPPATCH instructions in + document orderthe child elements of the propertyupdate + XML element in the order they appear in the request body + (an exception to the normal rule that ordering is irrelevant). 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 and . + + If a server attempts to make any of the property changes in a PROPPATCH request (i.e. the request is not rejected for high-level errors before processing the body), the response MUST be a Multi-Status response as described in . + + + + The response to a PROPPATCH request can be in two different formats: + should the server reject the request altogether (because of missing + access rights, failed conditional headers, malformed request syntax, etc.), + the status SHOULD be non-2xx HTTP status. On the other hand, if the server + did attempt the property modification, the response status SHOULD + be 207 Multistatus, using the 'multistatus' response body format defined + below (). + + This method is idempotent, but not safe (see Section 9.1 of ). Responses to this method MUST NOT be cached. @@ -2159,9 +2546,15 @@ specify, cannot alter one of the properties. + 403 (Forbidden): The client has attempted to set a protected property, such as DAV:getetag. If returning this error, the server SHOULD use the precondition code 'cannot-modify-protected-property' inside the response body. + + 403 (Forbidden) (with the condition code 'cannot-modify-protected-property' + defined in ) - The client + has attempted to set a protected property, such as DAV:getetag. + 409 (Conflict) - The client has provided a value whose semantics are @@ -2177,7 +2570,7 @@
-
+
>>Request @@ -2245,7 +2638,7 @@
-
+
MKCOL creates a new collection resource at the location specified by the Request-URI. If the Request-URI is already mapped to a resource @@ -2291,7 +2684,7 @@ the server does not allow the creation of collections at the given location in its URL namespace, or 2) the parent collection of the Request-URI exists but cannot accept members. - +Language? I think it can indicate lots of other things. 405 (Method Not Allowed) - MKCOL can only be executed on an unmapped URL. @@ -2301,12 +2694,14 @@ until one or more intermediate collections have been created. The server MUST NOT create those intermediate collections automatically. - + + 415 (Unsupported Media Type) - The server does not support the request body type (although bodies are legal on MKCOL requests, since this specification doesn't define any, the server is likely not to support any given body type). + 507 (Insufficient Storage) - The resource does not have sufficient space to record the state of the resource after the execution of @@ -2363,6 +2758,7 @@ 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. +The fact that it's undefined in RF2616 really wouldn't stop us to define it, I think.
@@ -2375,14 +2771,31 @@ A server processing a successful DELETE request: + - MUST destroy locks rooted on the deleted resource + + MUST destroy locks rooted on the deleted resource + MUST destroy those locks where the lock root is the Request-URI. + + + + MUST remove the mapping from the Request-URI to any resource. + + + + + + + MUST destroy locks rooted on the deleted resource + MUST destroy those locks where the lock root is the Request-URI. + MUST remove the mapping from the Request-URI to any resource. + Thus, after a successful DELETE operation (and in the absence of other actions) a subsequent GET/HEAD/PROPFIND request to the target Request-URI MUST return 404 (Not Found). @@ -2417,7 +2830,7 @@ than the resource identified in the Request-URI) then the response can be a 207 (Multi-Status). Multi-Status is used here to indicate which internal resources could NOT be deleted, including an error - code which should help the client understand which resources caused + code which should help the client understand which resourceswhat caused the failure. For example, the Multi-Status body could include a response with status 423 (Locked) if an internal resource was locked. @@ -2494,6 +2907,9 @@ A PUT that would result in the creation of a resource without an appropriately scoped parent collection MUST fail with a 409 (Conflict). + +What does 'appropiately scoped' mean here. Since there is the defined term 'namespace consistency', it should be used here. --Manfred Baedke + A PUT request allows a client to indicate what media type an entity body has, @@ -2511,6 +2927,10 @@ the first place. Thus, clients can't always rely on the ability to directly influence the content type by including a Content-Type request header. + + (1) We shouldn't say "ought generally", when the TAG says it's a SHOULD. (2) + I think extending this to heeaders other than Content-Type is just confusing here. +
@@ -2891,7 +3311,7 @@ DAV:creationdate property value SHOULD remain the same after a MOVE. - Dead properties MUST be moved along with the resource. + Dead properties MUSTSHOULD be moved along with the resource. @@ -2959,6 +3379,9 @@ "T" then prior to performing the move the server MUST perform a DELETE with "Depth: infinity" on the destination resource. If the Overwrite header is set to "F" then the operation will fail. + +Though it is defined later, mentioning the default here might be clearer. --Manfred Baedke + @@ -3109,15 +3532,17 @@ ). Responses to this method MUST NOT be cached. -
+
A LOCK request to an existing resource will create a lock on the resource identified by the Request-URI, provided the resource is not already - locked with a conflicting lock. The resource identified in the Request-URI - becomes the root of the lock. Lock method requests to create a new + locked with a conflicting lock. The resource identified in the Request-URI + becomes the root of the lock. + Lock method requests to create a new lock MUST have an XML request body. The server MUST preserve the - information provided by the client in the 'owner' field in the request body when the lock - information is requested. The LOCK request MAY have a Timeout + information provided by the client in the 'owner' field in the request body when the lock + information is requestedXML element. + The LOCK request MAY have a Timeout header. @@ -3155,7 +3580,7 @@
-
+
The Depth header may be used with the LOCK method. Values other than 0 or infinity MUST NOT be used with the Depth header on a LOCK @@ -3189,8 +3614,9 @@
-
+
+ A successful LOCK method MUST result in the creation of an empty resource which is locked (and which is not a collection), when a resource did not previously exist at that URL. Later on, the lock @@ -3199,10 +3625,15 @@ scope. A server MUST respond successfully to a GET request to an empty resource, either by using a 204 No Content response, or by using 200 OK with a Content-Length header indicating zero length + + A successful LOCK request to an unmapped URL causes that URL to become + mapped, and the new resource being referred to being locked. See + for further details. +
-
+
The table below describes the behavior that occurs when a lock @@ -3233,7 +3664,7 @@
-
+
In addition to the general status codes possible, the following status codes have specific applicability to LOCK: @@ -3257,6 +3688,7 @@ is already a lock on the resource which is not compatible with the requested lock (see lock compatibility table above). + 412 (Precondition Failed), with 'lock-token-matches-request-uri' precondition code - The LOCK request was made with a If header, indicating that the @@ -3265,7 +3697,17 @@ a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid. - + + + 412 (Precondition Failed), with 'lock-token-submitted' precondition code - + The LOCK request was made with an If header, indicating that the + client wishes to refresh the given lock. However, the Request-URI did not + fall within the scope of the lock identified by the token. The lock may have + a scope that does not include the Request-URI, or the lock could have disappeared, + or the token may be invalid. + + +
@@ -3477,8 +3919,14 @@ present it has its normal meaning as a conditional header. + For a successful response to this method, the server MUST delete the lock entirely. + + For a successful response to this + method, the server MUST remove the lock from the resource identified + by the Request-URI and from all other resources included in the lock. + @@ -3580,10 +4028,12 @@ DAV = "DAV" ":" #( compliance-class ) compliance-class = ( "1" | "2" | "3" | extend ) - extend = Coded-URL | token + extend = Coded-URL | token + ; token: defined in Coded-URL = "<" absolute-URI ">" - ; No linear white space (LWS) allowed in Coded-URL - ; absolute-URI is defined in RFC3986 + ; No linear white space (LWS) allowed in Coded-URLLinear White Space (LWS) allowed in + ; Coded-URL + ; absolute-URI is defined in RFC3986: defined in @@ -3596,17 +4046,18 @@ The value is a comma-separated list of all compliance class - identifiers that the resource supports. Class identifiers may be - Coded-URLs or tokens (as defined by ). Identifiers can + identifiers that the resource supports. Class identifiers may be + Coded-URLs or tokens (as defined by ). + Identifiers can appear in any order. Identifiers that are standardized through the IETF RFC process are tokens, but other identifiers SHOULD be Coded-URLs to encourage uniqueness. - + A resource must show class 1 compliance if it shows class 2 or 3 compliance. In general, support for one compliance class does not entail support for any other, and in particular, support for compliance class - 3 does not require support for compliance class 2. Please refer to Please refer to for more details on compliance classes defined in this specification. @@ -3697,14 +4148,14 @@
- Destination = "Destination" ":" Simple-ref + Destination = "Destination" ":" Simple-ref (see )
If the Destination value is an absolute-URI (Section 4.3 of ), it may name a different server (or different port or scheme). If the source server cannot - attempt a copy to the remote server, it MUST fail the request. Note that + attempt a copy to the remote server, it MUST fail the requestYes. What else should the server do? :) --Manfred Baedke. Note that copying and moving resources to remote servers is not fully defined in this specification (e.g. specific error conditions). @@ -3728,6 +4179,7 @@ The If header has two distinct purposes: + The first purpose is to make a request conditional by supplying a series of state lists with conditions that match tokens and ETags to specific resource. If this header is evaluated and all state lists fail, @@ -3736,6 +4188,14 @@ state lists succeeds. The success criteria for state lists and matching functions are defined in and . + + The first purpose is to make a request conditional by supplying a + series of state lists. If none of the state lists match the + state of the resource it applies to, the request MUST fail with a + 412 (Precondition Failed) status. Otherwise, the request may succeed. + The matching functions for ETags and state tokens are defined in + below. + Additionally, the mere fact that a state token appears in an If header @@ -3801,7 +4261,7 @@
-
+
A Condition that consists of a single entity-tag or state-token evaluates to true if the resource matches the described state (where the individual @@ -3852,9 +4312,15 @@ in the scope of the lock. + Handling unmapped URLs: for both ETags and state tokens, treat as if the URL identified a resource that exists but does not have the specified state. + + Note that for the purpose of matching entity tags and state tokens, the + URL being unmapped should be treated the same way as if the resource + existed, but did not have the specified state. +
@@ -3906,10 +4372,19 @@
+ + + Missing whitespace on continuation line of If header. + See also Erratum 1068. + + + Added whitespace. + +
If: (Not <urn:uuid:181d4fae-7d8c-11d0-a765-00a0c91e6bf2> - <urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>) + <urn:uuid:58f202ac-22cf-11d1-b12d-002035b29092>)
This If header requires that the resource must not be locked with a lock @@ -4059,7 +4534,7 @@ If a COPY or MOVE is not performed due to the value of the Overwrite header, the method MUST fail with a 412 (Precondition Failed) status code. The server MUST do authorization checks before checking this - or any conditional header. + or any conditional header. All DAV compliant resources MUST support the Overwrite header. @@ -4101,7 +4576,7 @@ . -
+
The 207 (Multi-Status) status code provides status for multiple independent operations (see @@ -4109,7 +4584,7 @@
-
+
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a @@ -4122,7 +4597,7 @@
-
+
The 423 (Locked) status code means the source or destination resource of a method is locked. This response SHOULD @@ -4131,7 +4606,7 @@
-
+
The 424 (Failed Dependency) status code means that the method could not be performed on the resource because the requested action @@ -4141,7 +4616,7 @@
-
+
The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to @@ -4165,7 +4640,7 @@ to use 300-level redirect responses (and early interoperability tests found clients unprepared to see those responses). A 300-level response MUST NOT be used when the server has created a new resource in response to the request. - +Don't we usually say "3xx class" instead of "300-level"?
@@ -4181,12 +4656,14 @@
+
This status code is used in HTTP 1.1 only for Request-URIs, not URIs in other locations.
+
@@ -4258,15 +4735,21 @@ Servers MUST use this new element with redirect responses in Multi-Status. Clients encountering redirected resources in Multi-Status MUST NOT rely on - the 'location' element being present with a new URI. If the element is not present, the client + the 'location' element being present with a new URI. + Inconsistency: if servers MUST include the location element, why can't clients + rely on it being present??? + If the element is not present, the client MAY reissue the request to the individual redirected resource, because the response to that request can be redirected with a Location header containing - the new URI. + the new URI. + Language: clients MAY do whatever they want. This is nothing normative. +
-
+ +
, , , and @@ -4276,7 +4759,8 @@ responses.
- + +
@@ -4324,7 +4808,7 @@ ]]>
-
+
depth Used for representing depth values in @@ -4362,7 +4846,7 @@
-
+
href MUST contain a URI or a @@ -4372,7 +4856,8 @@ Refer to the specification text where 'href' is used to see what limitations apply in each case. - Simple-ref + Simple-ref (see ) +
<!ELEMENT href (#PCDATA)> @@ -4502,7 +4987,10 @@
owner - Provides information about the creator of a lock. + Provides information about the creator of a lock. + Holds client-supplied information about the principal on whose + behalf the lock was created. + Allows a client to provide information sufficient for either directly contacting a principal (such as a telephone number or Email URI), or for discovering the @@ -4620,12 +5108,18 @@ resource relative to the request or result.
- ]]> -
+<!ELEMENT response (href, ((href*, status)|(propstat+)), + error?, responsedescription? , location?) >
+ + + Note: the usage of the 'error' element inside 'response' is an + incompatible change to , paragraph 2 + (where 'error' appeared as a child element of 'responsedescription'). + +
-
+
responsedescription Contains information about a status response within a Multi-Status. @@ -4730,15 +5224,24 @@ resource, or even of some other resource). A computed property is always a protected property. - - COPY and MOVE behavior refers to local COPY and MOVE operations. - + + + COPY and MOVE behavior refers to local COPY and MOVE operations. + + For properties defined based on HTTP GET response headers (DAV:get*), the header value could include LWS as defined in , Section 4.2. - Server implementors SHOULD strip LWS from these values before using as + Server implementors SHOULDMUST strip LWS from these values before using as WebDAV property values. -
+ + + Note that all property elements can be extended according to the rules defined in + . + + + +
@@ -4767,7 +5270,7 @@ ]]>
-
+
@@ -4785,6 +5288,9 @@ presentation to a user. This property is defined on the resource, and hence SHOULD have the same value independent of the Request-URI used to retrieve it (thus computing this property based on the Request-URI is deprecated). + + + While generic clients might display the property value to end users, client UI designers must understand that the method for identifying resources is still @@ -4824,14 +5330,14 @@ ]]>
-
+
getcontentlength Contains the Content-Length header returned by a GET without accept headers. See Section 14.13 of . This property is computed, therefore protected. - The DAV:getcontentlength property MUST be defined on any + The DAV:getcontentlength property MUSTSHOULD be defined on any DAV compliant resource that returns the Content-Length header in response to a GET. This property value is dependent on the size of @@ -4845,7 +5351,7 @@ ]]>
-
+
getcontenttype Contains the Content-Type header value (from Section 14.17 @@ -4866,7 +5372,7 @@ ]]>
-
+
getetag Contains the ETag header value (from Section 14.19 @@ -4902,10 +5408,10 @@ the Last-Modified header to which this property is linked. This property value is dependent on the last modified date of the destination resource, not the value of - the property on the source resource. Note that some server + the property on the source resource. Note that some server implementations use the file system date modified value for the DAV:getlastmodified value, and this can be preserved in a - MOVE even when the HTTP Last-Modified value SHOULD change. + MOVE even when the HTTP Last-Modified value SHOULD change. Note that since requires clients to use ETags where provided, a server implementing ETags can count on clients using a much better mechanism than modification dates for offline synchronization or cache control. @@ -4918,7 +5424,9 @@ the last-modified date to know when to overwrite the existing body. The DAV:getlastmodified property MUST be defined on any DAV compliant resource that returns the Last-Modified - header in response to a GET. + header in response to a GET. +Language: starts with a note (IMHO unneeded), but then makes a normative statement. + @@ -4928,7 +5436,7 @@
-
+
lockdiscovery Describes the active locks on a resource @@ -4941,8 +5449,11 @@ 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. Owner information MAY be omitted - if it is considered sensitive. If there are no locks, but the server supports + token. + Owner information MAY be omitted + if it is considered sensitive.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. If there are no locks, but the server supports locks, the property will be present but contain zero 'activelock' elements. If there is one or more lock, an 'activelock' element appears for each lock on the resource. This @@ -4971,39 +5482,53 @@
>>Response - HTTP/1.1 207 Multi-Status Content-Type: application/xml; charset="utf-8" Content-Length: xxxx - - - - http://www.example.com/container/ - - - - - - - 0 - Jane Smith - Infinite - - urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76 - - - http://www.example.com/container/ - - - - - HTTP/1.1 200 OK - - - - ]]> + <?xml version="1.0" encoding="utf-8" ?> + <D:multistatus xmlns:D='DAV:'> + <D:response> + <D:href>http://www.example.com/container/</D:href> + <D:propstat> + <D:prop> + <D:lockdiscovery> + <D:activelock> + <D:locktype><D:write/></D:locktype> + <D:lockscope><D:exclusive/></D:lockscope> + <D:depth>0</D:depth> + <D:owner>Jane Smith</D:owner> + <D:timeout>Infinite</D:timeout> + <D:locktoken> + <D:href + >urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href> + </D:locktoken> + <D:lockroot> + <D:href>http://www.example.com/container/</D:href> + </D:lockroot> + </D:activelock> + <D:activelock> + <D:locktype><D:write/></D:locktype> + <D:lockscope><D:exclusive/></D:lockscope> + <D:depth>0</D:depth> + <D:owner>Jane Smith</D:owner> + <D:timeout>Infinite</D:timeout> + <D:locktoken> + <D:href + >urn:uuid:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76</D:href> + </D:locktoken> + <D:lockroot> + <D:href>http://www.example.com/container/</D:href> + </D:lockroot> + </D:activelock> + </D:lockdiscovery> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + </D:propstat> + </D:response> + </D:multistatus> + This resource has a single exclusive write lock on it, with an infinite timeout. @@ -5013,15 +5538,20 @@
-
+
resourcetype Specifies the nature of the resource. SHOULD be protected. Resource type is generally decided through the operation creating the resource (MKCOL vs PUT), - not by PROPPATCH. + not by PROPPATCH. +Language confusing: why "generally"? + Generally a COPY/MOVE of a resource results in - the same type of resource at the destination. + the same type of resource at the destination. +That's true for the collection type, but I doubt it's true in general (where +types often depend on specific locations in the server namespace). + MUST be defined on all DAV compliant resources. Each child element identifies a specific type the resource belongs to, such as 'collection', which is the only resource type defined by @@ -5057,7 +5587,9 @@ locks supported at the destination, not on the value of the property at the source resource. Servers attempting to COPY to a destination should not attempt to set this property at - the destination. + the destination. +That's generally true for any protected property, right? + Returns a listing of the combinations of scope and access types which may be specified in a lock request on the resource. Note @@ -5150,7 +5682,7 @@ This mechanism does not take the place of using a correct numeric - status code as defined here or in HTTP, because the client MUST + status code as defined here or in HTTP, because the client MUSTmust always be able to take a reasonable course of action based only on the numeric code. However, it does remove the need to define new numeric codes. The new machine-readable codes used for this @@ -5204,30 +5736,48 @@ All these elements are in the "DAV:" namespace. If not specified otherwise, the content for each condition's XML element is defined to be empty. - - + + + lock-token-matches-request-uri + 409 Conflict + (precondition) -- A request may include a Lock-Token header to identify a lock for the UNLOCK method. However, if the Request-URI does not fall within the scope of the lock identified by the token, the server SHOULD use - this error. The lock may have + this errorcondition. The lock may have a scope that does not include the Request-URI, or the lock could have disappeared, or the token may be invalid. - + +
+ + + + A request may include a Lock-Token header to identify a lock for the + purpose of UNLOCK. However, if the + Request-URI does not fall within the scope of the lock identified by the + token, the server SHOULD use this condition code. + +
+ + + lock-token-submitted (precondition) + 423 Locked + The request could not succeed because a lock token should have been submitted. This element, if present, MUST contain at least one URL of a locked resource that prevented the request. In cases of MOVE, COPY and DELETE where collection locks are involved, it can be difficult for the client to find out which locked resource - made the request fail -- but the server is only resonsible for returning + made the request fail -- but the server is only responsible for returning one such locked resource. The server MAY return every locked resource that prevented the request from succeeding if it knows them all. @@ -5235,10 +5785,40 @@
]]>
+ +
+ + + + If a request would + + modify the content for a locked resource, a dead + property of a locked resource, a live property that is defined to be + lockable for a locked resource, + an internal member URI of a locked collection, or + refresh a lock that locks that resource, + + the request MUST fail unless the lock-token for that lock is + submitted in the request. An internal member URI of a collection is + considered to be modified if it is added, removed, or identifies a + different resource. + +
+ <!ELEMENT lock-token-submitted (href)* >
+ + Servers SHOULD insert DAV:href elements for the URLs of each root of a + lock for which a lock token was needed, unless that URL identifies the + same resource to that the request was sent. + +
+ + no-conflicting-lock (precondition) + Typically 423 Locked + A LOCK request failed due the presence of an already existing conflicting lock. Note that a lock can be in conflict although the resource to which @@ -5249,22 +5829,60 @@
]]>
- - - - no-external-entities - 403 Forbidden - (precondition) -- If the server rejects a client - request because the request body contains an external entity, the - server SHOULD use this error. + +
+ + + + This precondition code can be used to signal that a lock request failed + due the presence of an already existing conflicting lock. Note that + a lock can be in conflict although the resource to which the request + was directed is only indirectly locked. In this case, the + precondition code can be used to inform the client about the resource + which is the root of the conflicting lock, avoiding a separate lookup + of the "lockdiscovery" property. Make sure the document actually + defines "indirectly locked". + +
+ <!ELEMENT no-conflicting-lock (href)* >
+ + Servers SHOULD insert a DAV:href element for the URL of the root of the + conflicting lock. + +
+ + + + + no-external-entities + + 403 Forbidden + + (precondition) -- If the server rejects a client + request because the request body contains an external entity, the + server SHOULD use this errorcondition code. + + + - - - - - + +
+ + + + If the request body is XML, and the server does not support external + entities, this condition code can be used to signal the problem (see + also ). + +
+ + + + preserved-live-properties + 409 Conflict + (postcondition) -- The server received an otherwise-valid MOVE or COPY request, but cannot maintain the live properties with the same behavior at the destination. @@ -5273,23 +5891,66 @@ + +
+ + + + Servers may reject MOVE requests, if they cannot maintain live properties + with the same behaviour at the destination URL. In this case, this + postcondition name may be used to signal the failure condition. + Does this really apply to COPY as well??? + +
+ - - propfind-finite-depth - 403 Forbidden - (precondition) -- This server does not allow - infinite-depth PROPFIND requests on collections. + + + propfind-finite-depth + + 403 Forbidden + + (precondition) -- This server does not allow + infinite-depth PROPFIND requests on collections. + + - + + +
+ + + + Used to signal that a request was rejected because the server did not + allow a value of "infinity" for the "Depth" request header. + +
+ - + + cannot-modify-protected-property + 403 Forbidden + (precondition) -- The client attempted to set a protected property in a PROPPATCH (such as DAV:getetag). See also , Section 3.12. - + + + + +
+ + + + An attempt to modify a property that is defined by this document, as being + protected for that kind of resource, MUST fail (see , + Section 3.12). + +
+
@@ -5342,6 +6003,7 @@ specification. However, correct XML will not be valid according to any DTD due to namespace usage and extension rules. In particular: + Elements (from this specification) are in the "DAV:" namespace, Element ordering is irrelevant unless otherwise stated, @@ -5356,7 +6018,20 @@ Note that this means that elements containing elements cannot be extended to contain text, and vice versa. - + + + + Element names use the "DAV:" namespace, + Element ordering is irrelevant unless otherwise stated, + Extension attributes (attributes not already defined by this specification) + may be added, and MUST be ignored by recipients unless recognized), + + Extension elements (elements not already defined by this specification) + may be added for element type definitions other than "ANY" or "#PCDATA", + and MUST be ignored by recipients unless recognized). + + + With DTD validation relaxed by the rules above, the constraints described by the DTD fragments are normative (see for example @@ -5440,6 +6115,16 @@
+ + + Treat references to UTF-8 and UTF-16 the same way (add RFC reference for + UTF-16). Make UTF-8 reference informative (the requirements are defined + in XML-REC, not this specification). + + + Done. + + In the realm of internationalization, this specification complies with the IETF Character Set Policy . In this specification, @@ -5448,7 +6133,8 @@ In both cases, the human-readable content is encoded using XML, which has explicit provisions for character set tagging and encoding, and requires that XML processors read XML elements - encoded, at minimum, using the UTF-8 and UTF-16 encodings of + encoded, at minimum, using the UTF-8 and UTF-16 + UTF-8 () and UTF-16 () encodings of the ISO 10646 multilingual plane. XML examples in this specification demonstrate use of the charset parameter of the Content-Type header, as defined in , as well as the XML @@ -5525,7 +6211,7 @@ concerns, and may increase the hazards from poor server design. These issues are detailed below. -
+
Due to their emphasis on authoring, WebDAV servers need to use authentication technology to protect not just access to a network @@ -5637,7 +6323,7 @@
-
+
XML supports a facility known as "external entities", defined in Section 4.2.2 of , which instruct an XML processor to @@ -5658,9 +6344,12 @@ worst case significantly modifying its semantics, or exposing the XML processor to the security risks discussed in . Therefore, implementers must be aware that external XML entities - should be treated as untrustworthy. If a server implementor chooses + should be treated as untrustworthy. If a server implementor chooses not to handle external XML entities, it SHOULD respond to requests - containing external entities with the 'no-external-entities' condition code. + containing external entities with the 'no-external-entities' condition code. + If a server rejects a request due to the presence of external entities, it + SHOULD include the 'no-external-entities' condition code in the response body. + There is also the scalability risk that would accompany a widely @@ -5680,7 +6369,7 @@
-
+
This specification encourages the use of "A Universally Unique Identifier (UUID) URN Namespace" () for @@ -5714,7 +6403,7 @@
-
+
HTTP has the ability to host programs which are executed on client machines. These programs can take many forms including web scripts, executables, plug in modules, and macros in documents. WebDAV does not change any of the security concerns around these programs yet often WebDAV is used in @@ -5726,16 +6415,58 @@ published content. Servers can also mitigate the risk by having appropriate access restriction and authentication of users that are allowed to publish content to the server. - + + + One specific attack scenario deserves special mention here: with the + arrival of the "XMLHttpRequest" API (see ), + user agents have acquired the capability to submit arbitrary HTTP requests + against the server the content was obtained from. With the well-known + semantics of HTTP verbs such as PUT and DELETE, the following attack + becomes possible: + + Alice prepares an HTML page with embedded Javascript code that will + submit a DELETE request against the URI http://www.example.com/users/bob/ (a + resource she has not write access to, but Bob has). + Alice stores this HTML page at http://www.example.com/users/alice/readme.html, + a resource she has write access to. + Alice emails Bob a link to http://www.example.com/users/alice/readme.html, + for which he has read access once authenticated. + Bob follows the link, authenticates, and the embedded script code + executes the DELETE request against http://www.example.com/users/bob/ + while being authenticated as Bob. + + + + This attack relies on the common risk of collaboratively authoring + resources on the same server, which requires a certain amount of trust + between the users. However, even an action usually considered as "safe", + such as opening an HTML page in a web browser, can cause arbitrary + HTTP methods to be invoked. Note that WebDAV isn't the root cause + for this vulnerability, it just makes it more visible. + + + Potential steps to reduce the risks associated with this attack include: + + Separating server domains for authoring (read/write) and publicly serving + content. + Disallowing certain content (such as scripts in HTML pages) altogether, + as discussed above. + Using user agents that follow , + in that they do not allow unsafe methods to be executed without making the + user aware of the consequences - unfortunately, none of today's browsers + is doing that. + + +
-
+
- This specification defines two URI schemes: + This specification defines two URI schemes (see and ): the "opaquelocktoken" scheme defined in , and @@ -5760,11 +6491,19 @@ names or element names.
-
+
- The message header fields below should be added to the permanent - registry (see ). - + The message header fields below should be added toupdated in the permanent + registry (see for the registration process, and + for the initial registration being updated by this specification). + + + + Note: the "Status-URI" header defined in + has been removed in this specification; its IANA registration should continue + to reference RFC2518. + +
Header field name: DAV @@ -5824,10 +6563,35 @@
+ + + +
+ + This specification defines the HTTP status codes + + 207 Multi-Status (Section ), + 422 Unprocessable Entity (Section ), + 423 Locked (Section ), + 424 Failed Dependency (Section ) and + 507 Insufficient Storage (Section ), + + to be updated in the registry at . + + + Note: the HTTP status code 102 (Processing) (defined in ) + has been removed in this specification; its IANA registration should continue + to reference RFC2518. + +
+ +
-
+
+I think three sections of thanks is way too much, this probably should +be collapsed into a single one. 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 @@ -6309,23 +7073,20 @@ - - - - - -UTF-8, a transformation format of ISO 10646 - - - - -ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. - - - - - - + + + + UTF-8, a transformation format of ISO 10646 + + Alis Technologies +
fyergeau@alis.com
+ + + + + + + @@ -6463,7 +7224,9 @@ - + + + Namespaces in XML @@ -6488,6 +7251,40 @@ + + + + Namespaces in XML 1.0 (Second Edition) + + Textuality +
+ tbray@textuality.com +
+ + + Contivo, Inc. +
+ dmh@contivo.com +
+ + + Microsoft +
+ andrewl@microsoft.com +
+ + + University of Edinburgh and Markup Technology Ltd +
+ chard@cogsci.ed.ac.uk +
+ + + + + + + XML Information Set (Second Edition) @@ -6503,9 +7300,9 @@ - - + + Extensible Markup Language (XML) 1.0 (Third Edition) @@ -6542,6 +7339,45 @@ + + + + Extensible Markup Language (XML) 1.0 (Fourth Edition) + + Textuality and Netscape +
+ tbray@textuality.com +
+ + + Microsoft +
+ jeanpa@microsoft.com +
+ + + University of Illinois at Chicago and Text Encoding Initiative +
+ cmsmcq@uic.edu +
+ + + Sun Microsystems +
+ eve.maler@east.sun.com +
+ + + +
+ francois@yergeau.com +
+ + + + + + @@ -6678,6 +7514,27 @@ + + + + UTF-16, an encoding of ISO 10646 + + Internet Mail Consortium +
+ phoffman@imc.org +
+ + + Alis Technologies +
+ fyergeau@alis.com +
+ + + + + + @@ -6774,6 +7631,20 @@ + + + + UTF-8, a transformation format of ISO 10646 + + Alis Technologies +
fyergeau@alis.com
+ + + + + + + @@ -6913,7 +7784,54 @@ + + + + + HTTP Header Field Registrations + + + + + + + + + + + Guidelines and Registration Procedures for New URI Schemes + + + + + + + + + + + + + + + + + + The XMLHttpRequest Object + + Opera Software ASA +
+ annevk@opera.com +
+ + + + + Work in progress. + + + @@ -7118,8 +8036,9 @@
-
- +
+ + The original WebDAV model for locking unmapped URLs created "lock-null resources". This model was over-complicated and some interoperability and implementation problems @@ -7155,7 +8074,42 @@ "locked empty resources" by only attempting PUT after a LOCK to an unmapped URL, not MKCOL or GET. - + + + This specification deprecates the "Lock-Null Resources" (LNRs) defined in Section + 7.4 of , and replaces them with empty locked regular + resources (see ). However, it's still + legal for servers to implement the deprecated model. + + + A LNR differs from an empty locked resource in the following aspects: + + + It MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to any + methods except for PUT, MKCOL, OPTIONS, PROPFIND, LOCK, and UNLOCK. + + + Most of its live properties, such as all the get* properties, will have + no value as a lock-null resource does not support the GET method. It MUST + have defined values for lockdiscovery and supportedlock properties. + + + 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 + resource ceases to be in the lock-null state. (Note that an LNR thus + can be used to create a collection, which is not possible with the + simplified empty locked resource model anymore.) + + + If it 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. (Note that with an empty locked resource, + an empty regular resource would remain in place.) + + + +
A WebDAV client implemented to this specification might find servers @@ -7187,6 +8141,7 @@
+
@@ -7269,7 +8224,7 @@
-
+
This section lists major changes between this document and RFC2518, starting with those that are likely to result in implementation changes. Servers will @@ -7320,6 +8275,15 @@ Headers and Marshalling + + + The requirement to support UTF-16 stems from XML-REC and thus is not new. + The fact only UTF-8 was mentioned in RFC2518bis simply was a oversight. + + + Done. + + The Destination and If request headers now allow absolute paths in @@ -7333,16 +8297,18 @@ in (see ). Related to that, it adds the "error" XML element inside multistatus response bodies (see , however note that it uses a format - different from the one recommend in RFC3253). + different from the one recommended in RFC3253). - + Senders and recipients are now required to support the UTF-16 character encoding in XML message bodies (see ). - + + Clients are now required to send the Depth header on PROPFIND requests, although servers are still encouraged to support clients that don't. + @@ -7641,7 +8607,7 @@
Fixed factual errors in Security Considerations authentication section. Fixed example of refreshing a lock -- didn't use "If" header as required in the text. - Fixed example of using so-called 'all-prop' with the 'include' directivenotifi, so that it + Fixed example of using so-called 'all-prop' with the 'include' directivenotifi, so that it would actually be a useful example, by including live properties that wouldn't already be covered by 'all-prop'. Clarified requirement in section 7.7 paragraph 2 -- a clear requirement for the server to meet, rather than @@ -7667,6 +8633,186 @@ summary
+ +
+ + In , clarify extensibility, and what exactly + the DTD fragments mean. In and , + refer to extensibility rules, remove "Extensibility" lines. Clarify content for + . + See issue 48. + + + Fix inconsistencies after backout of lock refresh changes. + See issue 143. + + + Update PUT () accordingly. Also fix language + in (should be a separate ticket). + See issue 152. + + + Minor fixes applied to changes made by L. D. + See issue 161. + + + Remove misleading statement about Date header in + (it tries to repeat normative language from Section 14.18 of , but + fails; for instance, the Date header is not required for 1xx responses). + See issue 169. + + + Cleanup description of status codes inside multistatus in + , and clarify individual Sections + and as well. + See issue 177. + + + Fix incorrect terminology and typos, mainly in . Add + forward references. + See issue 181. + + + Remove most of the unnecessary stuff from the definition of + empty locked resources, and remove the part about LNRs completely, + just adding a forward reference to a new appendix (). + See issue 202. + + + Fix intro in plus text in . + See issue 213. + + + Various proposed fixes to Sections , + and . + See issue 217. + + + Remove "use with" statements from . + See issue 220. + + + Fix typos; add requirement to consistently use the same segment in + PROPFIND responses, re-add subsection titles for examples. + See issue 227. + + + Re-organize some of the Timeout discussion in . + Remove unneeded statement about what timetype values are allowed + in responses (), and integrate those + parts that are about Timeout semantics into . Update Changes section. + See issue 229. + + + Relaxed requirements for COPY () and MOVE + () of dead properties to "SHOULD". + See issue 235. + + + Describe the problem and potential solutions in . + See issue 237. + + + Add definition of PROPPATCH response format in . + See issue 238. + + + Relax requirements for DAV:getcontentlength in . + See issue 239. + + + Update references for REC-XML and REC-XML-NAMES. + See issue 240. + + + Fix inconsistency between and . + See issue 241. + + + Remove statement in . + See issue 242. + + + Remove unneeded subsection from . + See issue 243. + + + Fix description of DAV:owner in . + See issue 244. + + + Remove incomprehensible statement from . + See issue 245. + + + Get rid of confusing statement about COPY/MOVE behaviour in . + See issue 247. + + + Fix statement about LWS handling in . + See issue 248. + + + Remove misleading statement about status 415 from . + See issue 250. + + + Rephrase introduction to . + See issue 251. + + + Rewrite to become consistent with + whatever says. + See issue 252. + + + Rephrase statement about shared locks in . + See issue 254. + + + Remove redundant language from . + See issue 255. + + + Update front matter to say "Updates: 3253" (no change tracking). + Note the nature of the change in . + See issue 258. + + + Rephrase sentence about unlock notifications () + so that it becomes clear that those are not specified by WebDAV. + See issue 259. + + + Restore missing text from (see ). + See issue 260. + + + Add registration procedure and registry references; add information + about Status-URI to , add + HTTP status code registration (). + See issue 264. + + + Clarify the requirement about the ordering of instructions inside the + PROPPATCH request in . + + + Add reference for UTF-16 in . + Make the UTF-8 reference informative (the normative reference is already + made through XML-REC). + + + Remove incorrect claim from that the UTF-16 requirement + is new (it was always required to support UTF-16 because of the + requirements inherited from XML-REC). + + + Add missing whitespace in If header example. + +
+ +