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: Fri, 10 Dec 2004 21:49:37 +0100
Message-ID: <41BA0BE1.4010805@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: ejw@cs.ucsc.edu, 'webdav' <w3c-dist-auth@w3.org>

Lisa Dusseault wrote:
>>> This kind of thing could be useful for other applications as well.  
>>> It could even work with PROPPATCH, because the server knows to treat 
>>> this as a "per-binding" property and change only the value that 
>>> applies for this binding.
>> So where do you store it? Either on the resource itself (in which case 
>> you need to maintain that property for each parent collection, so you 
>> could simply expose that information as well), or on the collection.
> WebDAV servers *store* things any way they like.  E.g. a new table in 
> the backend database called "PER_BINDING_PROPS" with column headers for 
> binding, property name and value. Who cares how they store it -- that's 
> what gives the implementors flexibility.  WebDAV's model and marshalling 
> are what we're talking about.

Yes, and WebDAV's (that is, HTTP's) model involves resources and URIs. 
URIs are used to address resources, and content and properties represent 
the state of the *resource*, no the URI.

If you want things to vary based on the binding, store them with the 
binding, and in WebDAV's model, that's part of the state of the parent 
collection. It's ok to do this, but if you do things will stay much 
simpler if you work with that model.

For instance, is PROPPATCHing "the next picture" modifying the state of 
the picture, or that of the slide show? If it's part of the picture, 
I'll need write permissions to the picture resource, right? Why would I 
need that if the only thing I do is changing the ordering in a container 
object (the slide show)?

>> BTW: you seem to be changing positions frequently :-) May I remind you 
>> that you asked that the BIND spec mandates that properties MUST NOT 
>> vary across bindings?
> As it happens, I am not changing positions on this issue (although I 
> reserve my right to change my mind if I'm convinced by an argument or 
> think of new cases).  I have held this position for a year or more now 
> and will try to state it again another way:
> That servers should be allowed to vary properties per binding and IF 
> that's the consensus...
>     then the specification should warn clients that "clients MUST be 
> prepared for properties that vary per binding"
> ELSE IF the consensus (despite my opinion) is that properties can't vary 
> per binding
>     then the specification should say that properties MUST NOT vary 
> across bindings.

As far as I can tell, there is no consensus for either of these. RFC2518 
says that properties "describe the state of a resource". People seem to 
come to different conclusions about what this means, but if this is the 
case, it should be fixed in RFC2518, not in BIND.

Best regards, Julian

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Friday, 10 December 2004 20:50:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:31 UTC