W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2004

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 07 Dec 2004 11:50:53 +0100
Message-ID: <41B58B0D.1090603@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: Webdav WG <w3c-dist-auth@w3c.org>

Lisa Dusseault wrote:

> On Dec 6, 2004, at 2:20 PM, Julian Reschke wrote:
> ...
> 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).

If a server does something "unlikely and weird" that causes this not to 
work, then it's broken. There's no reason to believe that a server that 
get's DAV:lockdiscovery wrong will get DAV:resource-id right, so why 
would I worry about that?

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

Which is exactly the reason why RFC3744 says that DAV:acl will be the 
same no matter what binding you use.

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

Well, as you just pointed out, the difference between dead and live 
properties is fuzzy. Also, the statement as proposed, sort of 
*encourages* implementers to have live properties varying by binding. 
IMHO, they shouldn't (as properties are part of the state of the 
resource or computed based on the state of a resource), and thus should 
not vary at all. My impression from earlier discussion was that you 
don't buy that point of view, so I haven't tried hard to get it into the 
spec. Should I now?

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 7 December 2004 10:51:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:17:51 UTC