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

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

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

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

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

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

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

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

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

> ...

Best regards, Julian

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

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