Re: Summary on LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY

If we were starting from scratch, I would agree with Jason that
we should not be overloading the If header the way the original
authors of 2518 did, but since there are implementations that depend
on this syntax, I think it is more important to maximize interoperability
with existing clients/servers than to fix this marshalling.

So I agree with the resolutions that Julian describes below, and also
agree that no special wording/explanation is required for the shared
lock case, both since I believe it follows from the original wording,
and that shared locks are not commonly implemented in any case.

Cheers,
Geoff

Jason wrote on 06/29/2004 02:03:41 AM:
> 
> 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.