RE: WebDAV Bindings - Issue Yaron.BindingsProperty

This seems right to me.  It also points out that till now we've been
thinking that capabilities vary by resource, so that responses to OPTIONS
vary by resource.  When we consider situations where there are multiple
bindings to the same resource, it turns out that capabilities really vary by
URI, and responses to OPTIONS with different request-URI but the same
resource may be different.
 
So we need also to take another look at the wording of section 15 Capability
Discovery, as well as 9 (which you discuss in another note).
 
--Judy 
 

-----Original Message-----
From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
Sent: Sunday, January 16, 2000 8:27 PM
To: w3c-dist-auth@w3.org
Subject: WebDAV Bindings - Issue Yaron.BindingsProperty



Section 11 of the BIND specification defines the dav:bindings property. What
is not clear to me from the text in this section is if it is possible to
have the dav:bindings property accessible through one binding but not
another? 

One could imagine that two servers share access to the same disk drive and
hence are able to map names to the same "resource" (as they understand the
term). In order to keep things consistent both servers agree to record all
the names they use to refer to the same resource. However only one of the
servers actually supports the BIND method and the dav:bindings property and
the other doesn't. I can still do a GET on each server and the result will
be from the same resource but only one of the servers will be able to serve
up the dav:bindings property. Unfortunately the language in section 11
speaks of the dav:bindings property being on a resource so the presumption
is that if I can get the dav:bindings property through one binding then I
MUST be able to get it through the other. I believe this is too strict a
requirement.

As such I move that the language in section 11 be clarified so as to specify
that the dav:bindings property may not necessarily be available through all
bindings on the resource.

Received on Tuesday, 18 January 2000 09:28:07 UTC