Re: Comments on bind-08

OK,

I'm going back to Jim's original issues list to ensure that we are on 
the page re: answers, fixes, issues and open questions (that are not yet 
on the issues list).

Jim Whitehead wrote:
> ...
> * 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.

I think this answered.

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

Fixed: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2_allow_destroy>

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

Fixed:
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.1_separate_loop_discussion>

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

Issue opened 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.3_copy_depth_infinity>, 
but unclear whether we really need additional text. Feedback to Geoff's 
and my question 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.

Issue opened: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.3_copy_example>.

> * 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 think we have consensus that we don't need to consider this case as 
important enough to require special discussion or even a new method.

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

Issue opened (see above): 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.3_copy_example>. 
Q: would an example involving a COPY of a BIND loop resolve both issues?

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

Fixed: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.2.4>.

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

IMHO still unclear. Awaiting feedback explaining why a reader of both 
specs would come to the conclusion that a version is the "same resource" 
as the VCR.

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

Answered (it's a URI).

> * 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,"

Issue tracked as: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.6_when_do_ids_change>. 
Do we need additional changes?

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

See above.

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

Fixed: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.3.2>

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

Issue opened: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.3.2_example>.

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

Issue opened and resolved:
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.atomicity>

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

Still under discussion.

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

Fixed: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.4.1>

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

Issue opened and resolved:
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.atomicity>

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

Still under discussion.

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

Issue opened and resolved:
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.atomicity>

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

Fixed: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.6>

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

Rewritten as:

       (DAV:rebind-source-exists): The Request-URI plus the DAV:segment
       in the request body element MUST identify a 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.

Still discussing this...

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

Still discussing this.


Best regards, Julian


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

Received on Tuesday, 30 November 2004 20:15:57 UTC