Re: Relationship between BIND and RFC 3253

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

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

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.

>
>
>> 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.
--
Werner Donné  --  Re                                     http://www.pincette.biz
Engelbeekstraat 8                                               http://www.re.be
BE-3300 Tienen
tel: (+32) 486 425803	e-mail: [email protected]