ID: draft-ietf-webdav-bind-05

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.

Meta:
  - Who is maintaining the webdav.org site for specs?  The latest draft 
for bind there is -02.
  - Is the canonical issue list the one at webdav.org?  It looks like it 
was last updated almost a year ago.

1.1
  - 'DAV:' is a namespace URI, not a namespace name.
  - Path segment being the characters found *between* slashes is 
confusing, since the last piece  of a URL is also a segment.

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?
  - Second paragraph: how might I otherwise negotiate?  The DAV:bind 
header?

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?

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

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... :)

2.5
  - last paragraph is a repeat of text two paragraphs before
  - 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.

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?

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

7.1
  - IANA notification for 208?

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?

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.

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

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:.
  - the other IANA actions i've listed above

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

Sorry some of these are nit-picky.

-- 
Joe Hildebrand
Denver, CO, USA

Received on Tuesday, 22 June 2004 22:54:20 UTC