Re: Issues remaining with Bind draft

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)
  - 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.  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.  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 11:53:33 UTC