Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings

On Dec 6, 2004, at 2:20 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>>> If it doesn't matter, why does RFC2518 say:
>>>
>>> "Although implicit in [RFC2068] and [RFC2396], any resource,  
>>> including collection resources, MAY be identified by more than one  
>>> URI. For example, a resource could be identified by multiple HTTP  
>>> URLs."
>>>
>>> (<http://greenbytes.de/tech/webdav/ 
>>> rfc2518.html#rfc.section.5.1.p.4>) and
>>>
>>> "A resource may be made available through more than one URI. However  
>>> locks apply to resources, not URIs. Therefore a LOCK request on a  
>>> resource MUST NOT succeed if can not be honored by all the URIs  
>>> through which the resource is addressable."
>>>
>> In this case it *does* matter to clients because it is detectable --  
>> the behavior has concrete results, even if the client can't detect  
>> that there are multiple bindings.  If a client is trying to allow the  
>> user to
>
> It's always detectable. For instance, if I submit a depth:0 LOCK  
> request to "/a", and a subsequent PROPFIND on the DAV:lockdiscovery  
> property of "/b" shows that it is locked by the same lock I just  
> created on "/a", I can conclude that both are the same resource.
>
> BIND makes it *easier* to detect sameness, but it doesn't introduce  
> any new concept.
>
Clever... so an observant client could detect that the same lock  
existed on two URLs so conclude they are bindings to the same resource  
(unless the server calculates the value for lockdiscovery on the fly  
and does something unlikely and weird with lock tokens).

I still think that the bindings draft makes it far more likely that a  
client will try to detect whether two bindings are the same resource  
and behave differently if they are.  For example, a client that is  
bindings-aware could try to speed up synchronization by using  
'DAV:resource-id' and synchronizing only once per resource, rather than  
once per binding.  The client could cache the 'DAV:acl' property (or  
any other live property) for offline use.  If the client knows that all  
bindings will have the same value for 'DAV:acl' then it only needs to  
request that property once per resource.  OTOH if the client knows that  
different bindings may have different values for 'DAV:acl' (or another  
live property) then the client must ask once for each binding.

I also worry that it's not enough for us to say that dead properties  
MUST be the same value no matter which binding is addressed but live  
properties MAY vary.  We don't have a reliable way for the client to  
tell which properties are dead and which are live.  Still, I could live  
with that.

Lisa

Received on Monday, 6 December 2004 23:25:27 UTC