Issues with rfc2518bis-06 (part 3)

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

Received on Saturday, 11 September 2004 19:28:42 UTC