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

Re: Relationship between BIND and RFC 3253

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 07 Oct 2008 17:33:24 +0200
Message-ID: <48EB8144.2010403@gmx.de>
To: Werner Donné <werner.donne@re.be>
CC: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, w3c-dist-auth@w3.org

Werner Donné wrote:
>> 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 before
> the CHECKOUT. The version-controlled binding set of that checked-in version
> 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.

But we're talking about the pre-CHECKOUT state of the *collection*, not 
its member.

> 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

Did I? I don't think so, but maybe I'm confused. Can we stick to the 
example that I proposed? Is there something wrong with it?

> 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 that
> the version-controlled binding sets of all versions of that collection 
> are not
> affected.

Yes.

> 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 
> collection
> 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 
> modified.

UNCHECKOUT changes the state of the collection to be checked in, so yes, 
I would claim that operation affects the DAV:checked-in property.

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

Great!

I didn't mean to prevent other discussions, I just want to get things 
done step by step...

BR, Julian
Received on Tuesday, 7 October 2008 15:34:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:16 GMT