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

Re: Comments on bind-08

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Tue, 30 Nov 2004 09:32:58 -0800
Message-Id: <E0996999-42F5-11D9-B57F-000A95B2BB72@osafoundation.org>
Cc: "WebDAV (WebDAV WG)" <w3c-dist-auth@w3.org>
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>

Weighing in...

On Nov 29, 2004, at 7:57 PM, Geoffrey M Clemm wrote:

> 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 
>>> 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.
> Jim: I'm OK with adding the paragraph, but what was the possible
> misunderstanding
> that this additional text was intended to clear up?  How else could a
> Depth=infinity
> COPY work?

I agree with Jim that we should add clearer wording here.  The 
ingenuity of
implementors is great, and that includes a surprising ability to come to
different conclusions than the writers of a specification.

>>> * 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.
> I agree with Julian.  A version is a new resource created by the 
> CHECKIN method.
> According to section 2.6, a new resource must be assigned a new 
> resource-id,
> so each new version needs to be assigned a new, distinct resource-id.

Great -- so we agree on what should happen.  As Jim suggests,
let's put it in the spec.

>>> * 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?
> 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 
> resources
> and which URL mappings are being modified by an operation, since this 
> is all
> 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 
> binding
> spec.  So I'd vote not to add such an example, but I could live with 
> it,
> if a majority is for it.

An example with locks and REBIND would be great.  Other examples with 
and bound resources (and requirements about what URL must be 
in the requests) would also be great.

Received on Tuesday, 30 November 2004 17:33:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:31 UTC