Subject: RE: [Bug 2] Bindings needs to completely describe how bindings in teract with locks.

From: "Fay, Chuck" <[email-masked]>
Date: Fri, 14 Jan 2005 12:39:42 -0800

I like Joe's suggestion, but I would word it differently, because part
of 2518's description of UNLOCK is flawed and misleading.  Note that it
says "The UNLOCK method removes the lock... from the Request-URI", not
from the *resource* identified by the Request-URI.  It is clearly stated
elsewhere in 2518 that "locks apply to resources, not URIs," and the
sentence on UNLOCK goes on to talk about "all other resources included
in the lock."  So the sentence is internally inconsistent.  If one
relied just on this misleading portion of the description of UNLOCK from
2518, one could mistakenly conclude that locks are on URIs, not
resources, and hence an UNLOCK on a URI other than the one used in the
original LOCK operation would fail.  I think this is at the heart of
Lisa's concern.

So I would rework Joe's suggestion this way, so that it doesn't rely on
the flawed definition of UNLOCK:

<blockquote>
   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. [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,
   given an otherwise well-formed and permissioned request.  The
   authors of this specification anticipate and recommend that future
   revisions of [RFC2518] maintain this behavior.
</blockquote>

--Chuck Fay, FileNet Corporation, Costa Mesa, CA
phone:  (714) 327-3513, fax:  (714) 327-5076, email:  [email-masked] 

-----
Joe Hildebrand wrote:
> > > like "The server MUST allow UNLOCK to work on any binding
> > to a locked
> > > resource, given an otherwise well-formed and permissioned request"
> > > (some standards-track document, not an email list or bug db), the 
> > > requirements for interoperability have minimally been met.
> > 
> > But that's what RFC2518 already says
> > (<http://greenbytes.de/tech/webdav/rfc2518.html#METHOD_UNLOCK>):
> > 
> > "The UNLOCK method removes the lock identified by the lock token in 
> > the Lock-Token request header from the Request-URI, and all other 
> > resources included in the lock. If all resources which have been 
> > locked under the submitted lock token can not be unlocked then the 
> > UNLOCK request MUST fail."
> 
> 
> How about this.  Section 2.3 of BIND has this language:
> 
> <blockquote>
>    It might be thought that a COPY request with "Depth: 0" on a
>    collection would duplicate its bindings, since bindings are part of
>    the collection's state.  This is not the case, however.  The
>    definition of Depth in [RFC2518] makes it clear that a "Depth: 0"
>    request does not apply to a collection's members.  Consequently, a
>    COPY with "Depth: 0" does not duplicate the bindings 
> contained by the
>    collection.
> </blockquote>
> 
> And 1.2 has this:
> 
> <blockquote>
>    The authors of this specification anticipate and
>    recommend that future revisions of [RFC2518] will update the
>    definition of the state of a collection to correspond to the
>    definition in this document.
> </blockquote>
> 
> If there was an extra paragraph in BIND that pulled from the 
> spirit of these two existing statements, could we move 
> forward?  Something like:
> 
> <blockquote>
>    It might be thought that an UNLOCK request to a locked resource
>    might unlock just that binding.  This is not the case, 
> however.  The
>    definition of UNLOCK in [RFC2518] makes it clear that the 
> server MUST
>    allow UNLOCK to work on any binding to a locked resource, given an
>    otherwise well-formed and permissioned request.  The 
> authors of this
>    specification anticipate and recommend that future revisions of
>    [RFC2518] maintain this behavior.
> </blockquote>
> 
> This doesn't change 2518.  It doesn't over-specify.  It 
> provides guidance for implementors, and makes clear the 
> relationship with 2518bis.
> 
> --
> Joe Hildebrand

---

From: Julian Reschke <[email-masked]>
Date: Fri, 14 Jan 2005 21:52:35 +0100

>    revisions of [RFC2518] maintain this behavior.

I like this better, as it actually attempts to give a reason *why* 
somebody would think that. Thinking of it, the language could be even 
more precise here. I'd also prefer to lose the part about "given an 
otherwise well-formed and permissioned request" because that IMHO is 
just fluff and distracting (of course a LOCK will fail when there's 
something else wrong with the request or the state of the resource).

Proposal:

"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."

Best regards, Julian

PS: great to see you back on the mailing list, Chuck.

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 14 Jan 2005 23:04:30 -0500

I agree that it would be desireable to add the statement Joe suggests
to the binding specification, and I like the editorial changes suggested
by Chuck and Julian.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Jan 2005 20:37:15 +0100

> to the binding specification, and I like the editorial changes suggested

Ok,

so do we have consensus to add the following subsection to section 2 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#overview.of.bindings>)?

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.

Best regards, Julian

---

From: Elias Sinderson <[email-masked]>
Date: Tue, 18 Jan 2005 12:01:28 -0800

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 
> resources, not URIs, so the server MUST allow UNLOCK to be used to 
> unlock a locked resource through any binding to that resource.  The

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Jan 2005 21:08:43 +0100

> core WebDAV specification.

Thanks.

> approach the last time it came up.

There was definitively a lot of support, but I'm not sure I'd call it 
"rough consensus". Anyway, as RFC2518bis seems to be stuck (little 
progress in the last year and no progress at all in the last six 
months), it makes a lot of sense to put that option back on the table.

On the other hand, I don't want to distract from the BIND last-call, so 
maybe we should discuss this in a few weeks.

Best regards, Julian

---

From: Brian Korver <[email-masked]>
Date: Tue, 18 Jan 2005 13:48:15 -0800

Seems like good text to add.

-brian
[email-masked]

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 18 Jan 2005 12:06:37 -0800

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:

> 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.
>
> 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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 18 Jan 2005 18:44:49 -0500

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

---

From: Ted Hardie <[email-masked]>
Date: Tue, 18 Jan 2005 16:08:00 -0800

A working group has the opportunity when revising a standard
to declare a previously optional aspect of the original spec to be
mandatory.  It happens quite frequently in security documents
(where there is almost a track of new algorithms starting as
optional, becoming mandatory, then being deprecated), and
it happens often enough in APPs contexts that no one would
be surprised if a locking draft that succeeded RFC-2518's
description of locking declared it mandatory.

I am not saying that this *should* happen, but the discussion
of a successor document should take into account that this
would be in scope for such a document.

			regards,
				Ted Hardie

At 6:44 PM -0500 1/18/05, Geoffrey M Clemm wrote:
>placing it in its own separate specification allows us to resolve 
>the locking issues
>more rapidly, by de-coupling them from the rest of the issues in RFC-2518bis."
>
>Cheers,
>Geoff
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Jan 2005 01:35:46 +0100

> Removing locking from base WebDAV is a major step.  Before we take it,

We remove it from the *document* and move into a different document. 
Locking was optional in RFC2518, and things will be the same afterwards.

> (Adobe) rely on locking being implemented in the server.

So does Apple. I'm not sure how this is relevant? Please be more specific.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Jan 2005 01:42:31 +0100

> would be in scope for such a document.

Thanks for the clarification, Ted.

Personally, I think this would be a step into the wrong direction. There 
are scenarios out there today that work perfectly fine without locking, 
and there are servers that do not support locking at all, or do not 
support it for specific resources.

Making locking mandatory in future specs will not affect these servers 
(nor the clients that work with them). In the best (or worst?) case they 
will be upgraded to include other -bis features, claim compliance but 
still will not support locking.

On the other hand, clarifying that locking *is* optional, and publishing 
a much simpler base WebDAV spec (sans locking) my actually convince 
potential server implementers to implement those parts of RFC2518 
(namespace operations + metadata) and therefore increase WebDAV's 
acceptance.

Best regards, Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Tue, 18 Jan 2005 17:08:00 -0800

Moving locking issues into another draft doesn't reduce the complexity of
the locking issues; it just moves text. If an issue is contentious in
2518bis, it will still be contentious in 2518bis-lock. 

Moving locking to a separate document won't speed the overall process,
because approval of this document will still be gated on completion of the
rest of the 2518bis edits, to ensure there aren't inconsistencies.

Locking should not be split out from the rest of 2518bis. 

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Jan 2005 02:24:19 +0100

> 2518bis, it will still be contentious in 2518bis-lock. 

It reduces the amount of work for the editors of RFC2518bis (who seem to 
have trouble spending time on it). Also, as far as I can tell, almost 
all of the issues with locking have been resolved on the mailing list 
(see 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-issues.html>).

> rest of the 2518bis edits, to ensure there aren't inconsistencies.

That would be only true if the intent would be to submit both of them as 
"Draft". *My* intent (when I made that proposal initially and while 
working on it) was to submit it as "Proposed", so RFC2518bis (base) and 
the locking spec can really become independent of each.

So the timeline would be something like:

#1: finish the separated locking spec, updating RFC2518, publish as 
"proposed"

#2: finish RFC2518bis minus locking, publish as "draft"

#3: advance the locking spec to draft as well (another competing spec to 
go to "draft" would be DeltaV).

As far as I can tell, once the WG agrees on that plan we could be done 
with #1 this spring.

> Locking should not be split out from the rest of 2518bis. 

I'd be tempted to agree if I had any idea about when work will continue 
on RFC2518bis.

Best regards, Julian