Re: Issues remaining with Bind draft

At 8:48 AM -0800 03/24/2004, Lisa Dusseault wrote:
>I suggest adding the following text to the Bind draft:
>
>"Methods that create a new resource (MKCOL, MKWORKSPACE, MKACTIVITY, 
>PUT when the destination is unbound) each create only one binding 
>and one resource.  Methods that create a new binding (BIND) leave 
>other bindings unaffected.
>
>"The following methods MUST have an identical result on every 
>binding to a resource, regardless of which binding is addressed:
>  - GET, PUT (to an existing binding), OPTIONS, HEAD.
>  - PROPPATCH, LOCK, UNLOCK
>  - all the methods defined in RFC3253 (except the ones that create a 
>new resource)

It strikes me that just listing them out from RFC 3253 would be useful here,
even if redundant, as it would eliminate any confusion on exactly which ones
are meant.

>  - ORDERPATCH
>  - ACL
>
>"The following methods have a result that only affects the binding 
>that is addressed, and don't affect other bindings to the same 
>resource: REBIND, UNBIND.

For the custom live properties, could PROPPATCH have an effect that 
affects only
the binding address (as noted below, implementations MAY define custom live
properties which have different values on different bindings)?


>MOVE, COPY and DELETE have special behavior described in detail in 
>sections 2.3 to 2.5.
>
>"The REPORT and PROPFIND methods could conceivably provide different 
>information depending on which binding to a resource is addressed 
>but by default they return the same information regardless of 
>binding.  The definition of each property or report ought to make 
>clear if this property or report diverges from the default.

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?


>  All reports defined in RFC3253 and the ACL RFC return the same 
>result for any binding to the same resource.  All (live) properties 
>defined in RFC2518, RFC3253, RFC3648 and the ACL RFC MUST have the 
>same value appearing on all bindings to the same resource. All dead 
>properties MUST appear the same on all bindings to the same 
>resource. An implementation MAY define custom live properties which 
>have different values on different bindings to the same resource."
>
>---
>
>This text is intended to supplement the model description by making 
>requirements on implementations to encourage them to behave 
>consistently, and to clear up confusion in applying the model in 
>specific cases.
>
>Lisa
>
>
>On Mar 22, 2004, at 12:25 PM, Julian Reschke wrote:
>
>>Lisa Dusseault wrote:
>>
>>>This is definitely an improvement.  However, I still  have some 
>>>issues -- the interaction between bindings and locks is still 
>>>unclear.  The spec needs to clearly say that
>>>  - if one binding is locked, then every binding is locked (with 
>>>the same lock token)
>>
>>No, the bindings aren't locked, the *resource* is (RFC2518).
>>
>>>  - All bindings to the same resource MUST support the same 
>>>features (e.g. locking)
>>
>>The bindings themselves do not support anything; the resource they 
>>are mapped to do. As they are mapped to the same resource, the same 
>>features are available.
>>
>>>  - All bindings to the same resource MUST show the same values for 
>>>live properties defined in RFC2518, RFC3253, RFC3648 and the ACL 
>>>RFC.
>>
>>Same. You're communicating with the resource, not particular bindings.
>>
>>>Unless my understanding of the intent is wrong...?  In which case, 
>>>it needs to clarify some other way.
>>
>>I'd say all of this follows from section 1, paragraphs 4 
>>(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-04.html#rfc.section.1.p.4>) 
>>to 6:
>>
>>"The BIND method defined here provides a mechanism for allowing 
>>clients to create alternative access paths to existing WebDAV 
>>resources. HTTP [RFC2616] and WebDAV [RFC2518]  methods are able to 
>>work because there are mappings between URIs and resources. A 
>>method is addressed to a URI, and the server follows the mapping 
>>from that URI to a resource, applying the method to that resource. 
>>Multiple URIs may be mapped to the same resource, but until now 
>>there has been no way for clients to create additional URIs mapped 
>>to existing resources.
>>
>>BIND lets clients associate a new URI with an existing WebDAV 
>>resource, and this URI can then be used to submit requests to the 
>>resource. Since URIs of WebDAV resources are hierarchical, and 
>>correspond to a hierarchy of collections in resource space, the 
>>BIND method also has the effect of adding the resource to a 
>>collection. As new URIs are associated with the resource, it 
>>appears in additional collections.
>>
>>A BIND request does not create a new resource, but simply makes 
>>available a new URI for submitting requests to an existing 
>>resource. The new URI is indistinguishable from any other URI when 
>>submitting a request to a resource. Only one round trip is needed 
>>to submit a request to the intended target. Servers are required to 
>>enforce the integrity of the relationships between the new URIs and 
>>the resources associated with them. Consequently, it may be very 
>>costly for servers to support BIND requests that cross server 
>>boundaries."
>>
>>At this point I really don't know how to improve that description 
>>(except by adding "we mean it -- it's really just another name 
>>mapped to the same resource" :-). If you think that this 
>>introduction needs to be improved, please make a concrete proposal.
>>
>>Does anybody else feel that this is unclear?
>>
>>
>>Regards. Julian
>>
>>--
>><green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 24 March 2004 12:41:56 UTC