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

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

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.

>
>>  - 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")
>
> 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.
Done, thanks.

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


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

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

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.

>
>>  - How does copying bindings work: raised March 24 2004 ("COPY of a  
>> 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.

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

Well I forgot a couple things :)

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

I have done so.

Lisa

Received on Friday, 28 January 2005 18:47:04 UTC