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

Re: Relationship between BIND and RFC 3253

From: Werner Donné <werner.donne@re.be>
Date: Tue, 7 Oct 2008 17:18:02 +0200
To: Julian Reschke <julian.reschke@gmx.de>
Message-Id: <CCD70EE8-9EEA-44F2-B146-7899E38F5263@re.be>
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, w3c-dist-auth@w3.org

On 07 Oct 2008, at 16:09, Julian Reschke wrote:

> Werner Donné wrote:
>> There are indeed no additional semantics for UNCHECKOUT in section  
>> 14.
> Well, we have an erratum for UNCHECKOUT in Section 14, and Geoff has  
> already proposed a resolution; do you disagree with it?

>> Therefore, I think the semantics of section section 4.5 apply,  
>> because
>> a version-controlled collection is also a version-controlled  
>> resource.
> Yes, those apply; but how exactly do they help clarifying what the  
> server needs to do?

For me section 4.5 is complete. It says that the pre-CHECKOUT state  
should be
restored. This means that the checked-in version becomes what it was  
the CHECKOUT. The version-controlled binding set of that checked-in  
must not have changed, because the corresponding property is protected  
and the
DELETE and VERSION-CONTROL methods have the proper pre-conditions to  
prevent it.

In your original message you raise the question about what should  
happen when
a VCR has been deleted since the last check-out. This is not a  
specific matter
for UNCHECKOUT. When a DELETE is performed on a VCR that corresponds  
to member
in a checked out collection, the server is responsible for making sure  
the version-controlled binding sets of all versions of that collection  
are not

I don't think section 4.11 can apply to the UNCHECKOUT method, because  
it says
what should happen when the checked-in version of a version-controlled  
is modified. A checked out collection is a checked out resource and  
those don't
have the checked-in version property. The property is reintroduced not  

>> Though the introduction of section 14 mentions workspaces, I don't  
>> think
>> the merge feature is limited to workspaces. It is allowed to use a
>> version-controlled collection as the request URI and a collection  
>> version
>> as the source. If both would be associated with the same version  
>> history,
>> for example, it would be strange if in such a case new version- 
>> controlled
>> members would be created as described in section 4.11.
> That's possible (I haven't implemented merge); and maybe that's a  
> separate erratum.
> Anyway, I'd like to stay focused on the BIND vs RFC3253 issue -- I  
> think it's sufficient if we describe a case where RFC 3253 *clearly*  
> requires BIND semantics; so is the currently proposed text correct?

I agree that from the view point of the BIND spec this is sufficient  
and the
proposed text is correct.

> BR, Julian

Werner Donné  --  Re                                     http://www.pincette.biz
Engelbeekstraat 8                                               http://www.re.be
BE-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne@re.be
Received on Tuesday, 7 October 2008 15:18:38 UTC

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