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 |
Change |
Open |
In some cases, such as when the parent collection of a resource is locked, a 423 (Locked) status code is returned even though the resource identified by the Request-URI is not locked. This can be confusing, since it is not possible for a client to easily discover which resource is causing the locked status code to be returned. An improved status report would indicate the resource causing the lock message. |
Raised by Kevin Wiggen: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0039.html (Point #1) |
|
|
45 |
DTD_BOOBOO |
Change |
InBis |
The keepalive element in the DTD is not correctly specified according to XML DTD rules. |
Raised by Ashish Agrawal: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0004.html Also noted by Juergen Reuter: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0198.html |
Resolved to remove dav:keepalive due to no implementations and apparent lack of interest in it: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0156.html |
|
46 |
NS_BOOBOO |
Editorial |
InBis |
In section 23.4.2, in the second example it uses the ns prefix of bar but it only defines a prefix of del... which it doesn't use. |
Raised by Jason Crawford: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0247.html Also noted by Frank Dawson in personal email. |
|
|
47 |
COPY_INTO_YOURSELF_CLARIFY |
Change |
Open |
RFC 2518 doesn’t explicitly specify how to handle the case where a COPY with Depth infinity has a destination that is within the source hierarchy. For example, a COPY of Depth infinity of /A/ into /A/B/. One resolution is to state that the copy must behave as if the resources are first copied to a temporary location, then moved from the temporary location into the destination. |
Raised during the Sept. 29, 1999 Advanced Collections teleconference. |
|
|
48 |
MISSING_NS_SPEC |
Editorial |
InBis |
In the example in Section 8.1.1, the properties R:DingALing and R:Random have not had the namespace specifier “R” defined within their scope, and hence another xmlns:R=“http://www.foo.bar/boxschema/” will need to be added. |
Caught by Juergen Reuter: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0198.html |
|
|
49 |
EXTEND_UNDEFINED |
Change |
Open |
The definition of the DAV header in section 9.1 uses a production called “extend”, which is undefined in either this, or the HTTP/1.1 spec. – |
Caught by Juergen Reuter: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0198.html also http://lists.w3.org/Archives/Public/w3c-dist-auth/2000AprJun/0057.html |
|
|
50 |
PUT_ON_COLLECTION |
Change |
Open |
Currently, the language in section 8.7.2 does not state that a PUT is permitted on a collection. On the flip side, it doesn’t state that this is forbidden either. It’s just silent. The spec. should explicitly state that PUT is (or is not) permitted on a collection. |
Raised during the Nov. 8, 1999 Advanced Collections breakout at IETF-46. |
|
|
51 |
LEVEL_OR_CLASS |
Editorial |
Open |
When describing compliance, the terms “level” and “class” are both used in the specification. Section 9.1 uses the term “level”, while Section 15 uses the term “class”. The specification should pick one and be consistent. |
Raised during the Nov. 8, 1999 Advanced Collections breakout at IETF-46. |
|
|
52 |
LOCK_BODY_SHOULD_BE_MUST |
Change |
Open |
Section 8.10.1 states that a LOCK method request SHOULD have an XML request body. This SHOULD should instead be MUST. |
Raised by Greg Stein: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0224.html |
|
|
53 |
LOCK_INHERITANCE |
Editorial |
Edit |
Section 7.5 states, “If a lock owner causes the URI of a resource to be added as an internal member URI of a locked collection then the new resource MUST be automatically added to the lock.” However, though this is the intent, the specification does not explicitly state that this behavior only applies to depth infinity locked collections. The words “Depth infinity” should be added before the word “locked” in this sentence. |
Raised by Jim Davis: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0250.html |
|
|
54 |
IF_AND_AUTH |
Editorial |
Open |
The fact that use of authentication credentials with submission of lock tokens is required should be strengthened in the document. |
Raised by Geoff Clemm: |
|
|
55 |
DISPLAYNAME |
Change |
Open |
There is confusion over the definition and use of the displayname property that has led to varying implementations. The default value of displayname should be specified. The behavior of displayname when there are multiple URLs for the resource needs to be clarified. |
Raised by Rickard Falk: |
|
|
56 |
DEPTH_LOCK_AND_IF |
Change/Editorial |
Open |
The specification is currently silent on how to use the If header for submitting a locktoken when performing a DELETE in a Depth infinity locked collection. Should the If header have both the collection URL and the Request-URI, or just the Request-URI? An example of this is needed. |
Raised by Joe Orton and Greg Stein on dav-dev list: |
|
|
57 |
LOCK_SEMANTICS |
Change/Editorial |
Open |
At present, the WebDAV specification is not excruciatingly explicit that writing to a locked resource requires the combination of the lock token, plus an authentication principal. At one point, the spec. discusses an “authorized” principal, but “authorized” is never explicitly defined. |
Raised at the Redmond, WA DeltaV design team meeting. |
|
|
58 |
LOCK_SEIZURE |
Change |
Duplicate |
Should it be possible to seize a lock, or for any principal to unlock a lock, thus making it easier for another client to begin working on a locked resource. |
Raised at the Redmond, WA DeltaV design team meeting. |
Duplicated by UNLOCK_BY_NON_LOCK_OWNER issue. |
|
59 |
PROPFIND_INFINITY |
Change |
Open |
If a client quickly submits multiple PROPFIND, Depth: infinity requests to the top of a collection tree containing many resources, it effectively forms a denial of service (DoS) attack. Though this is noted at a high level in Section 17.2 in Security Considerations, the specific risks of a large PROPFIND should be noted there. Additionally, the specification should note whether a server is allowed to have a configuration option to disable Depth: inifinity PROPFINDs. It has been recommended that 403 (Forbidden) be returned if a server does not support Depth: infinity PROPFIND. Integer values other than 0 and 1 in PROPFIND requests were also proposed. |
Raised by Hartmut Warncke, Greg Stein: |
|
|
60 |
LOCK_REFRESH_BODY |
Change |
Edit |
Section 7.8 of RFC 2518 indicates that clients may submit a lock refresh without a body. However, it implies that clients could submit a lock refresh with a body. Server implementations have been disallowing a lock refresh with a body. It might make sense to codify this practice, and disallow submission of a body on a lock refresh. |
Raised by Rickard Falk: |
Agreed: http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0124.html |
|
61 |
RESOURCETYPE_EXTENSION |
Change |
Open |
Both versioning and access control have a need to have multiple values within the DAV:resourcetype property. The specification needs to explicitly state that these multiple values are allowable, and that clients should expect this. At least one example should demonstrate that. |
Raised during the Pittsburgh IETF meeting, in the DeltaV and Access Control breakouts. |
Resolved: that the examples will include multiple resource types http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0102.html |
|
62 |
ETAG_CHANGES_IF_PROPERTIES_CHANGE |
Change |
2518bis |
If a property of a resource changes, should the etag change? |
Raised by Lisa D: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0052.html |
Thread: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0067.html The ETAG SHOULD normally not change with PROPPATCH changes. In some cases an implementation will not be able to help it though. (Follow thread to see if they agree it should only change if the GET response changes.) |
|
63 |
LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY |
Change |
Open |
Is the complexity of the IF header appropriate for the simple task of verifying that a client knowingly owns a lock? The IF header seems to serve a different purpose. One of those purposes is for the server to verify that you have the lock token (and that you know the root of it?). Another is for the client to check some preconditions before doing an action. Another seems to be to specify what lock to refresh in a lock refresh request. This seems to create ambiguity in our definition of the semantics of the IF: header. |
Raised by Jason Crawford: Feb 2001 |
Post: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0055.html : It is felt by the group that it’s important that the client not just own and hold the lock token, but that it also know where the lock is rooted before it does tasks related to that lock. This still leaves the lock referesh issue unresolved. |
|
64 |
OPTIONS_RESPONSE_VARIES_FOR_RESOURCES |
Change |
Open |
Should the response for an OPTIONS request be expected to vary from resource to resource? What should we proscribe? What about an example for file, directories and null resources? |
Raised by Kevin Wiggins: http://lists.w3.org/Archives/Public/ietf-dav-versioning/2001JanMar/0539.html |
|
|
65 |
UNLOCK_WHAT_URL |
Change |
Open |
What do you return if the unlock request specifies a URL on which the lock does not reside? What if it’s on a URL that is locked by the lock, but it’s not the resource where the lock is rooted? |
Raised by Juergen Pill: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0086.html |
Resolved that you can specify any URL locked by the lock you want to unlock. ( http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0027.html ) We should resolve the issue of UNLOCK’ing other URL’s in a few days. |
|
66 |
MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL |
Change |
Open |
Right now the server uses the IF: header to verify that a client knows what locks it has that are affected by an operation before it allows the operation. Must the client provide the root URL of a lock, any URL for a pertainent loc, or some specific URL in the IF: header. |
|
Post: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0055.html : It is felt by the group that it’s important that the client not just own and hold the lock token, but that it also know where the lock is rooted before it does tasks related to that lock. This is just a point of info. The issue itself still needs to be brought up and answered.still |
|
67 |
UNLOCK_NEEDS_IF_HEADER |
Change |
Open |
Shouldn’t we be using an IF header to do an UNLOCK seeing as you need to prove you are holding a lock before you can remove it? (This might be contingent on LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY) |
Raised by Dan Brotsky: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0099.html |
|
|
68 |
UNLOCK_WITHOUT_GOOD_TOKEN |
Change |
Open |
What should UNLOCK return if a bad token is provided or no token. (This might be contingent on UNLOCK_NEEDS_IF_HEADER.) |
Raised by Dan Brotsky: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0099.html |
|
|
69 |
URL_ENCODING_ISSUES |
Change |
Open |
We have to resolve some issues involving encoding methods for URI’s. The discussion is very involved. |
Raised by Greg Stein: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0081.html |
|
|
70 |
LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER |
Change |
Open |
The LOCK renewal request should not us an IF header to specify what lock is being renewed. This limits the use of the IF header. |
Raised by Dan Brotsky: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0109.html |
|
|
71 |
IF_HEADER_CHECKS_AFTER_OTHER_CHECKS |
Change |
Open |
Should we document if the IF header is evaluated before methods specific checks of afterwards. The IF header is said to be modeled after the IF-MATCH header and the documentation for that says that method specific checks should come first. It’s not clear if it’s feasible to make all method specific checks before checking the IF header. It’s also probably easier to implement IF header checks at a common layer of code that is called before the method specific code in many implementations. |
|
|
|
72 |
LOCK_URL_WITH_NO_PARENT_COLLECTION |
Change |
Edit |
If a LOCK request is submitted to a URL that doesn’t have a parent collection, what should be the correct response? Other methods, PUT, MKCOL, COPY, MOVE all require a 409 response in this case. Seems like LOCK should have this requirement as well. |
Raised by Dan Brotsky: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0134.html |
Resolved that since LNR’s no longer exist (see NULL_RESOURCE_CLARIFY) the server should return 409. We should insure that the new text we add to replace LNR’s does not create an ambiguity: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0164.html |
|
73 |
LOCKDISCOVERY_ON_UNLOCKED_RESOURCE |
Change |
Open |
If the DAV:lockdiscovery property is requested from an unlocked resource, what is the correct response? Apache mod_dav responds with an empty mod_dav sends an empty lockdiscovery element (<D:lockdiscovery/>) while IIS sends an empty prop element (<D:prop/>), that is, it sends no lockdiscovery element at all. |
Raised by Hartmut Warncke: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0128.html |
|
|
74 |
PROP_ROUNDTRIP |
Change |
Open |
The specification is currently unclear as to how a server should handle the round-trip representation of property information. That is, if a client does a PROPPATCH/PROPFIND pair, what can it expect about the property value that is returned, as compared to the original property value it wrote? Some XML attributes have semantics that would allow a server to return XML that was semantically the same as the original, but was a different sequence of octets than the original. It is also possible that the protocol specification should be silent on this issue. An example of this ambiguity is whitespace. |
Raised during discussion of the PROP_ATTR issue: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0047.html http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0052.html |
|
|
75 |
GETLASTMODIFIED_UPDATE |
Change |
Edit |
RFC 2518 does not specify whether a (dead) property change causes an update to the getlastmodified property. It may, or it may not. It would be valuable to clients to specify the exact behavior of this property. |
Raised by Lisa Dusseault: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0138.html |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0077.html : Modifications to dead properties SHOULD NOT change the lastmodified property. See the wording in the discussion. |
|
76 |
XML_EMPTY_ELEM_LANG |
Change |
Edit |
RFC 2518 incorrectly states, in 23.3.1 that “it is a violation of the XML specification to use the <A></A> form if the associated DTD declares the element to be EMPTY”. This will be fixed to correctly reflect the XML recommendation. Additionally, language might be needed to reinforce what the XML rec actually does say. |
Raised by Geoff Clemm: http://lists.w3.org/Archives/Public/ietf-dav-versioning/2001AprJun/0159.html |
|
|
77 |
LOCK_NULL_STATUS_CREATION |
Change |
Edit |
What status code should be returned when a lock null resource is created – 200 OK or 201 Created? A related issue is what status code should be returned by a PUT or MKCOL on a lock-null resource? MKCOL is defined to be 201, PUT could be 200 or 201 (201 seems like a slightly better choice). |
Raised by Lisa Dusseault: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0267.html See also: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0299.html |
Resolved via the proposal to remove LNR and replace them with ordinary resources and by the following wording: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0129.html |
|
78 |
NULL_RESOURCE_CLARIFY |
Change/Editorial |
Closed |
The definition of a null resource should be changed to one that doesn’t use the term “resource” at all, and instead expresses it as an “unmapped URL”, thus meaning there is no implied state. |
Raised by Tim Ellison/Shaun Hall: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0282.html http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0281.html |
LNR’s removed. See discussions preceding conclusion: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0128.html |
|
79 |
UNLOCK_BY_NON_LOCK_OWNER |
Change |
InBis |
At present, the specification is not explicit about who might be capable of grabbing a lock token via lock discovery and the submitting it in UNLOCK (and/or for a subsequent write operation). It is OK for the resource owner to grab the lock token and do UNLOCK/write? Is it OK to have a “grab lock token” privilege that can be assigned to anyone? |
Raised by Lisa Dusseault in private email. |
Resolved in part by putting it under ACL control: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0002.html and the response that follows it. |
|
80 |
DEFER_LOCK_NULL_RESOURCES_IN_SPEC |
Change |
InBis |
Proposal to remove lock null resources from the spec until we are motivated to have them or something equivalent. In the meantime, keep the spec silent on the topic in order to avoid precluding LNR or the equivalent in a future version of WebDAV. |
Mentioned by many, and finally proposed by Geoff Clemm and supported by Jason Crawford: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0000.html |
LNR’s removed. See discussions preceding conclusion: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0128.html and http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0107.html |
|
81 |
TYPO_SEC8_9_6 |
Typo |
Edit |
Section 8.9.6 should speak of moving, not copying. |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0073.html |
|
|
82 |
CLARIFY_UNTAGGED_IF_HEADER_APPLICATION |
Change |
Open |
2518 says the untagged header should be applied to all resources involved in a request, but that is not defined. – There was also a proposal at the SLC IETF meeting to simply the IF header or move it to its own spec. – Also a proposal to remove UNTAGGED IF: header support. |
Raised by Geoff Clemm: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0159.html and IETF meeting: http://www.ietf.org/proceedings/01dec/minutes/WEBDAV.HTM |
|
|
83 |
PROPFIND_STATUS_ON_MISSING_DATE_PROPERTY |
|
Edit |
If a server doesn’t have a creationdate or lastmodifieddate available, what should it return if asked for this property or asked for all properties? |
Raised by Julian Reschke: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0248.html |
Concluded that a 404 NOT FOUND should be returned to indicate that the property is missing: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0159.html but we still need to resolve where/if that should be reflected in the spec. That can be a separate issue if it isn’t obvious to the RFC editor. |
|
84 |
AUTHENTICATION_TYPE_INSECURE |
Change |
Edit |
RFC2518 advocates Digest Authentication. There was some concern that although it doesn’t transmit the password in the clear, the password or password equivalent still has to reside in a file on the server basically in the clear. They can’t rely on that file being secure, and felt that Basic Authentication over SSL or other transport level security was a better option. |
Raised by Dylan Barrell: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0042.html |
This issue was contentious. The current resolution’s wording was roughly proposed by Jim Whitehead: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0143.html and discussion ended with http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0171.html |
|
85 |
ETAGS_ARE_QUOTED |
Change |
Edit |
RFC2518 section 8.1.1 has an example with an etag in it that isn’t quoted. It should be. All etags are quoted. |
Raised by Daniel Brotsky: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0214.html |
Resolved to fix it. |
|
86 |
PURPOSE_OF_NAMESPACE |
Change |
Closed |
Roy Fielding wasn’t clear why WebDAV uses namespaces and this led him to make some unfortunate conclusions about that aspect of WebDAV. |
Raised by Roy Fielding: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0299.html |
Resolved that we will not alter the spec, but this of course is an item that is suitable for an annotated spec: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0302.html |
|
87 |
DAV_WITH_COLON_IS_NOT_A_URI |
Change |
Closed |
The namespace URI “DAV:” is not a valid URI according to RFC 2396. This might cause problems with tools that justly expect a true URI as per the Namespace and URI specs. Also Julian has proposed the following wording so that other standards don’t follow our poor example: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0143.html |
Raised by Julian Reschke: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0193.html |
Resolved that Roy Fielding will try to get RFC 2396 updated to allows DAV: as a URI. We’ll need to check if this gets accepted: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0301.html |
|
88 |
DAVOWNER_FIELD_IS_CLIENT_CONTROLED |
Edit |
Edit |
The DAV:owner field of a lock is controlled by the locking client and should not be manipulated by the server. This is the only place the client can store info. The roundtrip details should match what we resolve for the PROP_ROUNDTRIP issue. Examples should also be checked. |
Raised in many places including the interop events. |
Resolved by repeated statement and no disagreement. . |
|
89 |
FINDING_THE_ROOT_OF_A_DEPTH_LOCK |
Edit |
Edit |
It would be good if a client could look at a locked resource that it was planning to unlock and also find out if it’s depth locked and where the depth lock is rooted. |
Concretely raised by Geoff Clemm: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0047.html |
Proposed solution: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0049.html approved. |
|
90 |
SECTION_12_4_MENTIONS_HREF_ELEMENT |
Edit |
Open |
Section 12.4 talks about an href element when describing the link element. There is no such element defined as a child of link. Fix this. |
|
|
|
91 |
NEW_MULTIPUT_METHOD |
Edit |
Review Discussion |
Review discussion of October 2001 to see if there is consensus around a MULTIPUT method. |
Raised by Jim Whitehead: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0094.html |
|
|
92 |
SOURCE_PROPERTY_UNDERSPECIFIED |
Edit |
Defered |
The concepts of dynamic resources and the details of the source property are not well defined and to some degree this might be limiting implementation. What is our policy on PUT on a dynamic resource? What/who creates the relationship between the source and the dest? How does a client know how to describe the constituent pieces of source in a UI? Are the src and dst reversed in 2518? What property values does PROPFIND return for a dynamic resource? Can the dav:source property be written by the client? -- There also was a proposal at the SLC IETF meeting to separate the DAV:source property in to it’s own spec. |
See discussion following: http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0094.html and a proposal at http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0119.html |
Almost resolved to remove the dav:source property from the spec to give us a clean slate to work with if we want to add a more completely specified version of that functionality later. – It looks like there might be an effort to define it as of 5/13/02. See: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0099.html -- 8/27/02 still no interoperable implementations. |
|
93 |
HOW_DOES_A_CLIENT_DETERMINE_IF_IT_OWNS_A_LOCK |
Edit |
Closed |
How does a client determine if a given lock was created by it? |
Various discussions in the following thread: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0127.html |
It was resolved that this type of info would not be provided by the server. The client creating the lock could store owner info in the DAV:owner field (or some field defined in the future) if it wishes. The querying client can also check ACL’s to get similar info. |
|
94 |
IS_HREF_A_CHILD_OF_KEEPALIVE |
Edit |
Edit |
Is makes more sense for DAV:prop to be used as a child of DAV:keepalive rather than DAV:href. |
Raised by Julian Reschke: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0114.html |
Resolved to remove dav:keepalive due to no implementations and apparent lack of interest in it: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0156.html |
|
95 |
ADD_AN_ERRORCODE_APPENDIX |
Edit |
Edit |
At the Salt Lake City IETF meeting it was agreed to add an appendix of error codes in RFC 2518. I should be copyable from the Versioning spec. |
|
See description. |
|
96 |
SHARED_LOCKS_INTEROP_NOT_TESTED |
Edit |
Closed |
There might not be any implementations of shared locks. If so, remove them |
Lisa Dusseault inquired if they are being used: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0165.html |
The thread did conclude that shared locks interoperate although it doesn’t look like they get used much. Also see: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0139.html |
|
97 |
DUPLICATE_PROPERTIES |
Edit |
Edit |
A server should only support a single property with a given name. For example, there should only be one DAV:lockdiscovery property even if there are multiple locks on a resource. |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0220.html |
Agreed. |
|
98 |
DAV_XML_NAMESPACE_IS_RESERVED |
Edit |
Edit |
The Versioning spec says that only XML elements documented in the WebDAV spec can use the DAV: namespace. |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0206.html |
Resolved in that discussion that only the spec can use the DAV: namespace. |
|
99 |
COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION |
Edit |
Edit |
What resource should be flagged in the multistatus response to locking issues in COPY/MOVE requests? |
Re-Raised: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0079.html |
Resolved to flag the locking errors at the source resource that was affected by the problem. The details of how to describe the error was deferred to a subsequent version of WebDAV. – 6/15/02 – 2518bis does not reflect this. |
|
100 |
COPYMOVE_LOCKED_STATUS_DESCRIPTION |
Edit |
Version2 |
The method of describing the details of (beyond what resolved by COPYMOVE_LOCKED_STATUS_CODE_CLARIFICATION) of the underlying cause of various locking and ACL COPY/MOVE problems is deferred. Two proposals were outlined in the discussion, but interest was not great and we clearly don’t have interoperability to take these proposals forward. |
First proposal: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0079.html |
|
|
101 |
LOCKDISCOVERY_FORMAT_FOR_MULTIPLE_SHARED_LOCKS |
Edit |
Edit |
There is some confusion on how a PROPFIND response should express the fact that a resource has multiple shared locks on it. It was suggested that the spec become clearer. |
Raised by Julian Reschke: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0215.html |
Resolved trivially that it’s probably worthwhile to demonstrate a correct response for this situation in one of the examples. |
|
102 |
HOW_DO_WE_ENCODE_FILENAMES_AS_URLS |
Add |
Open |
It has been suggested that WebDAV should define the mapping of external names (file system names for example) to URL encoded names. |
Raised by Larry Masinter: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0204.html |
|
|
103 |
SHOULD_A_SERVER_DETERMINE_MIMETYPE_OF_CONTENT |
Add |
Open |
How should the mimetype of the PUT request affect the mimetype of subsequent GET requests? Should it be remembered? If so, does the last PUT request take priority? Or the first? Or do we leave that unspecified? The solution should include coverage of what kind of resource should get created if one locks an unmapped URL. |
Raised by Dan Brotsky in the following thread: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0209.html |
|
|
104 |
CAN_HREF_BE_RELATIVE |
Edit |
Open |
Can DAV:HREF be a relative URI? If so, can the spec specify what it’s relative to? |
|
Partially resolved: Agreed that it can be relative, but no significant discussion on what it is relative to: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0241.html |
|
105 |
ADD_DEPTH_ZERO_DELETE |
Wish |
Open |
It has been suggested that we should have the ability to delete at depth zero. |
Suggested by Geoff Clemm et al: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0152.html |
|
|
106 |
INTEROPERABILITY_OF_102PROCESSING_STATUS_DEMONSTRATED |
Edit |
Open |
Have we demonstrated interoperability of the “102 Processing” status response code? |
Discussion begins with: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0169.html |
|
|
107 |
IS_XMLSPACE_SIGNIFICANT |
Edit |
InBis |
Should the xml:space attribute be respected. 2518bis on 6/1/02 says it should not. There is some debate on this. |
Re-raised: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0137.html |
The conclusion of the May/June 2002 discussion was that white space is significant: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0152.html |
|
108 |
HOW_ARE_TRAILING_SLASHES_USED |
Edit |
Open |
There are all kinds of issues with trailing slashes. Can a client simply add or remove them? Does a server treat two URL’s only differing by trailing slashes? Should a server redirect to the preferred URL? |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0201.html |
|
|
109 |
HOW_TO_FIND_THE_ROOT_OF_A_LOCK |
Edit |
Edit |
If one finds a locked resource, it might be one of several resource locked by a depth lock. How does one determine the root of the lock? |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0049.html |
Resolved to support a dav:lockroot element in the lock discovery property: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0053.html |
|
110 |
REMOVE_ETAG_SUPPORT_FOR_IF_HEADER |
Edit |
Open |
It was suggested that we remove the ETAG support in the IF header because it doesn’t seem to be used right now (no interop) and the same thing can be achieved via other mechanisms. |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0045.html |
In that thread it seems to be almost resolved that we eliminate the ETAG support from IF: headers in that anyone who cared seemed to prefer removing it, but the discussion got diverted and no final decision was made. Again on http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0081.html but it was actively used in subsequent discussions on the IF: header and strongly advocated there Sept/Oct 2002. |
|
111 |
MULTIPLE_TOKENS_PER_LOCK |
Edit |
Edit |
12.1.2 states that a dav:locktoken tag can have multiple <dav:href> tags in it. Is this right? And is it trying to suggest that a single (shared) lock might have multiple locktokens? |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0050.html |
It is resolved that section 12.1.2 was incorrect and that only a single lock token URI should be allowed there. Also it is resolved that a lock only has a single lock token. |
|
112 |
SHOULD_WE_SUPPORT_IRIS_AND_CHARMOD |
Edit |
Open |
There are various recent documents about internationalization of standards. We should see if we’re compliant with the IRI (internationalized resource identifiers, draft-durst-iri-00) and charmod and if we’re not, what it would take to bring us in to compliance. |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0070.html |
Jason and Lisa have begun reading. IRI’s look like they might become a problem. Further reading necessary. |
|
113 |
ORDER_OF_HEADER_EVALUATION |
Edit |
Open |
It was suggested that we require that the authetication and permission information for a request be evaluated before the If: header. This allows one to test if a long operation will succeed by submitting an equivalent shorter one with a false If: header. |
Summarized by Geoff Clemm: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0369.html |
|
|
114 |
ENCOURAGE_USE_OF_COOKIES |
Edit |
Rejected |
It was suggested at the Sept 2002 Interop that clients be required to support cookies. It was suggested that is can enhance security. |
Presented by Lisa Dusseault: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0274.html |
Was unanimously rejected on the list in the ensuing discussion. |
|
115 |
IF_HEADERS_CAN_GET_LONG |
Edit |
Open |
If headers can become quite long. We need a way to make sure we don’t exceed the maximum header length. |
Geoff Clemm: Point 2 of http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0039.html |
|
|
116 |
EVALUATE_ALL_OF_IF_HEADER |
Edit |
Open |
2518 says that a server only needs to evaluate the portions of the If: header that it finds appropriate. This underminds the stated primary purpose of the If header: for the client to submit assertions on the request because the server might ignore a few assertions and just go ahead with a request and the client doesn’t know if the assertions were evaluated or not. |
Jason Crawford: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0083.html |
Approved heartily right after proposed. |
|
117 |
REMOVE_UNTAGGED_IF_HEADER |
Edit |
Open |
It was propose to remove support for untagged IF headers in order to simplify the If: header. |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0025.html |
|
|
118 |
REQUIRE_UTF16 |
Edit |
Edit |
It was resolved to have servers and clients support UTF-16 in addition to UTF-8. |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0094.html |
Thread resolved to require support of both UTF-8 and UTF-16 on both clients and servers. |
|
119 |
SUPPORT_IRI_SPEC |
Edit |
Edit |
It was resolved to support the IRI and WebCharacterModel specs in some way. |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0069.html and http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0113.html |
The thread resolved a few things about what the spec should say about encodings and such. |
|
120 |
REMOVE_NOT_SUPPORT_FROM_IF_HEADERS |
Edit |
Open |
There doesn’t seem to be many (or any?) clients that use the NOT support of the If Header. Thus we have no interop testing. – Yet it was mentioned as something that might be helpful to let clients submit lots of lock tokens in discussions on rewriting the IF: header in October 2002. Those discussions are complete as of entry of this issue in this file. -- |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0087.html |
|
|
121 |
HOW_DOES_WEBDAV_SUPPORT_VARIANTS |
Edit |
Open |
A discussion thread was started. Let’s not forget about it. |
|
|
|
122 |
DAV_ERROR_SUPPORT |
Edit |
Open |
It was suggested that 2518 adopt the DAV:error support that the WebDAV versioning spec (rfc3253) supports. See that spec and search on “error” and “must-be”. |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0114.html |
|
|
123 |
XML_GUIDELINES_CONFORMANCE |
Edit |
Open |
The IESG has approved the Internet-Draft 'Guidelines for The Use of XML within IETF Protocols' <draft-hollenbeck-ietf-xml-guidelines-07.txt> as a BCP. This has been reviewed in the IETF but is not the product of an IETF Working Group. We need to evaluate if we are in compliance with these guidelines |
|
|
|
124 |
XML_ENTITY_DOS |
Edit |
Open |
recursive entity declarations can be used for effective DOS attacks, and thus WebDAV MUST allow servers to reject these kind of requests, even though they may be well-formed). |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0402.html |
|
|
125 |
CLARIFY_INTERNAL_MEMBER_URI_SEGEMENT |
Edit |
Edit |
The binding proposal changes the definition of a member of a collection a bit. Each binding has a URI segment associated with it. In 2518 right now it says that each internal member contains an associate URI. This needs to be adjusted to speak of a segment, not a whole URI. |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2003AprJun/0128.html |
|
|
126 |
DAV_REQUEST_HEADER |
Edit |
Edit |
RFC 2518 provides a mechanism (the "DAV" response header) for a server to indicate to a client that it supports a specific WebDAV option (e.g. "1", "2", "version-control", etc.), but there is no complementary mechanism for a client to indicate to a server that it understands a specific WebDAV option. This becomes an issue when a WebDAV extension (or revision) needs to change response formats in a way that possibly break existing clients. Detecting client features based on a single, well-defined request header will work better than (for instance) relying on custom headers (specified by each extension) or "User-Agent". Suggested resolution: allow
the use of the "DAV" header as a request header, with the same set
of values that are defined for the "DAV" response header. |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0060.html |
http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0060.html |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Last
modified: 3/13/03 by jlc