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 |
|---|
| Identifier | Type / Status | Reference and Description | Resolution / Latest Change |
|---|---|---|---|
| 14/15-surplus-sections |
edit closed |
[email protected], 2003-07-11: Remove unneeded empty "Coypright" and "IPR" sections (raised by IESG). | in revision 10: Done. |
| 3-ordering-semantics |
change closed |
[email protected], 2003-07-11: Add definition for the term "ordering semantics" (raised by Allison Mankin). | in revision 10: Added. |
| 4.1-DELETE-behaviour |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003AprJun/0024.html> [email protected], 2003-04-16: Concerns that it is not clear enough that DELETEing one internal member MUST not affect the ordering of the remaining members. |
in revision 08: Add clarification. |
| 6-position-preserving-rename |
edit closed |
[email protected], 2003-06-13: Add example about how to rename a collection member without changing it's position. | in revision 09: Example added. |
| 6.1-safe-update |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003AprJun/0024.html> [email protected], 2003-04-16: Lisa Dusseault expressed concerns that clients that to "safe deletes" (such as writing to a temp file, then moving to the original file) will lose the original ordering. As the very same issue applies to versioning (version histories lost) and ACLs, we aren't trying to "fix" it here (it ain't broken). Clients should be encouraged to do in-place editing using locks and etags. |
in revision 08: No change. |
| 6.1-when-are-members-added |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003AprJun/0024.html> [email protected], 2003-04-16: Concerns that different server implementations may treat MOVE inside the same collection as simple rename (not creating a new internal member), or a sequence of LINK/UNLINK (in which case ordering will not be preserved and the renamed resource would by default appear at the end of the ordering (in absense of a Position header)). [email protected], 2003-04-17: I don't think making a special case for "move within a collection" vs. "move outside of the collection" is worth optimizing, since it makes the spec more complicated and is likely to be enough of a problem to some servers to make it likely to not be followed anyway. [email protected], 2003-05-06: There doesn't appear to be consensus on this issue, hence we should leave it out of the spec. That said, given that we had discussion on this issue, it makes sense to try and capture some of that discussion in the specification, so that implementors aren't operating in a total vacuum on this issue. Minimally, the spec. should note that this behavior is intentionally undefined. |
in revision 08: Add clarification. |
| 7-clarify-positions-for-not-explicitly-mentioned-members |
edit closed |
[email protected], 2003-06-10: Make clear that when changing the ordering type, the ordering for those members that aren't mentioned in the ORDERPATCH request is server-defined. | in revision 09: Add clarification. |
| 7.1-surprising-ordering-type-in-DAV-ns |
edit closed |
[email protected], 2003-05-21: Get rid of "DAV:whim" as example for a previously set ordering type, because it may imply that there's something special with this URI. As the previous ordering type is irrelevant as long as the collection is ordered, just don't mention it. | in revision 09: Change made. |
| 8-order-for-unordered-subcollections |
edit closed |
[email protected], 2003-05-21: Clarify that for PROPFIND infinity on an ordered collection with unordered subcollections response ordering for subcollection members is undefined. | in revision 09: Add second example. |
| 9.4-UPDATE-non-version-controlled-members |
change closed |
Reference: <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003AprJun/0004.html> [email protected], 2003-04-06: Clarify effect of UPDATE of a versioned collection on ordering of non version-controlled members. |
in revision 08: Ordering is server-defined. |
| iesg-discuss-11-webdav-applications |
change closed |
Reference: <https://www1.ietf.org/IESG/EVALUATIONS/draft-ietf-webdav-ordering-protocol.bal> [email protected]: (Ned Freed) Unless applications have gotten a lot smarter while I wasn't looking, this section doesn't make them aware of anything. Suggest changing "applications" to "implementers". |
in revision latest: Fix. |
| ordered-header-name |
change closed |
[email protected], 2002-31-12: As DAV:orderingtype and the "Ordered" header carry the same information, it doesn't seem to make sense to have two differing names. | in revision 05: Rename it. |
| ordering-type-values |
change closed |
[email protected], 2002-31-12: The syntax is unnecessarily complex. The strings "DAV:custom" and "DAV:unordered" are valid URIs anyway, so they could appear inside DAV:href as well. This also applies to the possible values in the "Ordered" header described below. | in revision 05: Syntax simplified. |
| ordering-type-vs-allprop |
change closed |
[email protected], 2003-01-05: Define whether this property should be reported upon PROPFIND/allprop. | in revision 04: SHOULD NOT be reported. |
| ordermember-format |
change closed |
[email protected], 2003-01-03: If the DAV:href element in DAV:ordermember is supposed to only carry the segment name, a DAV:segment element should be used instead. | in revision 05: Syntax change. |
| ORDERPATCH-request |
change closed |
[email protected], 2003-01-03: For consistency with RFC3253, the document element should be called DAV:orderpatch. | in revision 05: Element type changed. |
| rfc-editor |
edit editor |
[email protected], 2003-12-03: (umbrella issue for changes made by RFC Editor) | latest change in revision latest |
| typo |
edit editor |
[email protected], 2003-10-13: (umbrella issue for typos) | latest change in revision latest |
| Version | Issues |
|---|---|
| latest | |||||||||||||||||| |
| 10 | ||||||||||||||| |
| 09 | ||||||||||||| |
| 08 | ||||||||| |
| 07 | ||||| |
| 06 | ||||| |
| 05 | ||||| |
| 04 | ||||| |
| 03 | |
| 02 | |
| 02orig |
Last change: 2003-12-03