Re: ID: draft-ietf-webdav-bind-05

Joe Hildebrand wrote:
> 
> In the interest of trying to get things moving on BIND, I've got some 
> review comments.  I'm unburdened by knowing where the WG has already 
> achieved consensus, so please let me know if I step on something 
> unintentionally.

Joe, thanks for doing the review. This is what we need to finally get 
back to make progress.

> Meta:
>  - Who is maintaining the webdav.org site for specs?  The latest draft 
> for bind there is -02.

Not me. I'd love to be able to update it, but I can't. In the meantime, 
the current edits are in

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html>

and the current issues lists lives at:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html>.

>  - Is the canonical issue list the one at webdav.org?  It looks like it 
> was last updated almost a year ago.

Nope. See above.

> 1.1
>  - 'DAV:' is a namespace URI, not a namespace name.

As far as I can tell, both terms are used interchamgeably. "namespace 
name" is the one defined in the XMLNS rec: 
<http://www.w3.org/TR/REC-xml-names/#dt-NSName>.

>  - Path segment being the characters found *between* slashes is 
> confusing, since the last piece  of a URL is also a segment.

That term is defined that way in 
<http://greenbytes.de/tech/webdav/rfc2396.html#rfc.section.3.3>.

> 1.3
>  - Is the first paragraph meant to be an exhaustive list of error 
> codes?  Wouldn't 404 be more appropriate for (DAV:bind-source-exists) 
> failing, for example?

a) no, it's not exhaustive,

b) and no, 404 would be incorrect because it should only occur when 
there's a problem with the resource identified by the Request-URI 
(<http://greenbytes.de/tech/webdav/rfc2616.html#status.404>):

" The server has not found anything matching the Request-URI. No 
indication is given of whether the condition is temporary or permanent. 
The 410 (Gone) status code SHOULD be used if the server knows, through 
some internally configurable mechanism, that an old resource is 
permanently unavailable and has no forwarding address. This status code 
is commonly used when the server does not wish to reveal exactly why the 
request has been refused, or when no other response is applicable."

>  - Second paragraph: how might I otherwise negotiate?  The DAV:bind header?

Good point. As far as I can tell, this text was inherited from RFC3253 
(<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.1.6>). 
Geoff, do you remember what this is supposed to mean? Can/should we 
clarify that?

> 2.1
> - I can't find a good reference for the 506 error code. It's not in 2616 
> or 2518, and is not mentioned by any of the pointers at 
> http://www.iana.org/assignments/http-status-codes.  Is this a candidate 
> for the IANA considerations, or are we missing a normative reference?

This is a new status code (it appears under "Additional Status Codes", 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.7.2>).

Last time I checked the IETF instructions for "IANA considerations", I 
got the impression that it's reserved for declaring *new* registries 
that the IANA needs to take care of, not adding new items to existing 
registries (such as HTTP method names, headers or status codes). Can you 
point to a normative document that clarifies?

> 2.2
>  - first sentence doesn't parse.  I think it was supposed to be "to 
> resource R *is* to be added"

Ok.

> 2.3
>  - last paragraph is a little confusing.  I'm not seeing the timeline of 
> a COPY request that may have partially succeeded.  Perhaps this is just 
> unclear pronoun references, and too may copies of "copy" in one 
> sentence... :)

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.2.3.p.5>:

"If a COPY request would cause a new resource to be created as a copy of 
an existing resource, and that COPY request has already created a copy 
of that existing resource, the COPY request instead creates another 
binding to the previous copy, instead of creating a new resource."

What this says is that while copying, the COPY request should try to 
preserve the source structure (like in a filesystem copy where an 
operation may want to try to preserve existing hard links rather than 
creating additional files). Any proposal how this can be made clearer?

> 2.5
>  - last paragraph is a repeat of text two paragraphs before

ok (it's just the first sentence, though).

>  - if I'm understanding this right, MOVE is the same as REBIND, except 
> for atomicity guarantees.  since we've got the same sort of issue for 
> UNBIND/DELETE, isn't it possible a client could figure out that the 
> server supports bind (using the DAV: header), specify an 'Atomic: T' 
> header, and save us from creating two HTTP methods?  I know that 
> creating http methods doesn't have the same stigma in this group as in 
> others, and I don't feel strongly about this one, just trying to 
> understand the design choice, since it looks like this was tracked with 
> the ATOMIC issue.

Almost. The issue here is that RFC2518 allows MOVE to be implemented as 
a COPY/DELETE sequence. That sequence wouldn't preserve for instance the 
DAV:resource-id property as required. So there are more differences, and 
as some people weren't happy with adding new requirements/restrictions 
to MOVE, the WG choose to add a separate method.

Note that a server can always do a "best effort" MOVE, but would have to 
reject the REBIND request when it can't do it "properly" (in particular, 
preserving (almost) all live properties).

> 3.2 (and others)
>  - Should all of the DTD be gathered into a single place in an appendix 
> (like 23.1 of 2518)?  Is it time to think about schema, as well?

This is a permathread (I think last time we had that back last summer). 
My take:

- the DTD fragments are there as a short notation; however WebDAV 
messages never ever can be validated using a DTD, so it's unclear what 
we gain by repeating the information in a second place in the spec (for 
the same reason it was removed from RFC2518bis)

- *if* we change notation, I'd vote for one that (1) is easy to read and 
(2) can *indeed* validate WebDAV XML messages. XML Schema can't due to 
the extensibility model we use. RelaxNG could. See 
<http://greenbytes.de/tech/webdav/rfc3470.html#rfc.section.4.7> for more 
information on this topic.

Specs that extend RFC2518 (such as earlier ACL and ORDERED-COLLECTIONS) 
should stick with RFC2518's format. If we want to change this, we should 
  do this while upgrading RFC2518 itself.

> 4 (and others)
>  - (DAV:locked-update-allowed) what if the resource is locked?  I 
> understand that this is a property of the resource, not the binding, but 
> since 2518 doesn't say anything about bindings, I think we could use a 
> paragraph at some point that spells this out explicitly.  Perhaps 
> another sub-section in section 2?

That's incorrect. In particular, 
<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.3> says:

"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."

That being said, a large amount of the open issues raised against 
RFC2518 are about locking semantics. The authors of the BIND spec feel 
that it's a bad idea to try to clarify locking semantics in a document 
that's completely independant and optional. Locking semantics should be 
fully defined in a single place.

One way to do this is to wait for RFC2518bis. Another one is to factor 
out locking from the base protocol, and publish this as "update" to 
RFC2518 (at "proposed" level), and let the BIND spec refer to that. This 
is what I'm currently working on (and I'm planning to submit a complete 
rewrite in time before the IETF meeting).

I've summarized the issue at 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0049.html>. 
   So far, I've seen many people agree, and it would be really good if 
the working group would come to a decision on this matter.

>  - Is this what 4_LOCK_BEHAVIOR refers to?  "Done" as the resolution 
> doesn't give me quite enough to go on...

No, I think that was a separate issue. We may want to go through the 
original message 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0200.html>) 
and make sure all things are indeed answered.

> 7.1
>  - IANA notification for 208?

See dicussion above (same for 506).

> 7.1.1
>  - I think this would be clearer if it included D:resource-id in the 
> request and response, so you could tell where the loop happened.  Are 
> resource-id's likely to be costly to return?

No, they should be cheap. I think we should update the example accordingly.

> 8.2
>  - The DAV: request header only has peripheral importance to this spec. 
>  This is just the first place it was needed.  Is it too late for this to 
> go into 2518bis, instead?  Seems to be a layering problem.  No matter 
> where it ends up, we ought to think about IANA registration of these 
> compliance class names.

It is in RFC2518bis, but the authors of RFC2518bis have repeatedly made 
clear that they don't have any estimate about when RFC2518bis will be 
done, and thus BIND should not rely in any way on RFC2518bis' contents.

> 8.2.1
>  - last paragraph "it's" -> "its"

Ok.

> 11
>  - Isn't there an IANA registry for HTTP methods and request headers?  I 
> don't see one.  If there was one I'd want to add BIND, UNBIND, REBIND, 
> and DAV:.

I think this is work-in-progress.

>  - the other IANA actions i've listed above

Yes, we need to clarify those.

> 5.1_LOOP_STATUS
>  - Is there anything left to do on this?

No, see latest issues list.

> Sorry some of these are nit-picky.

No reason to. As a matter of fact, this kind of review is what we need. 
Let's try to get things moving so that we can get back on track (BIND 
was supposed to be last-called in May according to the just updated 
working group charter).

Best regards. Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 23 June 2004 03:52:09 UTC