Re: Issues remaining with Bind draft

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 Monday, 22 March 2004 15:27:28 UTC