Creating a separate Locking-bis protocol specification

Locking support (level 2 WebDAV) is explicitly optional in RFC-2518.
So I fail to see how defining it in a separate specification has anything
substantive to do with whether or not a client implementor can rely
on it being implemented in a server.

So I would phrase the question somewhat differently, e.g.:

"Separating out the optional locking semantics from RFC-2518bis and
placing it in its own separate specification allows us to resolve the 
locking issues
in RFC-2518 in a more expeditious manner.  I'd specifically like to
hear from client implementors, some of whom (Adobe) rely on locking, as
to whether they agree that it is important to resolve the locking issues
more rapidly, by de-coupling them from the rest of the issues in 
RFC-2518bis."

Cheers,
Geoff

Lisa wrote on 01/18/2005 03:06:37 PM:

> 
> Removing locking from base WebDAV is a major step.  Before we take it, 
> I'd specifically like to hear from client implementors, some of whom 
> (Adobe) rely on locking being implemented in the server.
> 
> Client implementors, please identify yourselves and speak up!
> 
> Lisa
> 
> On Jan 18, 2005, at 12:01 PM, Elias Sinderson wrote:
> 
> >
> > Julian Reschke wrote:
> >
> >> Ok,  so do we have consensus to add the following [...]?
> >
> > I've been considering the various options suggested to address this 
> > issue since it was raised, along with the various implications. For 
> > the record, I don't have any problem with the suggested language 
> > (below) being added to the BIND specification as it seems to address 
> > Lisas' concerns, while leaving the actual locking behavior specified 
> > in the core WebDAV specification.
> >
> > For future reference, I would also like to see similar clarification / 

> > specification of locking behavior in the presence of multiple bindings 

> > to a resource appear in either 2518bis or a separate locking 
> > specification. My preference, once again, is for locking to be broken 
> > out into a separate specification, as suggested and discussed 
> > previously on this list. I believe that there was /rough concensus/ on 

> > that approach the last time it came up.
> >
> >
> > Cheers,
> > Elias
> > _________________________
> >
> >> 2.x UNLOCK and Bindings
> >>
> >> Due to the specific language used in section 8.11 of [RFC2518], it 
> >> might be thought that an UNLOCK request to a locked resource would 
> >> unlock just the binding of the Request-URI.  This is not the case, 
> >> however.  Section 6 of [RFC2518] clearly states that locks are on 
> >> resources, not URIs, so the server MUST allow UNLOCK to be used to 
> >> unlock a locked resource through any binding to that resource.  The 
> >> authors of this specification anticipate and recommend that future 
> >> revisions of [RFC2518] maintain this behavior.
> >
> >
> >
> 
>