Re: Comments on bind-08

Jim Whitehead wrote:
> I gave the latest WebDAV Bindings Protocol specification a careful read
> today, and was generally very impressed by the solidity of the
> specification. I have a number of comments (below) which mostly seek to
> clarify the intent of the specification. I'm fine with these being
> considered last-call comments if the WG wants to proceed with a WG last call
> on the -08 specification -- IMO, the specification is certainly ready for
> such a review.

Thanks.

> Also, I'm not sure whether current WG practice is for those submitting
> comments to directly enter them into the issue tracking system. If so, let
> me know, and I'll enter these in.

I don't have any preference. At the end of the day, discussion needs to 
take place on the mailing list anyway.

> OK, the comments:
> 
> * Terminology section (1.1): There is a reference to
> draft-fielding-rfc2396bis here, and also in Section 3.2 (perhaps it occurs
> elsewhere in the specification as well). References in RFCs need to be to
> documents of RFC level stability (or equivalent). If
> draft-fielding-rfc2396bis hasn't yet been approved by the IESG, we should
> just revert back to RFC 2396.

It has been approved in September and is on in the RFC Editor's 
publication queue. If it get's published before we are done we'll update 
the draft ourselves, otherwise it'll be part of the publication process 
anyway.

> * Section 2, paragraph 3. The language here would preclude the future
> definition of a DESTROY method which had the semantics of removing the state
> of a resource from a server, irregardless of any containment relationships
> that may hold it. Such a method could be quite useful for records management
> functionality, in order to implement a records disposition policy that
> specified deletion at a certain time. My recommended tweak to the language
> of section 2 is minor: add the following sentence to the end of the
> paragraph:
> 
> "It is permissible, however, for future method definitions (e.g., a DESTROY
> method) to have semantics that remove all bindings and/or immediately
> reclaim system resources."

I'm fine with stating that it's possible to define a method that 
*explicitly* has that semantics (affecting other bindings). How about...:

"It is permissible, however, for future method definitions (e.g., a 
DESTROY method) to have semantics that explicitly remove all bindings 
and/or immediately reclaim system resources."

> * Section 2.1. I think it would be more clear to separate out the discussion
> of loops and bindings, and make it a separate section (say, 2.2) This issue
> comes up frequently enough that it would be good to make it easy to find
> this issue in the TOC. Also, a mention of the Already Reported status code
> would be good to have here, since it also mentions 506.

The last sentence of the first paragraph already mentions the 506 status.

Would adding a new subsection ("Bind Loops") and moving the first 
paragraph of 2.1 into that subsection be what you have in mind?

> * Section 2.3. This section doesn't clearly address the semantics of COPY
> with Depth infinity. My recommendation is to add, after paragraph 3, text
> like this:
> 
> "As specified in [RFC2518], a COPY with Depth infinity causes the collection
> resource to be duplicated, all of its bound children to be duplicated, and
> their children's bound children, and so on, to the bottom of the containment
> hierarchy. All of the segments of the bindings of the destination collection
> are the same as for the destination collection. However, the destination
> resource for all bindings in the destination collection are different from
> those of the source collection, since all resources have been duplicated,
> creating new resources with distinct DAV:resource-id properties."

As far as I understand, the depth:infinity semantics for COPY follow 
from what's being said about depth:0 and the RFC2518 infinity semantics 
(just checking...). Thus, I'm not convinced that we need to say this, 
but it probably wouldn't hurt either. Feedback appreciated.

> * There should also be some text addressing COPY depth infinity and loops --
> in some instances during a COPY with Depth infinity, the server really wants
> to recreate the binding that causes the loop, rather than continuing to make
> duplicate resources. This is somewhat addressed by the final paragraph in
> Section 2.3, but not exactly.

I thought it was. Could you be more specific. Maybe expand that 
statement so that it becomes clear that this applies to loop situations 
as well?

> * One gap in the current COPY semantics is the ability to copy a collection
> and its bindings. COPY depth 0 says copy all non-binding state. COPY depth
> infinity copies all bindings and makes duplicates of all bound resources.
> But, there's no single atomic operation (call it BINDDUP) that duplicates
> the collection and its bindings, but doesn't duplicate the bound resources.
> That is, there is no operation that does a COPY Depth 0 plus BIND for all
> members. So, two questions. Is there a compelling scenario for having a
> BINDDUP method? I confess I'm having a hard time coming up with one. Second,
> assuming there is a compelling scenario, can it be accomplished just using
> COPY, LOCK, and BIND, rather than having a special purpose method. Also
> unclear.

I do agree we don't have that. I have no idea whether anybody needs it. 
If it's needed, you can get very close to it using MKCOL, LOCK, n * BIND 
and UNLOCK.

> * It might make sense to create an example covering the situation described
> in the final paragraph of Section 2.3. I'm not 100% sure I know what
> scenario this paragraph addresses, other reading the spec. for the first
> time would presumably have a tougher time.

Agreed. I'll give it a try.

> * Section 2.4, second paragraph. "MUST NOT" is used in the text of an
> example -- seems like it should be lower case here instead.

Agreed.

> * Section 2.6 -- there needs to be some discussion on the interactions of
> DAV:resource-id and versioning. As near as I can tell, the intent is that
> every revision will have a unique DAV:resource-id value.

That's correct. I'm not sure why we would need to state this -- a 
version resource clearly is not the same resource as it's VCR, so it 
seems clear they'll never have the same DAV:resource-id.

> * Section 2.6 -- I think it would help clarify the text to say that one
> possible implementation technique is to use a GUID for the unique
> identifier, and then reference the same GUID document as is referenced in
> RFC 2518.

That's in section 3.1 (definition of DAV:resource-id property), isn't it?

> * Section 2.6, final paragraph, last two sentences. Change "must not" to
> "MUST NOT" (and eliminate the "For example" at the start of the sentence --
> perhaps change to "Specifically,"

I agree for PUT/COPY, but things get unclear when we talk about MOVE (as 
RFC2518 allows this to be implemented in terms of COPY/DELETE). REBIND, 
on the other hand, has that property. Feedback appreciated.

> * Section 2.6. Need to add a note indicating that REBIND does not affect the
> value of DAV:resource-id.

See :-)

> * Section 3.2, final sentence -- delete the word "either", add a comma after
> "or".

OK.

> * Section 3.2. I think it would be helpful to have an example of this
> property. I'd be happy to help develop such an example.

Agreed.

> * Section 4. The intent of the BIND method is for its behavior to be atomic.
> However, this is never actually stated explicitly in the specification.
> Seems like it should be.

Yes. Probably the same for UNBIND (REBIND already mentions it). Text 
suggestion welcome.

> * Section 4. Need a new condition to cover the case where the BIND
> half-succeeded, and then needed to be rewound. This condition would address
> the case where Overwrite is true, the destination binding has been removed,
> but the new binding couldn't be created.

But then it wouldn't be atomic, right?

> * Section 4.1, final sentence. Remove comma after the URI.

OK.

> * Section 5. Same comment as for BIND. The intent of UNBIND is that it's
> supposed to be atomic, but that's never explicitly stated.

200.

> * Section 5. I think we need a condition for a cross-server UNBIND failure.

Could you please describe that situation in more detail?

> * Section 6. Same comment as for BIND, UNBIND. The intent of REBIND is to be
> atomic, but this is not explicitly stated.

Last sentence of first paragraph, but I do agree it could be improved. 
As you said, same as for BIND and UNBIND.

> * Section 6. Should precondition DAV:rebind-into-collection be named
> DAV:rebind-from-collection, to mirror the similar precondition for UNBIND?

Agreed. Not sure why it was inconsistent.

> * Section 6. Precondition DAV:rebind-source-exists is incorrect. The
> DAV:href element identifies the destination binding to be created, not the
> source. Seems like this precondition, and the previous one, reflect an older
> marshalling of the arguments.

Agreed. I think we should keep the precondition, but it needs to say:

"The Request-URI plus the DAV:segment in the request body element MUST 
identify a non-null resource."

> * Section 6.2. I think it would be helpful to have an example including
> REBIND and locks, showing submission of one or more lock tokens in the If
> header.

Such as one involving locked source and destination collections? That 
may be useful. What do others think?

> * Section 7.1.1. Might just be a personal preference, but I'd rather see
> plain GUIDs rather than opaqulocktoken URI GUIDs in the example.

A plain GUID isn't a legal URI. And unfortunately, there's still (!) no 
registered URI scheme except "opaquelocktoken" that's based on UUIDs (== 
GUIDs) -- "urn:uuid" seems to be dead.

> That's it.

Thank you very much for the review. I'll do the editorial changes right 
away and add the other points to the issues list on a case-by-case once 
we agree that we should change the current text.

Best regards, Julian

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

Received on Monday, 29 November 2004 22:59:36 UTC