Subject: Re: LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY vs RFC2518bis-05

From: Jason Crawford <[email-masked]>
Date: Wed, 2 Jun 2004 10:16:29 -0400

> > I *do* agree that "Lock-Token" technically is a better choice to 
select 
> > the lock to be refreshed, however...:
> > 
> > - RFC2518bis is unclear about whether you'll still need to specify the 

> > "If" header in the request (because one may argue that the LOCK 
refresh 
> > request is modifying the locked state of the resource)
> > 
> > - RFC2518bis says it is "recommended" to support the old marshalling 
> > ("If" header). I think for backwards compatibilty with existing client 

> > this should be a "REQUIRED".
> > 
> > Finally, I'm not so sure that this change really makes sense. As far 
as 
> > I can tell, no widely used server currently implements the new 
> > marshalling (I just tested IIS5, Apache/moddav2 and our own). Also, 
> > clients will likely continue to use the old format anyway, because 
after 
> > all it works just fine; and IIS is unlikely to be upgraded anytime 
soon :-)
> > 
> > So either
> > 
> > 1) roll back the change in RFC2518bis, or
> > 
> > 2) add both issue and resolution, and also clarify the issues 
mentioned 
> > above in new RFC2158bis text

The old way of overloading If seems pretty lame.   Can't new clients do 
both?
Can't new servers detect which approach in being used?

I wouldn't require servers to support the old way.  Supporting the old way 
is common sense but at some point we should encourage the movement to the 
new approach.

J.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Jun 2004 16:26:38 +0200

> The old way of overloading If seems pretty lame.   Can't new clients do 

Agreed, but it works (if it ain't broke, don't fix it). Why are we 
adding completely new requirements for both servers and clients with the 
inevitable interoperability issues if the present protocol does what 
it's supposed to do?

> Can't new servers detect which approach in being used?

They could, if we clearly define how. So far we haven't.

> I wouldn't require servers to support the old way.  Supporting the old 
> way is common sense but at some point we should encourage the movement 
> to the new approach.

Well, that would break Microsoft Office. I don't think people will be 
very interested in a spec revision that doesn't work with it.

IMHO the only thing we should say is that LOCK without a request body 
*with* an If header will refresh all locks on the resource identified by 
the request URI (possibly deprecating the use of the Time-Out request 
header here -- I don't think there's a strong use case for changing the 
timeout after the lock already exists; and as far as I know existing 
servers do not support it anyway).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Jun 2004 16:37:02 +0200

> servers do not support it anyway).

Make that... "...will refresh all locks on the resource identified by 
the request URI that have been submitted in the 'If' header..."

Julian