RE: BIND and DAV:checkout-set property

One could equally well make the argument that a binding-unaware
client would be even more surprised when it encounters a checked-out
resource whose URL does not appear in the DAV:checkout-set of
its DAV:checked-out version. 

I do not see anything in the current specification language that
requires a server to do it one way or the other, so until we 
get a compelling reason to do it one way or the other, I'd probably
leave the language as it is.

Cheers,
Geoff

"Julian Reschke" <julian.reschke@greenbytes.de> wrote on 09/01/2003 
05:42:56 AM:

> > From: ietf-dav-versioning-request@w3.org
> > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Geoffrey M 
Clemm
> > Sent: Sunday, August 31, 2003 3:57 AM
> > To: 'ietf-dav-versioning@w3.org'
> > Subject: Re: BIND and DAV:checkout-set property
> >
> >
> >
> > RFC-3253 leaves this up to the server implementation.
> > So you can do whatever is easier for your server.
> > ...
> 
> I think this is wrong, and as far as I remember, we already discussed 
this
> question some time ago and came to a different conclusion.
> 
> In this particular case, the spec says:
> 
> "This property identifies each checked-out resource whose 
DAV:checked-out
> property identifies this version."
> 
> That is, if there's only one checked-out resource and two bindings, 
there
> should be only one href element, giving one of the bindings.
> 
> If a server would report all bindings, a non-binding-aware client might
> conclude that there are in fact multiple checked-out resources which is 
not
> the case.
> 
> Anyway: we clearly should work on a clarification of RFC3253 regarding
> bindings.
> 
> Julian
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 

Received on Monday, 1 September 2003 22:28:28 UTC