Issues List
# |
Issue ID |
Type |
Status |
Issue Description |
Reference |
Resolution |
|
1 |
PROP_ATTR |
Change |
InBis |
What is a WebDAV server required to do with XML attributes other than xml:lang submitted with a PROPPATCH? This affects how well WebDAV will be able to support RDF, since RDF uses attributes extensively. |
Greg Stein raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0089.html |
See: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0070.html |
|
2 |
WRITE_DAV_PROP |
Change |
InBis |
Which properties specified in the WebDAV specification “DAV:” properties may be written by the client? For example, can the client write to DAV:getcontenttype? |
Jim Davis raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0204.html See also discussion: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0022.html http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0071.html |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2003AprJun/0106.html |
|
3 |
XML_NS |
Change |
InBis |
Remove the XML Namespace appendix from the WebDAV specification, since it has gone to REC status at the W3C. |
Yaron outlined this issue at one point: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0343.html |
Approved to remove appendix 4. While doing so, insure that we at least mention our Namespace URI. Scan for other references to XML Namespace: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0308.html also try to use appropriate notation: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0328.html |
|
4 |
REMOVE_RELATED |
Editorial |
Closed |
Remove the word “related” from the discussion under “Collections:” in section 1. |
Mark D. Anderson raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0230.html |
|
|
5 |
NOTE_NO_VERSIONING |
Editorial |
InBis |
It would be helpful if the WebDAV Distributed Authoring Protocol explicitly mentioned that versioning was not supported. |
Mark D. Anderson raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0230.html |
|
|
6 |
EMPHASIZE_DTD_GROUPS |
Editorial |
InBis |
It would be helpful to add comments to the WebDAV XML DTD to emphasize the logical grouping of elements. |
Mark D. Anderson raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0230.html |
2518bis has added comments and a few other minor changes to the DTD listed there. |
|
7 |
BACKGROUND |
Editorial |
Closed |
It would be helpful to note which specifications are considered to be necessary background reading for reading the WebDAV spec. |
None. |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2003AprJun/0106.html |
|
8 |
URI_URL |
Editorial |
Defered |
Perform a thorough review of the specification to ensure that URI and URL are used correctly, and consistently throughout. -- |
Larry Masinter raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0142.html |
Seems to have been deferred: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0216.html but there is some follow on discussion on what exactly needs to be clarified. http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0068.html but no specific action was concluded besides the fact that we don’t need to wait for RFC2396 to be updated or request any changes/clarifications to that. |
|
9 |
NULL_RESOURCE |
Editorial |
Closed |
Add a forward reference to section 7.4 (“Write Locks and Null Resources”) in the definition of Null Resource in the Terminology section. |
Mark D. Anderson raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0230.html |
No longer relevant now that we lack that definition: http://lists.w3.org/Archives/Public/w3c-dist-auth/2003AprJun/0106.html |
|
10 |
COLLECTION_INTRO |
Editorial |
Closed |
The introduction to collections has been a source of confusion, and should be rewritten to be more clear. Mark Anderson has some suggestions for text that can go into this new introduction, which can be used as a starting point. |
Mark D. Anderson raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0231.html |
Incorporated in 2518 long ago. |
|
11 |
CONSISTENCY |
Change |
Open |
Disagreement over whether a DAV URI namespace needs to be consistent. |
Issue raised by Roy Fielding: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0155.html, http://lists.w3.org/Archives/Public/w3c-dist-auth/2003AprJun/0106.html |
|
|
12 |
COMPLIANCE_RESOURCE |
Editorial |
Open |
Add a brief description to the text describing why we discuss compliance on a per-resource basis. Try to remove references to server compliance. |
Mark D. Anderson raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0231.html |
|
|
13 |
REMOVE_SECTION_5.3 |
Editorial |
InBis |
Discussion in section 5.3 about why MKCOL was used instead of PUT doesn’t belong in a protocol specification (it’s a minor point of design rationale), and appears to be confusing to some. |
Mark D. Anderson raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0231.html |
|
|
14 |
DEFINE_PRINCIPAL |
Editorial |
Open |
The term “principal” is never defined in the WebDAV specification, or the HTTP or Digest specifications. It should be defined. |
Mark D. Anderson raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0234.html |
|
|
15 |
MOVE_SECTION_6.4.1_TO_APPX |
Editorial |
InBis |
The discussion of generating UUID node fields without using the IEEE 802 address in section 6.4.1 can be moved to an appendix. |
Mark D. Anderson raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0234.html |
|
|
16 |
OPTION_WITH_DEPTH |
Change |
Closed |
Should the Depth header be usable with OPTIONS to perform a query of the capabilities of all resources in a hierarchy? |
Mark D. Anderson raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0234.html Further discussion at: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0089.html |
No support for this change. See: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0107.html |
|
17 |
OVERLAP_5.3_AND_8.7.2 |
Editorial |
Closed |
There is some overlap in text between section 5.3 and 8.7.2 which can safely be removed. |
Mark D. Anderson raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0234.html |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2003AprJun/0106.html |
|
18 |
PUT_FOR_NON_COLLECTION_RES |
Editorial |
InBix |
At present, the discussion of PUT for non-collection resources takes place in the section on PUT for collections. It should be moved. |
Mark D. Anderson raised this issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0234.html |
|
|
19 |
NEED_FOR_PUTL |
Change |
Closed |
Is there a need for a PUTL (put which succeeds only if the resource is locked) method to avoid certain classes of overwrite conflicts, or a need to restrict the behavior of PUT on WebDAV servers to only accept writes if the resource is locked? |
Originally raised by Sanford Barr: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JanMar/0186.html Further discussion at: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0090.html |
No support for this change. See: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0108.html |
|
20 |
XML_LANG_CLARIFY |
Change |
InBis |
The requirement for xml:lang is not as precise as it should be, and needs tightening to account for the xml:lang attribute appearing earlier in a message body than a property value element. |
Raised by Jim Davis: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0203.html |
Not quite clearly resolved at: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0318.html |
|
21 |
XML_NOT_VALID |
Editorial |
InBis |
The specification should explicitly note that the XML is not valid, and is only well-formed. |
Raised by Jim Davis: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0055.html |
|
|
22 |
COPY_OVERWRITE_LOCK_NULL |
Change |
Closed |
If URL Ub is locked, creating a lock-null resource, then if a COPY is performed listing Ub as the destination, COPY will remove the lock-null resource, removing the lock, then perform the copy. A note needs to be added stating that the delete performed by the Overwrite header is atomic with the rest of the operation. |
Raised by Jim Davis: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0244.html |
LNR’s removed. See discussions preceding conclusion: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0128.html |
|
23 |
ALLPROP_AND_COMPUTED |
Editorial/Change |
InBis |
If a server has some computed properties which are expensive to compute, then PROPFIND allprop, especially PROPFIND allprop with Depth infinity can be an expensive operation. There should be an implementation note added to the document noting this problem. Suggestion that servers might want to be conservative in their implementation of such compute expensive properties. Clients should only perform PROPFIND allprop when necessary, not by default. |
Raised by Ken Coar during Advanced Collections breakout at Orlando IETF. Also, see discussion starting at: http://lists.w3.org/Archives/Public/w3c-dist-auth/2000OctDec/0023.html Further discussion at: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0109.html |
2518bis does not deprecate ALLPROP, just redefines it to have the server limit what it returns: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0032.html |
|
24 |
COPY_LIVE_PROPS |
Change |
InBis |
For some live properties, if the server is unable to maintain the liveness of the property at the destination of a copy, it is harmful to perform an octet-for-octet copy of the contents of the live property as a dead property. One example is the lockdiscovery property. In some cases (e.g., lockdiscovery), it is harmful to copy the value of the property at all, since the presence of lockdiscovery is related to whether the resource supports LOCK, not whether the server supports the lockdiscovery property. It is possible that sometimes the rules for copy may be different from the rules for move. It may also be the case that copy/move behavior can only be specified on a per-property basis, and no generalizations are possible. – Note by Julian Rescke on July 4, 2002 suggests that we define properties clear enough that the behavior for COPY/MOVE is clear. |
Raised by Larry Masinter: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0293.html Further clarification by Judy Slein: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0025.html |
Resolved: 7/25/02 & 8/1/02: COPY should do the equivalent of a GET/PROPFIND followed by PUT/PROPPATCH. It should be noted that the resulting resource might not behave in the same manner as the original. An example of this is variant processing where the COPY only copies one of the variants. – MOVE should maintain the integrity of the resource in that all live properties and behaviors should remain live and have the same semantics at the new location as at the old location. If there is any doubt “same” is defined according to the author’s concept of “this resource”. |
|
25 |
LOCK_REFRESH_BY_METHODS |
Change |
InBis |
The specification requires a lock to be refreshed if any method is executed, by anybody, on a locked resource. This can cause some performance problems. More importantly, the semantics of this refresh do not seem to be right -- why should a random GET by a third party cause all locks to be refreshed? |
Raised by Jim Amsden. |
We should remove the mention of this behavior in 2518: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0137.html |
|
26 |
MULTISTATUS_FOR_NON_DEPTH |
Change |
Closed |
At present, the specification is mostly silent on whether a 207 response can be returned by methods which do not use the Depth header, and which are not returning property values (PROPFIND). 207 should not be returned in this case, and the spec. should explicitly mention this. |
Raised by Joe Orton: http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0314.html |
|
|
27 |
LIVE_AND_NON_LIVE |
Editorial |
InBis |
The specification should explicitly state which properties are live, and which are non-live. |
Raised by Judy Slein: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0025.html |
Lisa has entered a clarification in 2518bis for each property. |
|
28 |
302_AND_MULTISTATUS |
Change |
InBis |
The HTTP 302 response also returns the Location header, which a client uses to determine where to redirect itself. The multistatus response does not have any mechanism for returning the Location header information. This is a problem for redirect references in the Advanced Collections specification. |
Raised during the Advanced Collections conference call, 1/14/99. |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2003AprJun/0106.html |
|
29 |
MKCOL_AND_302 |
Editorial |
Open |
The specification is ambiguous on the handling of 302 by MKCOL. It should explicitly state that MKCOL is redirected by a 302. |
Raised during the Advanced Collections conference call, 1/14/99. |
|
|
30 |
IMPLIED_LWS |
Editorial |
Open |
The specification should explicitly note that the HTTP implied linear whitespace rule also applies to productions in the WebDAV specification. |
Raised by Jim Davis in private email, 1/31/99. |
|
|
31 |
PUT_AND_INTERMEDIATE_COLLECTIONS |
Change |
Open |
HTTP/1.1 allows PUT to create intermediate collections during PUT operation. WebDAV explicitly forbids this. This may cause problems with non-DAV-aware HTTP/1.1 authoring clients which depend on this behavior, even though the behavior is not guaranteed by HTTP/1.1 PUT. |
Raised by Yoram Last: |
|
|
32 |
INTEROP_DELETE_AND_MULTISTATUS |
Change |
Open |
An HTTP/1.1 authoring tool which issues a DELETE to a WebDAV server might receive a 207 MultiStatus response, which it would not understand. Following rules in the HTTP specification, it would then treat the 207 as a 200 (OK), and incorrectly assume the operation succeeded. |
Raised by Yoram Last: |
|
|
33 |
OVERWRITE_DELETE_ALL_TOO_STRONG |
Change |
Open |
A COPY or a MOVE with Overwrite set to True will perform a DELETE with Depth infinity at the destination of the operation. However, in the same situation, most OS’s will perform a merge, rather than a DELETE. It is feared the DELETE is counter to user’s expectations. |
Raised by Kevin Wiggen: |
|
|
34 |
WHEN_TO_MULTISTATUS_FOR_DELETE_1 |
Change |
Open |
If a DELETE is issued to a collection, and it fails on all resources contained by the collection, and on the collection itself, a server should report just a single 4xx status code. But, instead the definition of DELETE indicates it should return a multistatus since an error occurred on a resource other than the Request-URI. The language needs to be tweaked so a multistatus is not required in this case. |
Raised by Yoram Last: |
|
|
35 |
WHEN_TO_MULTISTATUS_FOR_DELETE_2 |
Change |
Open |
If a DELETE is issued to a collection, and it succeeds on all resources except the Request-URI, then it is OK for the server to report a single failure code. A multistatus response should be returned instead, and the language of DELETE should be tweaked so this is the case. |
Raised by Yoram Last: |
|
|
36 |
DATE_FORMAT_GETLASTMODIFIED |
Change |
Open |
RFC 2518 specifies that the DAV:getlastmodified property must have the format specified by the HTTP-date production in RFC 2068. However, HTTP-date allows three date formats, rfc1123-date, rfc850-date, and asctime-date. Since RFC 2068 requires clients to accept all three time formats, this creates some ambiguity for whether WebDAV clients should also accept all three. The WebDAV specification should be updated to clarify that only the rfc1123-date production should be used in DAV:getlastmodified. |
Raised by Joe Orton: |
|
|
37 |
DEEP_LOCK_ERROR_STATUS |
Change |
Open |
Section 8.10.4 states that if a lock cannot be granted to all resources in a hierarchy, a 409 status response must be issued. Yet, the example in section 8.10.10 which demonstrates this uses a 207. |
Raised by Kevin Wiggen: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0196.html |
|
|
38 |
OVERWRITE_DELETE_ERROR_STATUS |
Editorial |
Open |
If a COPY or MOVE is submitted on a collection with Overwrite=T, if an error occurs during the delete processing associated with the Overwrite header, causing the entire operation to fail, what status should be returned? |
Raised by Kevin Wiggen: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0196.html |
|
|
39 |
MISSING_LOCK_TOKEN |
Editorial |
InBis |
Section 8.10.1 explicitly states that the response from a successful lock request MUST include the Lock-Token header, yet the examples in 8.10.8, 8.10.9, and 8.10.10 aren't compliant with this requirement, and should be updated. |
Raised by Keith Wannamaker on the dav-dev list: |
Make obvious editing changes to the examples: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0229.html |
|
40 |
LOCK_ISSUES |
Change/Editorial |
Open |
Jason Crawford's list of lock issues sent to the list. |
Raised by Jason Crawford: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html |
|
|
41 |
INFINITY_USE_IN_XML |
Editorial |
InBis |
Examples 8.10.8 and 8.10.9 use "Infinity" inside the Depth XML element, yet the spec. says this should be "infinity". The examples should be changed. |
Raised by Keith Wannamaker on the dav-dev list: |
Fix examples. |
|
42 |
MULTISTATUS_FROM_MKCOL |
Change |
Open |
If MKCOL is submitted with an entity body, as permitted by RFC 2518, to create a collection and populate it, then it would make sense to return a 207 Multistatus for errors. This possibility should be made more clear in the specification. |
Raised by Jim Amsden: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0222.html |
|
|
43 |
NULL_LOCK_SLASH_URL |
Change |
Closed |
If a URL ending in a slash is null locked, is it legal to do a PUT to it? That is, does the URL ending in slash set the resource type to a collection, or does the first PUT/MKCOL set the resource to a ordinary, or collection resource. |
Raised by Kevin Wiggen: (Point #4) |
LNR’s removed. See discussions preceding conclusion: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0128.html |
|
44 |
REPORT_OTHER_RESOURCE_LOCKED |