W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2004

Re: Comments on bind-08

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Mon, 29 Nov 2004 22:57:46 -0500
To: "WebDAV (WebDAV WG)" <w3c-dist-auth@w3.org>
Message-ID: <OF6C60684A.3D865178-ON85256F5C.0013354A-85256F5C.0015C487@us.ibm.com>
Julian wrote on 11/29/2004 05:58:51 PM:

> Jim Whitehead wrote:

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

Jim: I'm OK with adding the paragraph, but what was the possible 
that this additional text was intended to clear up?  How else could a 
COPY work?

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

I do not thing we need to special case this particular scenario, so I 
would vote
not to add anything to handle it.

> > * Section 2.6 -- there needs to be some discussion on the interactions 
> > DAV:resource-id and versioning. As near as I can tell, the intent is 
> > 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.

I agree with Julian.  A version is a new resource created by the CHECKIN 
According to section 2.6, a new resource must be assigned a new 
so each new version needs to be assigned a new, distinct resource-id.

> > * Section 2.6, final paragraph, last two sentences. Change "must not" 
> > "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.

I'd vote to take Jim's suggested changes here.  A UUID that is not 
by the MOVE implementation for a repository should not be a candidate for 
DAV:resource-id implementation.

> > * Section 6.2. I think it would be helpful to have an example 
> > REBIND and locks, showing submission of one or more lock tokens in the 
> > header.
> Such as one involving locked source and destination collections? That 
> may be useful. What do others think?

I continue to believe that the right place for locking examples is in a
locking spec, and that the binding spec just needs to make clear which 
and which URL mappings are being modified by an operation, since this is 
you need to know which locks are required.  I believe this information is
well-defined in the pre-conditions of the methods introduced by the 
spec.  So I'd vote not to add such an example, but I could live with it,
if a majority is for it.

Received on Tuesday, 30 November 2004 03:58:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:33 UTC