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

RE: Comments on bind-08

From: Jim Whitehead <ejw@cs.ucsc.edu>
Date: Wed, 1 Dec 2004 11:56:46 -0800
Message-Id: <200412011956.iB1JurjQ019374@cats-mx4.ucsc.edu>
To: "'WebDAV \(WebDAV WG\)'" <w3c-dist-auth@w3.org>

Julian and Lisa write:

> >> 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.
> Again, before we put additional spec into the spec, it should 
> be clear what problem it solves. I understand that you lean 
> to "more is better", but please acknowledge that many people 
> writing specs disagree.

The problem concerns the definition of "resource" and "identity" you use in
developing your implementation of DAV:resource-id. Since the discussion of
DAV:resource-id does not specifically discuss versioning, someone could read
the DeltaV spec and the bind specification, and reasonably assume that the
authors of the bind specification hadn't actually thought about the
interactions of DAV:resource-id and versioning. In this case, that same
reader might then think that the intent was to give each logical resource
(e.g., the abstract concept of all versions of a document) a unique
identifier, rather than each version. Such a person might then make their
implementation give each version in a version history the same
DAV:resource-id, and then have each VCR associated with this version history
expose the same DAV:resource-id.

While a very careful reading of both specifications would lead you to not do
this, I'll stress again that we need to assume the person with the incorrect
model will not be actively seeking disconfirming evidence.

> I'm not sure how locking examples for REBIND are going to help much. 
> REBIND is just like MOVE, except for slightly different 
> marshalling. I'm 
> not against adding an example per se, but if we do it it 
> should really 
> contain something that's not available elsewhere.

There have been many client implementation problems with the If header. More
examples might help reduce these implementation problems.

- Jim
Received on Wednesday, 1 December 2004 20:01:37 UTC

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