Re: Issues with rfc2518bis-06 (part 1-3)

I agree with the suggested fixes made by Julian in these issue lists.
And I'd especially like to thank Julian for his comprehensive reviews,
and his careful tracking of the state of these issues.

Cheers,
Geoff


Julian wrote on 09/11/2004 03:27:30 PM:
> This is a summary of issues either new in draft -05 or issues with 
> changes between drafts 05 and 06.
> 
> 
> 06-C01 Locks vs mutltiple URLs
> 
> I appreciate the clarification on locking. Currently it says:
> 
>     6.8  Locks and Multiple Bindings
> 
>     A resource may be made available through more than one URI.  However
>     locks apply to resources, not URIs.  Therefore a LOCK request on a
>     resource MUST NOT succeed if can not be honored by all the URIs
>     through which the resource is addressable.
> 
> This is a bit misleading as indeed the lock is on the resource, but it 
> *protects* the URL through which the lock was created. Thus given URLs 
> "a" and "b" identifying the same resource which was locked through "a", 
> I can apply DELETE to "b" without needing the lock token.
> 
> This seems to be another example why it would be A Good Thing to 
> completely import GULP (see for instance 
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-
> latest.html#gulp>) 
> into the spec.
> 
> 
> 06-C02 Section 7.5
> 
> "and the response SHOULD contain the 'missing-lock-token' precondition."
> 
> Spec should copy precondition/postcondition terminology from RFC3253; 
> while doing this, please change to identifiers that actually *name* the 
> condition, such as DAV:need-lock-token in 
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-
> latest.html#rfc.section.8.2.2>. 
> (same applies to almost all condition names defined by the document).
> 
> 
> 06-C03 Section 8.2 Multistatus Format
> 
>     The multistatus contains one response element for each
>     resource in the scope of the request (in no required order) or may 
be
>     empty if no resources match the request.
> 
> Although this is correct, I find it confusing that it's stated for 
> PROPFIND where this condition never occur. It should be mentioned in the 

> definition of the multistatus element instead.
> 
> 
> 06-C04 Section 8.3.1 Multistatus status codes
> 
> Why would we ever return a 423 in a 207 response body to a *PROPPATCH*?
> 
> 
> 06-C04 Section 8.9.3
> 
> ..refers to 8.7.2 for "namespace consistency". That's in 5.1, though.
> 
> 
> 06-C05 Section 8.10.4
> 
> Speaking of MOVE...:
> 
>     403 (Forbidden) - The source and destination resources are the same.
> 
> This is a very good example for why we need to go through *all* response 

> code examples in the document. A 403 upon MOVE can mean a lot of things, 

> and the only way to distinguish these is by using proper condition 
codes.
> 
> 
> 06-C06, 8.11.6
> 
>     423 (Locked) - The resource is locked already.  For consistency's
>     sake, this response SHOULD contain the 'missing-lock-token'
>     precondition element.
> 
> I find this misleading. We have a strict separation between LOCK 
> creation (with request body) and LOCK refresh (without). If a LOCK 
> creation request fails because the resource is already exclusively 
> locked, providing the lock token in the If header will not help at all.
> 
> 
> 06-C07, 8.12
> 
>     The If header is not needed
>     to provide the lock token although servers SHOULD still evaluate the
>     If header and treat it as a conditional header.
> 
> I agree with that, but I'm confused it's mentioned here. Doesn't it 
> apply to *all* HTTP methods?
> 
> 
> 06-C08, 9.5.4, lock token syntax
> 
> Uses an invalid lock token (<locktoken:a-write-lock-token>)
> 
> 
> 06-C09, 13.7 href element
> 
>     Purpose:  Identifies the content of the element as a URI.  In many
>        situations, this URI MUST be a HTTP URI, and furthermore, it MUST
>        identify a WebDAV resource.  There is one exception to this
>        general rule in the lockdiscovery property, where the lock token
>        (which is a URI but may not be a HTTP URI) is inside the href
>        element.  Other specifications SHOULD be explicit if the href
>        element is to contain non-HTTP URIs.
> 
> Wow? Since when? May it refer to a null resource? Is a null resource a 
> WebDAV resource? What about location/href, for instance? Unless there's 
> consensus for this incompatible change to RFC2518, please remove it.
> 
>     Value:  URI (See section 3.2.1 of RFC2616 [8])
> 
> No. URIs are defined in RFC2396(bis).
> 
> 
> 06-C10, 13.16
> 
> Typo in "Name:" line.
> 
> 
> 
> 
> 
> 06-E01 Boilerplate
> 
> The front page should refer to RFC3667, not RFC2026. In xml2rfc source 
> code, do this using ipr="full3667" on the root element.
> 
> 
> 06-E02 TOC gone
> 
> The TOC is gone. Please bring it back.
> 
> 
> 06-E03 Reference style
> 
> References now use numerical names instead of symbolic ones. Is there a 
> reason for this change? (use <?rfc symrefs="yes"?> in xml2rfc source 
code)
> 
> 
> 06-E04 non-ASCII characters
> 
> In section 7.6, 8.1.6, 8.2, 8.7.2 and probably some more places.
> 
> 
> 06-E05 XML references
> 
> Please update XML reference to "Extensible Markup Language (XML) 1.0 
> (Third Edition)", W3C REC-xml-20040204, February 2004.
> 
> 
> 06-E06 Appendix B.2
> 
> Formatting of list was lost.
> 
> 
> 
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
>