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

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

> Lisa Dusseault wrote:
>> ..-
>> 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
>
> As I already said *multiple* times, there are no URLs in that property  
> (except for the lock token URI).

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.

>
>>  - remaining is only to define how servers MUST handle lock refresh   
>> 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.

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.

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

>
>>>> 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.
>
> No, it doesn't. It's already in RFC2518.

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.


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

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

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

Lisa

Received on Friday, 28 January 2005 19:38:17 UTC