Subject: Re: [Bug 2] Bindings needs to completely describe how bindings interact with locks.

From: Lisa Dusseault <[email-masked]>
Date: Thu, 13 Jan 2005 16:01:41 -0800

I keep re-opening this issue because the spec still doesn't say what 
the server MUST do or what the client must be prepared to handle.  I 
don't care how you answer it on the list or in bugzilla; I am not even 
arguing for any specific answer.  I am arguing for some *specification* 
here.

These answers may follow from RFC2518 in your interpretation, but there 
have been and will be other interpretations.  Without clear guidance, 
some clients will assume that the URL that they query (the target of 
PROPFIND) is the one that MUST appear in the lockdiscovery property for 
that URL, and that if another URL appears the server must be broken.  
Some clients will associate only one URL with each locktoken and be 
confused if the same locktoken appears on some other URL.   Some 
clients will assume that if a URL that they query is locked (and they 
have the lock token, etc) they can UNLOCK the same URL.   If server 
implementors aren't forced to make compatible choices, then we will 
have interoperability problems surrounding bindings.  We have 
specifications not just so we can explain the model, but also to make 
requirements of implementors.

Lisa

On Jan 13, 2005, at 3:44 PM, [email-masked] wrote:

> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2
>
>
>
>
>
> ------- Additional Comments From [email-masked]  
> 2005-01-13 15:44 -------
> I'm not sure why you keep re-opening this issue. Your particular 
> questions
> answered in 
> <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2#c1>, and
> these answers follow from what RFC2518 already says.
>
>
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 13 Jan 2005 21:16:10 -0500

Lisa, you say the same thing every time, and we give the same
response every time (:-).  Locking behavior for RFC2518 features
(multiple URLs mapped to the same resource) needs to be defined by the
locking specification, not by the BIND specification.  Otherwise,
there will be mass confusion when the locking specification says
one thing and the BIND specification says something else.
The question of whether or you can apply UNLOCK to a locked resource
using a URL other than the one the LOCK was applied to is an open
question for the locking specification, and the BIND protocol
is not the place to resolve that open locking question (the same question
applies to depth locks, which have nothing remotely to do with the
BIND protocol).

OK, Joe, here's our first test of the "rough consensus" mechanism (:-).

Cheers,
Geoff

---

From: Neal Gafter <[email-masked]>
Date: Thu, 13 Jan 2005 18:35:33 -0800

I don't see how the locking specification (2518) can possibly say
anything about this, as there is no way without the bind spec of
getting more than one URL to the same resource.

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 13 Jan 2005 21:52:41 -0500

Hi Neal,

It's great to have someone other than usual culprits (:-) contribute
to the discussion!

Although the 2518 does not provide a standard method for mapping a
resource to more than one URL, it does explicitly state that in the
WebDAV model, multiple URLs may identify the same resource.
In particular, section 5.1 of RFC2518 states:

"Although implicit in [RFC2068] and [RFC2396], any resource, including
 collection resources, MAY be identified by more than one URI. For 
example,
 a resource could be identified by multiple HTTP URLs."

So since having multiple URLs identify the same resource is part of
the 2518 model, how locks behave when multiple URLs identify the same
resource must be defined by the locking model for 2518.

On the other hand, the BIND specification must specify the locking 
semantics of anything new that it introduces, which is the BIND, REBIND,
and UNBIND methods.  And the locking behavior of those methods is
defined in the BIND specification.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Fri, 14 Jan 2005 09:43:54 +0100

> It's great to have someone other than usual culprits (:-) contribute

+1.

>  collection resources, MAY be identified by more than one URI. For example,

I'd also like to add that

- RFC2616 (the base protocol that we extend) also includes this concept,

- RFC3253 (versioning) speaks of bindings and some RFC3253 operations 
indeed can create additional bindings to a resource, thus it's really 
time to actually get the BIND spec out of the door :-), and

- that just because you don't have a specific WebDAV method to 
explicitly create bindings that doesn't mean that you can't create them 
at all (for instance, a server that maps directly to an underlying POSIX 
filesystem would naturally expose file system hard links as WebDAV 
bindings). (That's similar to although only the unfinished REDIRECTREF 
spec defines an explicit method to create a redirect resource, you 
already see lots of HTTP resources that answer with 301/302 status 
codes, right...?).

Best regards, Julian

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 14 Jan 2005 10:15:08 +0100

Lisa Dusseault wrote:
> I keep re-opening this issue because the spec still doesn't say what the 
> server MUST do or what the client must be prepared to handle.  I don't 
> care how you answer it on the list or in bugzilla; I am not even arguing 
> for any specific answer.  I am arguing for some *specification* here.

Lisa,

it would be helpful if you would indeed *read* my replies. See 
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2#c1>..:

"General statement: it's not the BIND spec's job to resolve open issues 
with RFC2518's defintion of locking. RFC2518 explicitly allows multiple 
URIs to be mapped to the same resource (see for instance section 5.1), 
thus if there's some doubt about lock semantics, it needs to be 
clarified in RFC2518bis.

That being said, both questions can be answered by looking in RFC2518:

- the value of the DAV:lockdiscovery property will be the same, as both 
bindings refer to the same resource, and the lock is on the resource 
(RFC2518, section 13.8)

- UNLOCK removes the lock identified by the lock token from the resource
identified by the request-URI (and all other resources included in the 
lock), so again, it doesn't matter to which binding the UNLOCK is 
applied (section 8.11)"

So I *both* answered the actual questions *and* explained how it is 
indeed specified through RFC2518 and BIND. So in order to have a 
constructive discussion, you'd need to challenge these statements.

> that URL, and that if another URL appears the server must be broken.

I don't know what you're talking about. Where is the URI supposed to 
appear inside the DAV:lockdiscovery element at all? We're talking about 
RFC2518 + BIND, not RFC2518bis, right? (see 
<http://greenbytes.de/tech/webdav/rfc2518.html#PROPERTY_lockdiscovery>)

> confused if the same locktoken appears on some other URL.   Some clients 

Then they are buggy according to RFC2518 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.3>). 
Can you name a client that has this problem?

> will assume that if a URL that they query is locked (and they have the 
> lock token, etc) they can UNLOCK the same URL.   If server implementors 

They can.

> aren't forced to make compatible choices, then we will have 
> interoperability problems surrounding bindings.  We have specifications 
> not just so we can explain the model, but also to make requirements of 
> implementors.

Nobody argues with that. Can we please get back to the question *what* 
you think is underspecified?

Finally, a general note on "what to UNLOCK". A properly written client 
will apply UNLOCK to the URI where it originally applied the LOCK 
request to. It's supposed to keep this information anyway.

Questions about what to UNLOCK in case of "lock stealing" (removing a 
lock created by a different client (instance)) are interesting but 
really about an edge case that should not occur during normal operation. 
  It's fine to discuss this in the context of RFC2518bis (DAV:lockroot 
child element, for instance), but this has nothing to do whatsover with 
BIND.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 14 Jan 2005 07:40:43 -0500

I agree with everything Julian says here, including the fact that RFC-2518
answers both of these questions.  When I said that "there is an issue to 
be
resolved", I was referring to a suggestion that RFC-2518bis change the 
semantics
of RFC-2518 to require that an UNLOCK be applied to the request-URL of the
original LOCK request, but my understanding is that the most recent 
consensus
is that RFC-2518bis not make this change, and stay consistent with 
RFC-2518
and allow an UNLOCK request to be applied to any resource locked by the 
lock.
Thus one of the two questions that Lisa states should be answered by the
BIND spec is an issue being explicitly discussed in the context of 
RFC-2518, 
which illustrates why these issues need to be handled by RFC-2518bis (or 
preferably,
by a separate specification that is devoted to locking).

Cheers,
Geoff

> > I keep re-opening this issue because the spec still doesn't say what 
the 

> > confused if the same locktoken appears on some other URL.   Some 
clients

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 14 Jan 2005 09:38:01 -0800

Does this mean that we agree that some specification must describe  
binding/locking interaction?  As long as some document says something  
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.

Now let's discuss which specification should say these kinds of things.

1) Bindings spec should say it.  This works great -- it's a small  
clarification to add to a document which already describes bindings,  
and since it depends on RFC2518 it's perfectly easy to add text to  
describe how bindings works with the features described in RFC2518.   
Then Bindings can go to RFC, depending only on other RFCs.  Easy, done.

2)  RFC2518 should say it.  Oops, too late.  As you point out, RFC2518  
didn't fully specify bindings -- it only described that they might  
exist.  As did RFC2616.  This is pretty typical, similar to the way  
variants are described as being possible in RFC2616 but it doesn't  
fully describe how they work (e.g. with PUT).  Without a full  
specification, such a feature (bindings without the Bindings draft, and  
variants today) is not fully interoperable -- bindings and variants may  
exist, but servers may handle them differently, and clients have no  
reliable way of authoring them.  That's why we write a bindings spec,  
to fully specify how bindings work.

3) RFC2518bis should say it.  Well that's not an RFC yet, so this is  
problematic.  How can the Bindings draft go to RFC if it depends on  
something that's still a draft?  And why would you *want* to block  
Bindings behind a draft to revise WebDAV?  It's not necessary.  Why  
would you want to create this dependency?

4) Write some other document on "Interactions between Bindings and  
Locking".  This would be a companion to both the bindings specification  
and the locking specification but separate from both.  If implementors  
remember to consult this, it's a fine place to put information which  
discusses the interaction between two features.   Now Bindings has a  
dependency on another Internet-Draft, but this is a small one and  
should be easy to progress.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Fri, 14 Jan 2005 18:58:11 +0100

> binding/locking interaction?  As long as some document says something  

Yes. I think we only disagree about which spec, and whether the current 
language in RFC2518 is sufficient for now (which I think).

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

Also note that this has an entry on RFC2518's official issue list 
(<http://www.webdav.org/wg/rfcdev/issues.htm, entry 65) which says:

"Resolved that you can specify any URL locked by the lock you want to 
unlock. 
(http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0027.html )"

So it's even on the IETF-registered errata list (as "resolved"). Why 
would a new only indirecty related spec need to duplicate that information?

> Then Bindings can go to RFC, depending only on other RFCs.  Easy, done.

Drawbacks:

- makes the spec more complex
- adds normative language about a feature which is *completely* 
orthogonal to BIND
- risks conflicting specification in RFC2518bis

> exist.  As did RFC2616.  This is pretty typical, similar to the way  

Yes, but again, the language in RFC2518 is absolutely sufficient here. 
We're not talking about an IETF document going to "Full Standard", we're 
talking about "Proposed".

> to fully specify how bindings work.

In particular, we write the spec in a way that bindings fit well into 
the model established by HTTP and WebDAV, and thus *don't need* to 
specify their particular interaction with some optional (!) WebDAV features.

> 3) RFC2518bis should say it.  Well that's not an RFC yet, so this is  

Speaking of which, what is it's status?

> something that's still a draft?  And why would you *want* to block  

It wouldn't be able, but it doesn't, so this isn't an issue.

> would you want to create this dependency?

Nobody has suggested that (as far as I can tell).

> should be easy to progress.

Doesn't seem to be different from 1, except that it's an additional 
document.

BTW: you forgot to mention option #5, which is to split out locking from 
RFC2518bis and try to get that published as "Proposed Standard" ASAP. 
Most of the work has already been done in 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html>.

Best regards,

Julian