- From: Yaron Goland <yarong@Exchange.Microsoft.com>
- Date: Tue, 18 Jan 2000 08:02:16 -0800
- To: "'Slein, Judith A'" <JSlein@crt.xerox.com>, w3c-dist-auth@w3.org
I suspect the issue is better described as "Can a user rely on getting back a complete list of all the bindings they are allowed to see when they ask for a dav:bindings property?" I suspect Judy's answer will be "yes". Which is certainly reasonable. If so, then we need to clarify the language in the spec to make this clear. This is definitely a conclusion one can come to from reading the spec but it would be useful if the conclusion was explicitly addressed. Language such as "A client can rely upon the contents of the DAV:bindings property specifying all bindings for that resource that the client is authorized to know about." That having been said, it is also fairly clear that a design for weak bindings will most likely want to use the DAV:bindings property. The reason being that if one is performing a search one will almost certainly want to search on both weak and strong bindings. If one wants one over the other, one can always select the search based on resource type as weak bindings will almost certainly have their own resource type. Strong bindings obviously don't require their own resource type as, by definition, every WebDAV resource (to some extent or another) is a strong binding. As such I would like to see the DAV:bindings definition language tweaked to say something along the lines of "DAV:bindings, when used with bindings as defined in this specification,...." By putting in the parenthetical phrase the weak bindings spec will be able to say "DAV:bindings, when used with weak bindings, provides a list of available bindings. This list may not necessarily be complete." Yaron > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Tue, January 18, 2000 7:36 AM > To: 'Yaron Goland'; w3c-dist-auth@w3.org > Subject: RE: WebDAV Bindings - Issue Yaron.ApplePie3 > > > Comments in <js> </js> below. > > -----Original Message----- > From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com] > Sent: Sunday, January 16, 2000 8:26 PM > To: w3c-dist-auth@w3.org > Subject: WebDAV Bindings - Issue Yaron.ApplePie3 > > > > Section 11 of the BIND spec states: "A PROPFIND requesting > DAV:bindings MUST > return only those bindings that the client is authorized to see." > > This brings up a couple of questions. The first question is > "How do I ever > know if I have the definitive list of bindings?" I suspect > the answer is > "you don't" since there may be bindings you aren't authorized to see. > > <js> Right. </js> > > This then brings us to another sentence in section 11 which > reads "If the > DAV:bindings property exists on a given resource, it MUST > contain a complete > list of all bindings to that resource." > > However this means that the dav:bindings property must always return a > complete list of bindings which the sentence following it > (given at the > start of this letter) contradicts. > > <js> I don't see this as contradictory. The value of the > property on the > resource is the complete list of bindings. What gets > returned in response > to any particular PROPFIND request is some subset of that > value. </js> > > One should never have two MUST level requirements that are in direct > contradiction. The reason for the contradiction is that we > have raised the > bar too high on the contents of the dav:bindings property > value. We have > already specified that due to security concerns it is > absolutely impossible > for you to ever be sure that you necessarily have the complete list of > bindings. Therefore requiring that the complete list be > returned, even as > the default in the absence of security concerns, is self defeating. > > Therefore I move that the language in section 11 be changed > to read that the > dav:bindings property may contain zero or more of the > bindings available on > a resource rather than the definitive set since it is impossible to > meaningfully require that the definitive set be returned. >
Received on Tuesday, 18 January 2000 11:03:16 UTC