Re: Issues remaining with Bind draft

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 Wednesday, 24 March 2004 14:57:10 UTC