Properties of bindings (was Re: Issues remaining with Bind draft)

I found a reference to the "parentname" property, defined for Exchange  
2000 and Exchange 2003 in the "DAV:" namespace (no big surprise there  
though it's unfortunate):

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/ 
wss/_cdo_schema_dav.asp

The "hidden" flag you suggest would also be interesting as a binding  
property, as was suggested in this Internet-Draft (also implemented in  
Microsoft servers):

http://www.ics.uci.edu/~ejw/authoring/props/draft-hopmann-collection- 
props-00.txt

As you say, it could also be implemented on the parent collection as a  
list of hidden bindings within the collection, but the cat's out of the  
bag there for at least some implementations.  I don't see the harm in  
allowing some custom live properties to vary on bindings. Any  
implementation that didn't have the ability to calculate a live  
property based on a binding wouldn't have to do so.

Lisa

On Mar 24, 2004, at 11:49 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>>> Nope, and I absolutely disagree that live properties may vary  
>>> depending on access path.
>> I believe servers have already been implemented and deployed where  
>> the live property can vary depending on access path.  For example, in  
>> order to continue to maintain backward compatibility for a custom  
>> property called "parent-path", the server would have to implement  
>> bindings in such a way that "parent-path" was calculated from the  
>> request address.
>
> ...or it could make the decision not to maintain support for something  
> that doesn't fit into the BIND model.
>
> What's the use case for that property?
>
>>>> I'm trying to work through the implications of this, and having a  
>>>> bit of trouble.
>>>> Does this imply that a method generating this must be applied both  
>>>> to the
>>>> binding against which it was targeted and against some other  
>>>> binding to test
>>>> this?  or does it imply some mechanism of indicating that a  
>>>> property is
>>>> capable fo divergence?  In the second case, how is that  
>>>> discovered/stored?
>>>
>>>
>>> There must not be any divergence.
>> I should have been more clear in my original text.  What I meant was  
>> that when a new live property is specified (e.g. in an Internet-Draft  
>> / RFC), the specification should indicate if the live property may  
>> have different values on different bindings.  Otherwise, the  
>> assumption is
>
> No, it must not have different values based on the access path.
>
>> that the live property must have the same value on all bindings.
>
> Precisely.
>
>> Similarly, when a new report is specified, readers may assume that it  
>> behaves the same on all bindings, unless the specification says  
>> otherwise.
>
> Yes, they should assume it behaves the same on all bindings. The  
> REPORT method is defined to return information for the resource  
> referenced by the request URI. The request URI really is just the  
> access path and has no influence on the result.
>
>> I never envisioned a need or utility in having clients apply methods  
>> to multiple bindings to test this.  I did envision a mechanism to  
>> indicate that a property may diverge on different bindings, but I  
>> propose this should be in the specification where the property is  
>> defined.  So there are no issues for discovery/storage.
>
> Again, I think the concept of properties that vary on access path is  
> incompatible with what we are doing here. In the model we're working  
> in,  state only exists in WebDAV resources (where bindings belong to  
> the state of the containing collection).
>
> So if you have a property that is supposed to vary, it *per  
> definition* can't belong to the resource itself, thus it'll be part of  
> the parent collection's state (an example would be a "hidden" flag  
> that's attached to each of the bindings contained in the collection).
>
> I agree that in many cases the strong model used in BIND doesn't work  
> well in all practical use cases (there's a reason why Unix symbolic  
> links seem to be more popular then hard links). That's why the  
> Advanced Collection activity of this working group has resulted in  
> *several* specs. For instance, REDIRECTREF resources  
> (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref- 
> protocol-latest.html>) *are* separate resources that can have their  
> own metadata attached to it.  There was yet another planned thingy  
> called "direct reference" (as far as I understand similar to  
> redirectrefs minus the redirection step) that seems to more closely  
> map to what you feel bindings should be doing. Maybe you want to  
> pursue that project?
>
> Regards, Julian
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Thursday, 25 March 2004 17:48:15 UTC