Subject: Issues with rfc2518bis-06 (part 3)

From: Julian Reschke <[email-masked]>
Date: Sat, 11 Sep 2004 21:27:30 +0200

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sun, 12 Sep 2004 14:22:01 -0400

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

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 13 Sep 2004 15:04:41 -0700

While I appreciate all the issues reported with RFC2518, I am not 
dealing with them until we have issue status tracking more firmly in 
hand somehow.  Joe is investigating tools to help with this issue.

Thanks,
Lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Sep 2004 00:09:37 +0200

> hand somehow.  Joe is investigating tools to help with this issue.

I do appreciate the plan to enhance the issue tracking. May I recommend 
to simply adopt what I've been doing in the drafts I am / was editing 
(which means embedding the issue inside the xml2rfc draft text using XML 
extension elements)?

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 13 Sep 2004 15:15:10 -0700

I find that unacceptable for WG-tracked issues (of course it's fine for 
the author's own issues or to duplicate the WG-tracked issues until the 
author believes they've dealt with them).   The author can close the 
issues in their document as soon as they've made changes, but for many 
issues there needs to be some external item for the issues tracker 
person to mark state on when the WG agrees the issue is actually 
closed.

Lisa

On Sep 13, 2004, at 3:09 PM, Julian Reschke wrote:

> I do appreciate the plan to enhance the issue tracking. May I 
> recommend to simply adopt what I've been doing in the drafts I am / 
> was editing (which means embedding the issue inside the xml2rfc draft 
> text using XML extension elements)?
>
> Best regards, Julian
>
> --

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Sep 2004 00:38:36 +0200

Lisa Dusseault wrote:

> person to mark state on when the WG agrees the issue is actually closed.

I do agree that an issue isn't automatically closed just because the 
document editor thinks it is. But that doesn't seem to be a big issue -- 
give change control to somebody else as well, or have the author not 
close issues before there's WG consensus.

IMHO this has worked just fine for previous drafts, though. The document 
editor makes a proposal about how to resolve a specific issue to the 
mailing list, and does so in the working document (with the expectation 
that the change needs to be rolled back if the change turns out not to 
be ok).

The big advantages of having everything in one place are:

- document and issues list are in sync *by definition*
- published Internet Drafts automatically carry a list of open and 
resolved issues

Just my 2 cents,

Julian