Re: BIND, lock root, and clarifying RFC4918

Lisa Dusseault wrote:
> 
> I've been discussing the BIND draft's appendix A 
> <http://tools.ietf.org/html/draft-ietf-webdav-bind-25#appendix-A> with 
> Julian, and he asked me to post my opinion publicly.
> 
> There are two possible meanings when we discuss "the root of a lock":  
> this could refer to the resource that was directly locked, or to the URL 
> that was addressed in the LOCK request.  There are cases where RFC4918 
> definitely uses this phrase to mean resource: "The resource identified 
> in the Request-URI becomes the root of the lock.".  
> (<http://tools.ietf.org/html/rfc4918#section-7.4>)

Actually, that sentence is in Section 9.10.1 
(<http://tools.ietf.org/html/rfc4918#section-9.10.1>). It's the sentence 
I think RFC 4918 got wrong, and which both the RFC 4918 erratum and the 
appendix in BIND try to clarify.

> The appendix to BIND "clarifies" this by contradicting it, and saying 
> that the lock root is actually the URI.  (Certainly I agree the value of 

Yes.

> the 'lock-root' element is the URI so at least that's not 
> controversial.)  This "clarification" is justified by needing to explain 

No. The clarification is needed because a specification term can't 
identify a URI and a resource at the same time.

It seems you're saying that this inconsistency somehow was deliberate 
and serves a purpose. If so, which?

> that the lock does not cover the URIs that are bindings to the resource, 
> other than the URI that was LOCKed.    I don't think there is a need to 
> change the words of 4918 or clarify them; the behavior of bindings can 
> be specified in BIND without that.

BIND does not *need* to explain the locking model, because the RFC 4918 
locking model is the same (with 9.10.1 being the exception).

> With bindings functionality as Julian explains it in email, you can send 
> an UNLOCK request to any binding of a locked resource, even though some 
> of those bindings aren't covered by the lock....

Yes. UNLOCK operates on a resource, and it doesn't matter which URI you 
use in order to access it.

> ...  You can also change a 
> binding that's not covered by the lock, so if you lock a resource 
> through a binding in your collection, I can change the name of the 
> binding to the same resource in my collection or remove it...

If that namespace operation does not change the root of the lock (see 
RFC 4918, Section 7). Otherwise the request need to include the lock 
token (using the "If" header).

> ...  This 
> behavior makes at least as much sense as any other, but it should be 
> explained explicitly.  I don't think it falls out of the model trivially 
> the same way for everybody reading the BIND document. 

I think it's the only one that makes sense, and it happens to be the one 
defined by RFC 4918.

> Sometimes with messy, deployed protocols and extensions, it's hard to 
> define a model such that all the behavior simply can be deduced from the 
> model.  Sometimes you have to actually say "it works this way" although 
> it also helps to have the model.
> 
> To be clear, since BIND is an experimental document, I think this 
> appendix is pretty harmless to everything except possibly the 
> interoperability of bindings implementations, so I'm not blocking the 
> document or doing anything other than explain my lack of complete agreement.
> ...

Lisa, at this point I'd like to get feedback on two questions:

1) Do you maintain the point of view that the language in 9.10.1 of RFC 
4918 ("The resource identified in the Request-URI becomes the root of 
the lock.") is correct? If so, could you elaborate how it can be parsed 
given the fact that the remainder of the spec takes as the "root of the 
lock" being a URI, not a resource? (Essentially this is about confirming 
the open erratum for RFC 4918).

2) Independently of that, do you think that draft-ietf-webdav-bind-25 is 
ready and can be published? I *could* add an example explaining locking 
to Appendix A, but I'd really like to understand whether that change 
would be sufficient (from your perspective as appsarea AD).

BR, Julian

Received on Sunday, 30 August 2009 18:56:31 UTC