The identifier is a name for the issue (and is unique within this document).
The type of issue is one of:
The status of the issue is one of:
The reference is an indication of where the issue was first raised.
The description is a succinct overview of the issue.
The resolution describes the specification change that resolves the issue.
| Identifier | Type / Status | Reference and Description | Proposed Resolution / Latest Change |
|---|---|---|---|
| edit |
edit open |
julian.reschke@greenbytes.de, 2004-10-03: Umbrella issue for editorial changes. | latest change in revision latest |
| Identifier | Type / Status | Reference and Description | Resolution / Latest Change |
|---|---|---|---|
| 11.2-apply-to-redirect-ref-syntax |
change closed |
julian.reschke@greenbytes.de, 2003-10-17: Many toolkits have problems sending empty HTTP headers (optimizing them away). | in revision 06: Define values "T" and "F" (similar to WevDAV Overwrite header). This will also allow clients to express that they are aware of redirect extensions without also having to apply the request to the reference resource. |
| 12.1-property-name |
change closed |
julian.reschke@greenbytes.de, 2003-10-06: Sync names for DAV:reftarget property and "Redirect-Ref" response headers. | in revision 10: Retracted (see http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0010.html). |
| 13_allprop |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0051.html> julian.reschke@greenbytes.de, 2004-11-13: Make the spec consistent with RFC3253, RFC3648 and RFC3744 (new properties not returned upon PROPFIND/allprop requests). |
in revision 11: Add statement about PROPFIND/allprop behaviour. |
| 15.1-options-response |
change closed |
julian.reschke@greenbytes.de, 2003-10-20: Fix OPTIONS response ("Public" header mentioned, "Allow" header value line break). Remove irrelevant response headers. | in revision 06: Fix. |
| 3-terminology-redirectref |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0290.html> julian.reschke@greenbytes.de, 2003-07-27: Consider global rename of "redirect reference resource" to "redirect resource". |
in revision 10: Retracted (see http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0009.html). |
| 5_mkresource |
change closed |
julian.reschke@greenbytes.de, 2004-01-04: Umbrella issue for all changes caused by replacing the generic MKRESOURCE method by MKREDIRECTREF. | in revision 08: |
| 8.1_deep_lock_complexity |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005AprJun/0141.html> jbaumgarten@apple.com, 2005-06-27: ...In particular, the failure of locking methods that contain redirected resources would confuse our clients. Instead, we have decided to implement a simpler redirect capability via a custom property (not a WebDAV resource type) that is only activated when indicated by the client request. julian.reschke@greenbytes.de, 2005-07-03: Analysis of issue in http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JulSep/0005.html. |
in revision 13: Make all methods except PROPFIND and REPORT default to "Apply-To-Redirect-Ref: T". |
| 9-MKRESOURCE-vs-relative-URI |
change closed |
julian.reschke@greenbytes.de, 2003-10-08: Do not say anything about MKRESOURCE vs relative URIs. The server is supposed to store the relative URI, thus the issue of resolving the URI does only apply upon retrieval, not creation. | in revision 06: |
| A_DTD_cleanup |
change closed |
julian.reschke@greenbytes.de, 2003-11-18: Cleanup DTD. | in revision 08: |
| abnf |
change closed |
julian.reschke@greenbytes.de, 2005-02-09: Use ABNF syntax from RFC2234. | in revision 12: Go back to RFC822+RFC2616extensions. |
| dtd-changes |
change closed |
julian.reschke@greenbytes.de, 2005-05-07: Remove "Changes to the WebDAV Document Type Definition". Section "Extensions to the DAV:response XML Element for Multi-Status Responses" already all information needed. | in revision 12: Done. |
| frag_in_target |
change closed |
julian.reschke@greenbytes.de, 2005-02-12: The errata to RFC2616 (see http://skrb.org/ietf/http_errata.html#location-fragments) explicitly allow fragments in Location headers; so the spec needs to allow authoring them. | in revision 12: |
| headerreg |
change closed |
julian.reschke@greenbytes.de, 2005-08-24: Add RFC3864 registrations for new HTTP headers. | in revision 13: |
| lc-01-body |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0188.html> joe@orton.demon.co.uk, 2000-01-26: Entity Bodies for Redirect References: Clarify: Are there 2 resources, one that redirects and one that responds with its own entity body? Clarify: What is the effect of PUT for a URI that currently maps to a redirect reference? |
in revision 04: Redirect resource MUST NOT have a body. See also issue last call issue 23. |
| lc-01A-body |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0188.html> joe@orton.demon.co.uk, 2000-01-26: In the definition of MKRESOURCE, "Body" needs to be defined or else terminology changed. |
in revision 04: We will use MKREF instead of MKRESOURCE. |
| lc-02-status-codes |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0222.html> joe@orton.demon.co.uk, 2000-01-29: List only new status codes for MKRESOURCE. Don't discuss previously-defined status codes. |
in revision 03: Follow same practice as in binding spec: for existing status codes, describe new circumstances that might cause them. Make it clear that we are not redefining these codes. |
| lc-03-mkresource-response-cacheability |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0191.html> joe@orton.demon.co.uk, 2000-01-26: Saying that responses to MKRESOURCE SHOULD NOT be cached suggests that there are sometimes good reasons to cache responses. Is this the case? |
in revision 03: Responses to MKREF MUST NOT be cached. |
| lc-04-standard-data-container |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0189.html> joe@orton.demon.co.uk, 2000-01-26: "Standard data container" needs to be defined in the context of MKRESOURCE |
in revision 05: Not relevant once we switch to MKREF. |
| lc-05-standard-data-container |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0189.html> joe@orton.demon.co.uk, 2000-01-26: Inconsistency about whether a "standard data container" can be created with MKRESOURCE or not. |
in revision 05: Not relevant once we switch to MKREF. |
| lc-06-reftarget-relative |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0222.html> joe@orton.demon.co.uk, 2000-01-29: Why does the spec talk about relative URIs in DAV:reftarget in MKRESOURCE requests? Is the server required to resolve the relative URI and store it as absolute? Is the server required to keep DAV:reftarget pointing to the target resource as the reference / target move, or is DAV:reftarget a dead property? |
in revision 06: DAV:reftarget is readonly and present only on redirect references that are also WebDAV resources. Add a method for setting the target. Change definition of Redirect-Ref header so that it has the target as its value (comes back on all 302 responses). Server MUST store the target exactly as it is set. It MUST NOT resolve relatives to absolutes and MUST NOT update if target resource moves. See also issue 17, 43, 50, 57 |
| lc-07-bind |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Abstract should discuss only redirect references, not bindings. Expand discussion of redirect references. |
in revision 04: Abstract will discuss only redirect references. See also issue 34. |
| lc-08-bind |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Get rid of cross-references to the binding spec: in the abstract, in the introduction, in the definition of Reference Resource. |
in revision 04: Cross-references to bindings will be removed. See also issue 34. |
| lc-09-notational-after-introduction |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Move Notational Conventions after Introduction. |
in revision 03: Section will be moved. |
| lc-10-title |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Change the title of 16.4 so that it is not a sentence. |
in revision 03: Change to "Revealing Private Locations". |
| lc-11-pagination |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Don't paginate the review draft. |
in revision 03: We will paginate in accordance with IETF rules, but will try to produce a nicely formatted review spec as well. |
| lc-12-bind |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: First 3 paragraphs of Introduction are identical to those in binding spec. Make sure that any changes made there are also incorporated here. |
in revision 04: These paragraphs will change as necessary to make the redirect spec completely independent of the rest of WebDAV. |
| lc-13-usually |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Intro, para 4: Change "usually" to "possibly" in the sentence "A redirect reference resource is a resource in one collection whose purpose is to forward requests to another resource (its target), usually in a different collection." |
in revision 03: Agreed. |
| lc-14-bind |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Limit the discussion of bindings to just what is needed to understand the differences from redirect references. Maybe the paragraph in the Intro that starts "By contrast, a BIND request . . ." is all that is needed. |
in revision 04: Get rid of discussion of bindings altogether. See also issue 34, 35. |
| lc-15-direct-ref |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Don't define Direct Reference Resource, since direct references are out of scope. (If you do keep the definition, say explicitly that a direct reference resource is a type of reference resource.) |
in revision 04: Remove definition of Direct Reference Resource. See also issue 39. |
| lc-16-insure |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Section 4, para 2: Change "It is also what insures" to "It is also what helps to insure". |
in revision 03: Agreed. |
| lc-17-location |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Section 4, para 3: Clients should use the Location header, not the DAV:reftarget property, to find the location of the target. The purpose of the DAV:reftarget property should be to let the client update its value. |
in revision 03: We need both Location (which is absolute) and target (which may be relative). See also issue 6, 43. |
| lc-18-resource-types |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Need a registration procedure for resource types to insure interoperability. |
in revision 03: We won't hold up this spec to establish a registration procedure. We will mention in IANA considerations that as the number of resource types grows the need for a registration procedure increases, but that there is none at this time. |
| lc-19-direct-ref |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Section 4, para 5 and Section 6, para 3 discussions of the Apply-to-Redirect-Ref header make it sound as if we are specifying direct reference behavior. |
in revision 07: Change these passages so that the contrast is between applying the method to the redirect reference and responding with a 302. |
| lc-20-intro-mkresource |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Section 5: Start with "The new MKRESOURCE method" to make it clear that it is being introduced for the first time here. |
in revision 05: Say "The MKREF method defined normatively here . . ." |
| lc-21-bind |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Get rid of the binding-dependent language in the last para of Section 5. |
in revision 03: Delete all but the first sentence in this paragraph. |
| lc-22-coll |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Inconsistency about whether collections can be created with MKRESOURCE. |
in revision 05: (1) Strip all non-redirect-ref functionality from MKRESOURCE, then (2) later switch to a new method. |
| lc-23-body |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Section 5.1: Get rid of the statement that the body of the resource is empty (PostConditions). It would be good if the response to GET included a response body that could be shown to a user by a client that doesn't do automatic redirection. There is a related problem in Section 6 on PUT. It is wrong to assume that what is PUT to a resource is what GET will return. In Section 6, say "A PUT with Apply-To-RR MAY contain a request body. The semantics of the request body is out of scope for this specification..." Also fix the discussion of example 6.2. |
in revision 05: Redirect references cannot have bodies. GET with Apply-To-RR MUST fail with 403. PUT with Apply-To-RR MUST fail with 403. See also issue 1. |
| lc-24-properties |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Section 5.1: Replace the sentence "The properties of the new resource are as specified by the DAV:propertyupdate request body, using PROPPATCH semantics" with the following: "The MKRESOURCE request MAY contain a DAV:propertyupdate request body to initialize resource properties. Herein, the semantics is the same as when sending a MKRESOURCE request without a request body, followed by a PROPPATCH with the DAV:propertyupdate request body." |
in revision 08: MKRESOURCE will be replaced by simpler/more specific method. |
| lc-25-atomic |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Is MKRESOURCE atomic as viewed by a client? Can another client access the new resource's properties before they have been fully initialized? Maybe the MKRESOURCE request should let the client ask for it to be atomic. |
in revision 05: No longer relevant once we switch to MKREF with no request body. Also, as an intermediate step MKRESOURCE is defined to be atomic. |
| lc-26-lang |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Change "is not created" to "was not created" in para 4 under Postconditions of MKRESOURCE. |
in revision 03: Editor's discretion. |
| lc-27-lang |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Section 6: Change "non-referencing-aware clients" to "clients not aware of this protocol". |
in revision 03: Editor's discretion. |
| lc-28-lang |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Section 6: Get rid of the sentence "A reference-aware WebDAV client can act on this response in one of two ways." A client can act on the response in any way it wants. |
in revision 07: Agreed. See also issue 48. |
| lc-29-lang |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Section 6, para 4: Obvious, doesn't need to be stated. Maybe note in an example. |
in revision 07: Agreed. See also issue 48. |
| lc-30-headers |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Section 6, "When Apply-To-RR is used with GET or HEAD..." Either give a precise list of the headers that MUST be returned, or change MUST to SHOULD with the list of examples. |
in revision 03: Delete "along with all HTTP headers that make sense for reference resources (for example, Cache-Control, Age, Etag, Expires, and Last-Modified)." See also issue 48. |
| lc-31-MKCOL |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Section 6, para on MKRESOURCE and MKCOL is obvious and doesn't need to be stated. Maybe show in an example. |
in revision 04: Agreed. See also issue 48. |
| lc-32-ORDERPATCH |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0266.html> reuterj@ira.uka.de, 2000-02-07: Section 6. Don't talk about ORDERPATCH, since it hasn't been specified anywhere. |
in revision 03: Agreed. See also issue 48. |
| lc-33-forwarding |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0284.html> yarong@Exchange.Microsoft.com, 2000-02-11: Forwarding: Replace "forward" with "redirect" throughout. |
in revision 10: Original Resolution: Use "redirect" for the behavior redirect resources do exhibit. Use "forward" for the contrasting behavior (passing a method on to the target with no client action needed). Define these two terms. See also issue 40. Actual Resolution: change the text so that it always says "redirect" when we mean "redirect" and "forward" when we mean "forward"; do not add new definitions, though. |
| lc-34-bind |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0286.html> yarong@Exchange.Microsoft.com, 2000-02-11: NoBind: Remove all cross-references to the binding spec. Prefer also removing all mention of bindings. |
in revision 04: Agreed. See also issues 7, 8, 14 |
| lc-35-bind |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0287.html> yarong@Exchange.Microsoft.com, 2000-02-11: ReallyNoBind: Remove paras. 6 and 8 from Intro. |
in revision 04: Agreed. See also issue 14. |
| lc-36-server |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0285.html> yarong@Exchange.Microsoft.com, 2000-02-11: Servers: Replace "server" with "unrelated system" throughout. |
in revision 10: Originally proposed resolution: Try replacing "server" with "host" in some contexts, rephrasing in passive voice in others. See also issue 40. Actual resolution: replace or remove on a case-by-case basis; use "system" or "unrelated system" (host in RFC2616 terminology is something different). |
| lc-37-integrity |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0288.html> yarong@Exchange.Microsoft.com, 2000-02-11: Integrity: Intro, para 7 "Servers are not required to enforce the integrity of redirect references." Integrity is not defined. Replace with something clearer. |
in revision 08: Remove that sentence. Issue will be resolved as part of the resolution of "lc-57-noautoupdate". |
| lc-38-not-hierarchical |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0289.html> yarong@Exchange.Microsoft.com, 2000-02-11: Not Hierarchical: The first sentence of the second paragraph of the introduction of the redirect spec asserts that the URIs of WebDAV compliant resources match to collections. The WebDAV standard makes no such requirement. I therefore move that this sentence be stricken. |
in revision 08: State the more general HTTP rationale first (alternative names for the same resource), then introduce the collection hierarchy rationale, which applies only if you are in a WebDAV-compliant space. |
| lc-39-no-reference-or-direct-resource |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0290.html> yarong@Exchange.Microsoft.com, 2000-02-11: NoReferenceOrDirectResource: Remove the definitions of "Reference" and "Direct Reference Resource." Change the definition of "Redirect Reference Resource" to be: Redirect Resource: A resource created to redirect all requests made to it, using 302 (Found), to a defined target resource. julian.reschke@greenbytes.de, 2003-07-27: (Rename from "redirect reference resource" to "redirect resource" delayed for now). |
in revision 04: Agreed. See also issue 15. |
| lc-40-direct |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0291.html> yarong@Exchange.Microsoft.com, 2000-02-11: Assorted changes to Section 4, para 2 to get rid of the word "forward" and the word "server" and remove comparison with direct references. |
in revision 04: See also issue 33 (forward). See also issue 36 (server). Remove discussion of direct references. |
| lc-41-no-webdav |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0292.html> yarong@Exchange.Microsoft.com, 2000-02-11: Make redirect references independent of the rest of WebDAV. The creation method for redirect references shouldn't require an XML request body. |
in revision 08: MKRESOURCE will be replaced by a specific method that doesn't rely on any PROPPATCH semantics, however it will still use XML (see also BIND spec for similar marshalling). |
| lc-42-no-webdav |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0293.html> yarong@Exchange.Microsoft.com, 2000-02-11: Use a creation method that creates only redirect references. The MKRESOURCE method hinders experiment because a user of a server who wishes to add support for the creation of a new resource type can't simply throw in another Apache module and allow it to provide the code for the new resource type. They have to find the code used for MKRESOURCE and change it to support the new resource type. |
in revision 05: We will replace MKRESOURCE with MKREF, which creates only redirect reference resources. |
| lc-43-webdav |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0294.html> yarong@Exchange.Microsoft.com, 2000-02-11: Get rid of the DAV:reftarget property. |
in revision 05: DAV:reftarget is readonly and is present only for redirect references that are also WebDAV resources. We'll also have a method for setting target; Redirect-Ref header (returned on all 302 responses) will have the target as its value. See also issue 6, 17, 50. |
| lc-44-pseudo |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0302.html> yarong@Exchange.Microsoft.com, 2000-02-11: Instead of adding an optional prop XML element to the response element in 207 responses, define a new location XML element and a new refresource XML element. |
in revision 07: Agree to define new XML elements that are not pseudo-properties. Disagreement about whether refresource is needed. See issue 61. |
| lc-45-apply-to-rr |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0295.html> yarong@Exchange.Microsoft.com, 2000-02-11: Suggested replacement text for this paragraph, which briefly introduces Apply-To-Redirect-Ref. Includes a note that even with this header, the response may be a 302. |
in revision 04: See issue 19 for replacement text. Disagree. Redirect reference will never respond to Apply-To-RR with 302. |
| lc-46-bind |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0296.html> yarong@Exchange.Microsoft.com, 2000-02-11: Remove dependency on bindings from second paragraph of section 5. |
in revision 03: Agreed. |
| lc-47-207 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0297.html> yarong@Exchange.Microsoft.com, 2000-02-11: In line with his wish to get rid of the request message body of MKRESOURCE, 207 would not be an appropriate response code. The description of 409 might lead someone to believe that you can't create redirect references outside of WebDAV namespaces. Suggests a different description. |
in revision 05: No longer relevant - MKREF can't get a 207 response. Revise to make it clear that the first condition will only occur in WebDAV-compliant namespaces. |
| lc-48-s6 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0298.html> yarong@Exchange.Microsoft.com, 2000-02-11: Replace all of section 6 with just this: A redirect resource, upon receiving a request without an Apply-To-Redirect-Ref header, MUST respond with a 302 (Found) response. The 302 (Found) response MUST include a location header identifying the target and a Redirect-Ref header. If a redirect resource receives a request with an Apply-To-Redirect-Ref header then the redirect reference resource MUST apply the method to itself rather than blindly returning a 302 (Found) response. |
in revision 10: Original resolution: Keep a summary along the lines of Yaron's proposal (don't use the word "blindly"). Keep the bullets detailing the headers to be returned. Delete the rest, including the examples. See also issue 28, 29, 30, 31, 32. Actual resolution: the current wording seems to be in line with what Yaron proposed back in 2000. |
| lc-49-put |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0299.html> yarong@Exchange.Microsoft.com, 2000-02-11: Remove the last sentence of Example 6.2, which says that PUT replaces the reference with a different resource. |
in revision 05: No longer relevant. Deleted this example in response to issue 48. |
| lc-50-blindredirect |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0300.html> yarong@Exchange.Microsoft.com, 2000-02-11: Replace current language explaining the purpose of the Redirect-Ref header with language that simply states that it marks blind 302 responses from redirect resources. (Section 6.3, 11.1) |
in revision 06: Section 6.3 was removed in response to issue 48. In 11.1, change the definition of the Redirect-Ref header to have the value of the target (relative URI) as its value. Then we don't need a method for retrieving the target's relative URI. Presence of the Redirect-Ref header lets the client know that the resource accepts Apply-To-RR header and the new method for updating target. Reject Yaron's suggested language, but make the above changes. |
| lc-51-repeat |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0301.html> yarong@Exchange.Microsoft.com, 2000-02-11: The first sentence of this paragraph says only what's clear from RFC 2518, so will cause confusion by its presence. Delete it. The last sentence of this paragraph lists methods. That's a bad idea. Remove it. |
in revision 03: Delete entire paragraph. |
| lc-52-no-relative |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0303.html> yarong@Exchange.Microsoft.com, 2000-02-11: Don't allow relative URIs. Delete section 9. |
in revision 03: Declined. Some applications need relative URI. |
| lc-53-s10 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0304.html> yarong@Exchange.Microsoft.com, 2000-02-11: The behavior described in this section would have a very serious impact on the efficiency of mapping Request-URIs to resources in HTTP request processing. Also specify another type of redirect resource that does not behave as in section 10, but instead would "expose the behavior we see today in various HTTP servers that allow their users to create 300 resources." Be sure we know what behavior will be if the redirect location is not an HTTP URL, but, say ftp. |
in revision 07: We won't define 2 sorts of redirect references here. Servers SHOULD respond with 302 as described here, but if they can't do that, respond with 404 Not Found. (It's hard to modularize the behavior specified - it impacts processing Not Found cases of all methods, so you can't just add it to an HTTP server in a redirect ref module.) |
| lc-54-s10 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0304.html> yarong@Exchange.Microsoft.com, 2000-02-11: The Note: in section 10 has the same problem pointed out in Bindings.NoSlash and needs to be fixed. It contradicts RFC 2518 and 2616, which both assume that a URL and the same URL + "/" may map to different resources. |
in revision 04: Agreed in mailing list discussions that no change is needed. |
| lc-55-iana |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0305.html> yarong@Exchange.Microsoft.com, 2000-02-11: Expand the IANA section to list all methods, headers, XML elements, MIME types, URL schemes, etc., defined by the spec. |
in revision 08: Rejected: this section is about registering new spaces of identifiers. See RFC2434. |
| lc-56-notjusthttp |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0306.html> yarong@Exchange.Microsoft.com, 2000-02-11: Make it clear in examples and text that the redirection URI could be non-HTTP. |
in revision 05: We agree that it is possible to create redirect references to non-HTTP resources. Add example. (actually it was added to the definition of "target resource"). |
| lc-57-noautoupdate |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0307.html> yarong@Exchange.Microsoft.com, 2000-02-11: Add language to forbid servers from automatically updating redirect resources when their targets move. julian.reschke@greenbytes.de, 2004-01-05: I don't think we can forbid that. This spec consists of (a) clarifications of how a server that supports redirects should behave for specific WebDAV methods, and (b) extensions to explicitly create them (or to apply a method to the redirect itself). As such, we shouldn't add any requirements that HTTP doesn't add. What we could do is (1) note why auto-update may be a bad idea, and possibly (2) define that redirects created by MKREDIRECTREF should not behave that way (or alternatively define more specific resource types). |
in revision 10: State that operations on the target of a redirect reference usually will not affect the redirect itself; but also that clients should not rely on that in general (see also http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0004.html). |
| lc-58-update |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0308.html> yarong@Exchange.Microsoft.com, 2000-02-11: There needs to be a way to update the target of a redirect reference. |
in revision 10: Agreed. See also issues 6, 43. See new method UPDATEREDIRECTREF. |
| lc-59-depth |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0316.html> reuterj@ira.uka.de, 2000-02-14: Section 7: When a method is being applied to a collection with Depth > 0, let Apply-To-Redirect-Ref contain a list of URIs. This way you could have it apply to some subset of the redirect references in the collection. |
in revision 03: Declined. Too complex, no use case for it. |
| lc-60-ex |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0316.html> reuterj@ira.uka.de, 2000-02-14: Section 7, para 3: Make it clear that these are just examples of client behavior, and are not meant to limit the client's behavior to these options. |
in revision 06: Agreed to delete this paragraph. Continue discussion of what information should be returned with 302 in multistatus. Just location? Also redirectref? Update: ret gid of pseudo-property and special response format, define new response element instead. See ossue lc-61-pseudo. |
| lc-61-pseudo |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0316.html> reuterj@ira.uka.de, 2000-02-14: Section 7: It doesn't make sense to ask future editors of RFC 2518 to define DAV:location with the semantics it has here. RFC 2518 should provide the information in the Location header somehow in multistatus responses, but not by using properties. |
in revision 07: Define an XML element for location that is not a pseudo-property. We'll keep the recommendation that RFC 2518 add this for 302 responses. See also issue 44. |
| lc-62-oldclient |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0316.html> reuterj@ira.uka.de, 2000-02-14: Section 7: It's too strong to claim that non-referencing clients can't process 302 responses occurring in Multi-Status responses. They just have an extra round trip for each 302. |
in revision 07: Remove last sentence of the paragraph that recommends changes to RFC 2518. |
| lc-63-move |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0316.html> reuterj@ira.uka.de, 2000-02-14: Section 7.1: Is MOVE atomic from the perspective of a client? Agrees that there should be no 302s for member redirect references, but finds the rationale dubious. |
in revision 07: Remove 7.1. Reword 7.2 to avoid concerns with "poses special problems" and "due to atomicity". |
| lc-64-reftarget |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0316.html> reuterj@ira.uka.de, 2000-02-14: Perhaps make DAV:location a real property, instead of DAV:reftarget, and require it to be an absolute URI. |
in revision 03: Declined. Some applications need relative URI. See also issue 52. |
| lc-65-lock |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0316.html> reuterj@ira.uka.de, 2000-02-14: "In the case of a redirect reference resource, I think the intended meaning of WebDAV is that the resource itself is the internal member to be locked, not the target resource. In so far, I think, the Apply-To-Redirect-Ref header should implicitly always be set, and a LOCK request for a collection MUST fail if in the hierarchy of collections there is an ordinary redirect reference as internal member." |
in revision 03: Declined. Behavior will be the same for all methods. No exceptions. Consistency / simplicity override other considerations |
| lc-66-depth |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0316.html> reuterj@ira.uka.de, 2000-02-14: 7.3, 7.4: Change "Depth=infinity" to "Depth: infinity". |
in revision 03: Agreed. |
| lc-67-redirectref |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0316.html> reuterj@ira.uka.de, 2000-02-14: 7.4: The explanation should not contrast displaying the properties of the redirect ref with displaying the properties of its target, but with returning a 302. |
in revision 04: Revise as recommended. |
| lc-68-lock |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0316.html> reuterj@ira.uka.de, 2000-02-14: 7.6: The LOCK example responds with 207, as does the example in RFC 2518, but section 8.10.4 of RFC 2518 says if the lock cannot be granted to all resources the response MUST be 409 conflict. |
in revision 03: We'll keep 207 and encourage RFC 2518 to say the same. (This inconsistency in RFC 2518 is on the WebDAV issues list.) |
| lc-69-424 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0316.html> reuterj@ira.uka.de, 2000-02-14: 7.6: Thinks there should not be 424 returned for diary.html because it is not an ancestor of a member that caused the lock to fail. |
in revision 03: No change needed. The interpretation of "dependency" in the example is correct. It doesn't have to do with ancestor relationship, only with what caused operation to fail. |
| lc-70-relative |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0316.html> reuterj@ira.uka.de, 2000-02-14: Section 9, para 1: Maybe say that the resulting absolute URI could be any of a number of URIs, depending on which URI is used in the request to identify the redirect reference. |
in revision 03: No change needed. |
| lc-71-relative |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0316.html> reuterj@ira.uka.de, 2000-02-14: Section 9: Base URI should be the Request-URI or href minus its final segment. |
in revision 06: Original WG comment: Fix this. However, this is just a misunderstanding. The process of resolving a relative URI against a hierarchical base URI already involves removal of the last path segment, so the draft is correct here. |
| lc-72-trailingslash |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0316.html> reuterj@ira.uka.de, 2000-02-14: Section 10: Forbid DAV:reftarget from ending in "/" julian.reschke@greenbytes.de: (last call WG response): Make the note warn about the possibility of two slashes in a row, recommend against ending target with a slash, since that could result in two slashes in a row. |
in revision 06: It seems that the rule in the 3rd paragraph already explains how to deal with this situation. No change. |
| lc-73-asciiart |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0316.html> reuterj@ira.uka.de, 2000-02-14: Section 10: Replace the ascii art with Juergen's suggestion (see his message). |
in revision 03: Replace. |
| lc-74-terminology |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0316.html> reuterj@ira.uka.de, 2000-02-14: "plain HTTP/1.1 redirect" - find some good name for this an use it consistently |
in revision 06: Remove the whole sentence. |
| lc-75-ignore |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0316.html> reuterj@ira.uka.de, 2000-02-14: 11.2: "If the Apply-To-Redirect-Ref header is used on a request to any other sort of resource besides a redirect reference resource, the server SHOULD ignore it." Don't need to say this since HTP already says that any header that is not understood should be ignored. |
in revision 05: Need to keep this to specify what a server that does support this protocol needs to do when the header appears in a request to a non-redirect-ref resource. However, say "MUST". |
| lc-76-location |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0359.html> reuterj@ira.uka.de, 2000-02-22: 12.2: Make DAV:location a real (live) property, get rid of the DAV:reftarget property |
in revision 07: Pseudo-property was removed. |
| lc-77-webdav-applications |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0359.html> reuterj@ira.uka.de, 2000-02-22: Section 16: Change "WebDAV applications" to "applications that implement this protocol". |
in revision 03: |
| lc-78-directory |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0359.html> reuterj@ira.uka.de, 2000-02-22: Section 16.4: Change "directory" to "collection". Not new to this protocol. Holds for any protocol that has hierarchical access paths. |
in revision 04: |
| lc-79-accesscontrol |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0359.html> reuterj@ira.uka.de, 2000-02-22: Section 16.4: "In some environments, the owner of a resource might be able to use access control to prevent others from creating references to that resource." That would not be consistent with the concept of redirect references as weak links (e.g. think of moving a resource to a different locationo that is already the target of some redirection reference. |
in revision 06: Remove the statement. |
| lc-80-i18n |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0359.html> reuterj@ira.uka.de, 2000-02-22: Section 17: Could get rid of a lot of this section, since this protocol extends WebDAV. Just reference [WebDAV]. julian.reschke@greenbytes.de, 2003-10-02: True, but I note that other specs have re-stated these considerations as well. Opinions? |
in revision 07: Just point to RFC2518. Remove RFC2277 and XML from references (not needed anymore). |
| lc-81-typo |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0359.html> reuterj@ira.uka.de, 2000-02-22: Section 17: Typo "As in [WebDAV}" |
in revision 03: Fixed. |
| lc-82-iana |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0359.html> reuterj@ira.uka.de, 2000-02-22: Section 18: Just reference [WebDAV] and say this protocol does not introduce any new considerations. |
in revision 04: Simplify, then resolve issue 55. |
| lc-83-bind |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0359.html> reuterj@ira.uka.de, 2000-02-22: References: Get rid of the reference to the bindings spec. |
in revision 04: Agreed. |
| lc-84-ext |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0359.html> reuterj@ira.uka.de, 2000-02-22: Appendix 24.1: This is not an extension but a replacement for the WebDAV definition of the response element. |
in revision 03: Fixed. |
| lc-85-301 |
change closed |
ejw@cse.ucsc.edu, 2000-01-03:
Support creation of other than 302 redirects, especially 301.
julian.reschke@greenbytes.de, 2003-10-13: HTTP seems to distinguish the following use cases: (a) permanent redirect (301), (b) temporary redirect (302 or 307), (c) redirect to a GET location after POST (303) and (d) agent-driven negotiation (300). Among these, (a) and (b) seem to be well understood, so we should support both. (c) doesn't seem to be applicable. (d) may become interesting when user agents start supporting it, so the spec should be flexible enough to support a feature extension for that. For now I propose that the client is able to specify the redirection type as a resource type, such as "DAV:permanent-redirect-reference" and "DAV:temporary-redirect-reference". This spec would only define the behaviour for these two resource types and would allow future extensions using new resource types and suggested response codes. |
in revision 09: Support creation of both permanent (301, optional) and temporary (302, required) redirects. Keep protocol extensible for other types. Make lifetime visible as protected property. |
| old_clients |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0180.html> julian.reschke@greenbytes.de, 2003-11-10: There are (at least) two major design goals, but unfortunately both are in direct contradiction: #1: Maximum consistency with HTTP/1.1 (RFC2616). This means that any request that addresses a redirect reference resource MUST result in a 3xx status code (obviously the whole point is that GET MUST result in a redirection, and if it does, it's hard to say why other methods such as PUT or DELETE should behave differently). Therefore, the redirect reference protocol introduces a new request header ("Apply-To-Redirect-Ref") through which a client can indicate that the request indeed should be applied to the redirect reference resource itself. #2: Maximum usability with existing clients. For instance, the Microsoft Webfolder client will not be able to DELETE a redirect reference resource unless the server deviates from #1. Right now I'm not sure about the best way to resolve this. Currently the spec chooses #1 (back when this decision was made, there was probably the assumption that existing clients would quickly be updated -- something that probably isn't true today). However this may result in implementers either just ignoring these rules, or adding special workarounds based on "User Agent" detection. |
in revision 12: There was little feedback, so it seems that no change should be made. |
| rfc2396bis |
change closed |
julian.reschke@greenbytes.de, 2004-10-22: Update to RFC2396bis (this needs to be done carefully because we are using the term "relative URI reference" which does not exist in RFC2396bis anymore). | in revision 11: Agreed (draft-rfc2396bis has been published as RFC3986). |
| rfc2606-compliance |
editor closed |
julian.reschke@greenbytes.de, 2003-10-02: Ensure that examples use only sample domains as per RFC2606. | in revision 07: |
| specify_safeness |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/0196.html> julian.reschke@greenbytes.de, 2004-09-19: Specify safeness and idempotence of new methods. |
in revision 09: Done. |
| title |
edit closed |
julian.reschke@greenbytes.de, 2004-01-04: Expand "WebDAV" in document title. | in revision 08: Done (no change tracking). |
| Version | Issues |
|---|---|
| latest | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 13 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 12 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 11 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 10 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 09 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 07 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 06 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 05 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 04 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 03 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 02 |
Last change: 2005-10-01