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

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

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

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

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

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

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

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

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.

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

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

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

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


Best regards, Julian

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

Received on Friday, 28 January 2005 20:09:13 UTC