Re: Summary on LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY

On Wednesday, 06/09/2004 at 03:24 ZE2, Julian Reschke 
<julian.reschke@gmx.de> wrote:
> Julian Reschke wrote:
> >
> > OK,
> >
> > here's my attempt to summarize what Lisa and I discussed. I think this
> > should be used as resolution for the following issues:
> >
> > - LOCK_BODY_SHOULD_BE_MUST
> > - LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY
> >
> > Note that the description below does *not* change the original
> > semantics; it's just a clarification that seems to be in sync with
> > current implementations (and that's what we should be looking for when
> > updating the protocol)...:
> >
> > 1) A LOCK request with message body is a LOCK create request. A LOCK
> > request without a message body is a LOCK refresh request.
> >
> > 2) A LOCK refresh request refreshes those locks on the request 
resource
> > whose lock tokens are submitted in the "If" header and whose lock-root
> > is the resource identified by the request URI. A server MAY support
> > using the Time-Out header to set a new timeout, but clients can not 
rely
> > on that behaviour.
> >
> > 2a) In the case of a shared lock it's technically feasable to submit
> > lock tokens for multiple locks to be refreshed in one "If" header. The
> > semantics for that seem to be clear from 2), but it's doubtful whether 
a
> > client will ever want to do that. IMHO it doesn't make any sense to 
put
> > in the additional wording to forbid it, though (that's where I 
disagreed
> > with Lisa...).
> >
> > Note that if we stick with this resolution, the LOCK refresh changes 
in
> > RFC2518bis-05 will need to be rolled back.
> 
> OK,
> 
> can we please make a decision?

I really don't like using the If header for so many purposes, but I'm 
willing to give up on that point to get the spec out the door.  Let's hear 
some opinions on what Julian has said above.

J.