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

From: Lisa Dusseault <[email-masked]>
Date: Thu, 27 Jan 2005 16:06:58 -0800

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?

The title of the bug is general ("Bindings needs to completely describe 
how bindings interact with locks.") because when I entered it, I could 
see some undefined interactions and suspected there might be more.  At 
this point, I am not aware of any more undefined interactions, so if we 
satisfy the interaction between LOCK/UNLOCK and multiple bindings, I 
suggest we close the bug.  We can also make the bug title more specific 
so that if somebody comes up with a new undefined interaction between 
locking and bindings we'd encourage them to open a new bug.

Lisa

Begin forwarded message:

> From: [email-masked]
> Date: January 18, 2005 11:35:08 PM PST
> To: [email-masked]
> Subject: [Bug 2] Bindings needs to completely describe how bindings 
> interact with locks.
>
> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2
>
>
>
>
>
> ------- Additional Comments From [email-masked]  
> 2005-01-18 23:35 -------
> Suggested additional text bei Joe Hildebrand, Chuck Fay and Julian 
> Reschke:
>
> 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 particular binding expressed by the Request-URI, rather than the
> resource identified by that 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.
>
>
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Jan 2005 09:58:32 +0100

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

> ...

Best regards, Julian

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

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 28 Jan 2005 09:46:26 -0800

On Jan 28, 2005, at 12:58 AM, Julian Reschke wrote:

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

There are only three bugs open on Bind in bugzilla:
  - http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=2 -- 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")
  - http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=71-- 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")
  - http://ietf.webdav.org:8080/bugzilla/show_bug.cgi?id=5 -- 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.

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

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.

Lisa

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Jan 2005 19:15:42 +0100

Lisa Dusseault wrote:
> 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.

> raised in an email sent Nov 18 2003 ("Bindings and GULP again") and also 

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

> locks, other live properties")

It would be helpful if you could look at the answer that was entered 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=71#c1>) 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.

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

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")
> 
> resource): raised March 17 2004 ("Issues remaining with the Bind draft")

Answered in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0097.html> 
(follows from RFC2518's definition of DAV:getlastmodified).

> raised  March 17 2004 ("Issues remaining with the Bind draft")

Same.

> binding onto another binding of same resource")

This was answered in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0143.html>, 
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.

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

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 28 Jan 2005 10:46:37 -0800

> completely describe how bindings interact with locks". Stating  
> concrete cases where the interactions indeed aren't defined would be  
> much more helpful.

We've narrowed this down to a pretty small list of actual concrete  
cases, some of which are already dealt with:
  - we described how servers MUST allow UNLOCK on any binding
  - I *think* the interactions with lockdiscovery are OK now but I worry  
about whether clients will see unexpected URLs in that property
  - remaining is only to define how servers MUST handle lock refresh  
requests. -->  I'll add this to the bug.

> should be closed. If you disagree, please follow up on my answer.
Done, thanks.

>> however I suggest we resolve this by explicitly saying in Bind that  
>> the interactions with DeltaV remain undefined.
>
Ok, so how about some wordsmithing to fix that? "Many of the  
interactions between Bind and DeltaV are defined by the requirements in  
both specifications.  However, in cases where the interactions remain  
ambiguous or open to different implementations, this spec does not  
address how servers must implement the features."

>> investigation I see it was originally raised March 22 2004 ("Re:  
>> Issues remaining with the Bind draft")
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/ 
> 0097.html> (follows from RFC2518's definition of DAV:getlastmodified).

That's great, I have no problems with this answer.  Now it needs to be  
put in the specification.

>> raised  March 17 2004 ("Issues remaining with the Bind draft")

I don't think this really answers the question.  The answer in that  
email is "Same as MOVE (which means: usually not)."

Even if the answer is that a server MAY change the getlastmodified or  
getetag property on a REBIND (I think MUST is more appropriate, BTW)  
the answer still needs to go in the spec.

> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/ 
> 0143.html>, 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.

You're right, I failed to follow up on that one.

The assumption that was underlying that problem was that you couldn't  
MOVE a binding of a resource to overwrite a binding of the same  
resource even with Overwrite: T.    I suspect that some servers could  
easily forbid that on its own merits, so to speak, and a client that  
expected that to work would be surprised by the failure.  Same thing  
with COPY -- you say it can work, so the spec should say that rather  
than let server implementors decide to forbid it.

So how about "COPY and MOVE methods, when used with the "Overwrite: T"  
header,  overwrite the destination as described in RFC2518.  This  
behavior SHOULD NOT be different even if the source binding and the  
destination binding are actually bindings to the same resource."

>
>> Far from being infinite, no substantively new issues have been added  
>> to this list since March of 2004.   Adding text to resolve all these  

Well I forgot a couple things :)

> about what the spec should say, and then the WG can decide whether  
> these statements are actually correct and belong into the spec.

I have done so.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Jan 2005 20:15:44 +0100

Lisa Dusseault wrote:
> ..-

As I already said *multiple* times, there are no URLs in that property 
(except for the lock token URI).

> requests. -->  I'll add this to the bug.

I disagree that this needs to be undefined. BIND says:

"A BIND request does not create a new resource, but simply makes 
available a new URI for submitting requests to an existing resource. The 
new URI is indistinguishable from any other URI when submitting a 
request to a resource. Only one round trip is needed to submit a request 
to the intended target. Servers are required to enforce the integrity of 
the relationships between the new URIs and the resources associated with 
them. Consequently, it may be very costly for servers to support BIND 
requests that cross server boundaries."

(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.1.p.6>)

So we would only need to say something if this would be a case where 
this rule does not apply.

> address how servers must implement the features."

I personally think that this is the same as saying nothing, except for a 
more complex spec to maintain/read/understand and possible confusion by 
the reader ("what exactly is this trying to tell me?").

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

No, it doesn't. It's already in RFC2518.

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

REBIND is like MOVE. RFC2518 doesn't make any requirement about MOVE, so 
why should BIND make any? Any why would getlastmodified need to change? 
It certainly doesn't in a file system, for instance.

> than let server implementors decide to forbid it.

I don't understand. Moving "a" to "a" is a nop. Even if a server does 
reject that request, the state of the resource and it's bindings will be 
the same.

If you feel this needs clarification, add it to the RFC2518 issues list.

> destination binding are actually bindings to the same resource."

Why would anybody think it is different? I still don't see a problem 
here that would require additional spec text.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 28 Jan 2005 11:38:03 -0800

On Jan 28, 2005, at 11:15 AM, Julian Reschke wrote:

>>  - I *think* the interactions with lockdiscovery are OK now but I  
>> worry  about whether clients will see unexpected URLs in that  
>> property
>

Sorry I didn't give enough detail there; the "lockroot" goes in there  
in RFC2518bis, but of course we can clarify that in RFC2518bis.  That's  
why I think that the value of 'lockdiscovery' may be clear enough.

> available a new URI for submitting requests to an existing resource.  
> The new URI is indistinguishable from any other URI when submitting a  
> request to a resource. Only one round trip is needed to submit a  
> request to the intended target. Servers are required to enforce the  
> integrity of the relationships between the new URIs and the resources  
> associated with them. Consequently, it may be very costly for servers  
> to support BIND requests that cross server boundaries."
>

Actually, I think that language is misleading.  Naturally, the new URI  
is distinguishable from any other URI when submitting certain requests,  
the most obvious of which is UNBIND.

>> interactions between Bind and DeltaV are defined by the requirements  
>> in  both specifications.  However, in cases where the interactions  
>> remain  ambiguous or open to different implementations, this spec  
>> does not  address how servers must implement the features."
>
> I personally think that this is the same as saying nothing, except for  
> a more complex spec to maintain/read/understand and possible confusion  
> by the reader ("what exactly is this trying to tell me?").

All right, how about "The interactions between Bind and DeltaV are  
largely defined by the requirements in each specification.  However,  
further clarifications are out of the scope of this document."

Is that simple enough?

>>>> or  resource): raised March 17 2004 ("Issues remaining with the  
>>>> Bind  draft")
>>>
>>>
>>> Answered in   
>> That's great, I have no problems with this answer.  Now it needs to  
>> be  put in the specification.
>

Great.  Then we just need to say that:
"A BIND request MUST NOT change the value of the getlastmodified  
property of a resource"

--> Repeat requirement for UNBIND and REBIND  or phrase in one sentence  
depending on how you want to organize the spec.

> REBIND is like MOVE. RFC2518 doesn't make any requirement about MOVE,  
> so why should BIND make any? Any why would getlastmodified need to  
> change? It certainly doesn't in a file system, for instance.

I don't consider the answer that "RFC2518 is incomplete" to be a good  
argument for leaving Bind incomplete.  We can also raise an issue for  
RFC2518bis.

As to why getlastmodified might change, well it depends what the server  
implementor considers to be the state of the resource.

> reject that request, the state of the resource and it's bindings will  
> be the same.
>

This is something that servers might treat differently in the presence  
of bind-like features, which is why I suggest it for Bind.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Jan 2005 21:08:38 +0100

Lisa Dusseault wrote:
>>> worry  about whether clients will see unexpected URLs in that  property
>>
>>
>> As I already said *multiple* times, there are no URLs in that 
>> property  (except for the lock token URI).
> 
> 

Well, thanks for agreeing that BIND doesn't need to clarify something 
that doesn't exist yet (as it is only part of RFC2518bis).

> the most obvious of which is UNBIND.

Not at all, check the definition for UNBIND 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#METHOD_UNBIND>):

"The UNBIND method modifies the collection identified by the 
Request-URI, by removing the binding identified by the segment specified 
in the UNBIND body."

> further clarifications are out of the scope of this document."

I don't think this is helpful, but if you can get a rough consensus for 
that change, we can do it.

> "A BIND request MUST NOT change the value of the getlastmodified  

RFC2518 doesn't say that, nor should BIND. In particular, WebDAV 
implementations that derive ETags from the lastmod filestamp in the 
filesystem usually must touch the file in order to ensure proper ETag 
semantics.

> argument for leaving Bind incomplete.  We can also raise an issue for  

I didn't say RFC2518 is "incomplete". It just doesn't make any 
requirement, and as far as I can tell, it shouldn't.

>>>> 0143.html>, 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.
>>>
>>> The assumption that was underlying that problem was that you 
>>> couldn't   MOVE a binding of a resource to overwrite a binding of the 
>>> same   resource even with Overwrite: T.    I suspect that some 
>>> servers could   easily forbid that on its own merits, so to speak, 
>>> and a client that   expected that to work would be surprised by the 
>>> failure.  Same thing   with COPY -- you say it can work, so the spec 
>>> should say that rather   than let server implementors decide to 
>>> forbid it.
>>
>>

What does the presence of "bind-like" features have to do with that? 
Please explain.

Best regards, Julian