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

Lisa Dusseault wrote:
> On Jan 28, 2005, at 12:58 AM, Julian Reschke wrote:
>> Lisa Dusseault wrote:
>>> By the way, I agree with this wording. I would be even happier if it 
>>> also required the server to allow LOCK on any binding to refresh the 
>>> lock already existing. Can we add that?
>> In theory, we *can* state everything that is correct. In practice, the 
>> set of additional statements we can make is infinite, so it would be 
>> nice if you could describe why anyone would come to the impression 
>> that LOCK refresh is in any way different than other methods.
> I really don't see where you're getting the "in practice the set is 
> infinite" conclusion.  In theory it's infinite, but in practice it's 
> finite.  All the issues that I currently consider unresolved were raised 
> over six months ago.

I'll disagree, but that's not relevant here. Last Call is to get people 
reviewing the spec, so if people do that it's in general A Good Thing.

> There are only three bugs open on Bind in bugzilla:
>  - -- this was 
> raised in an email sent Nov 18 2003 ("Bindings and GULP again") and also 
> raised March 17 2004 ("Issues remaining with the Bind draft")

The problem here is the vague requirement to be "Bindings needs to 
completely describe how bindings interact with locks". Stating concrete 
cases where the interactions indeed aren't defined would be much more 

>  - this was 
> raised Nov 30 2004 ("Bindings and Permissions") but it's only an 
> elaboration of an issue raised March 18 2004 ("Should REBIND preserve 
> locks, other live properties")

It would be helpful if you could look at the answer that was entered 
(<>) and 
comment on that. As far as I can tell, this is not a BIND issue so it 
should be closed. If you disagree, please follow up on my answer.

>  - -- this was 
> raised March 17 2004 ("Issues remaining with the Bind draft") -- however 
> I suggest we resolve this by explicitly saying in Bind that the 
> interactions with DeltaV remain undefined.

No, they aren't "undefined". There are some scenarios where the specs 
(intentionally) do not require any specific server behaviour, but that 
doesn't mean that the topic in general is undefined.

> We're also currently discussing an issue recently re-raised by Brian, on 
> how ETags might behave with multiple bindings, but on some investigation 
> I see it was originally raised March 22 2004 ("Re: Issues remaining with 
> the Bind draft")
> Now that I review the email history here I see only three more issues 
> that I think are still unresolved:
>  - What event does creationdate refer to (creation of binding A, B or 
> resource): raised March 17 2004 ("Issues remaining with the Bind draft")

Answered in 
(follows from RFC2518's definition of DAV:getlastmodified).

>  - Does REBIND change the getlastmodified or getetag property values: 
> raised  March 17 2004 ("Issues remaining with the Bind draft")


>  - How does copying bindings work: raised March 24 2004 ("COPY of a 
> binding onto another binding of same resource")

This was answered in 
and as far as I can tell, you never followed up on that reply. Please 
understand that unless somebody who asks a question follows up on the 
answer, we obviously assume that the question was answered and that 
there is no open issue.

> Far from being infinite, no substantively new issues have been added to 
> this list since March of 2004.   Adding text to resolve all these issues 
> could take as much as a page added to the Bind spec and then we'd be 
> done (as far as I'm concerned) and we'd have a good spec.

Well, last time you said half a page would be enough :-)

Anyway, I'll suugest again that you actually make concrete proposals 
about what the spec should say, and then the WG can decide whether these 
statements are actually correct and belong into the spec.

> Lisa
> (BTW I'll open new bugs to track the three issues I listed last -- 
> unless I've overlooked some resolution, of course )

Best regards, Julian

<green/>bytes GmbH -- -- tel:+492512807760

Received on Friday, 28 January 2005 18:16:16 UTC