- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Thu, 22 Nov 2001 10:38:14 +0100
- To: "Daniel Brotsky" <dbrotsky@adobe.com>
- Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Daniel Brotsky > Sent: Thursday, November 22, 2001 1:29 AM > > At 8:11 AM -0500 11/21/01, Clemm, Geoff wrote: > >I believe that when we revise 2518, that that the > >new DAV:allprop behavior should be defined to be > >"all live properties defined in RFC 2518 plus all > >dead properties". > > This works fine for me if we allow for server "discretion" by saying > "at least all live properties defined in RFC 2518 plus all dead > properties." Servers that *want* to show live properties should not > be prohibited from doing so. > > My motivation for this (other than common sense :^) is that I believe > many generic clients use ALLPROP as a way of saying "show me > everything I'm likely to care about." Some servers will have a > number of general-interest properties that are live and useful in > such a list; for example, workflow servers often have live properties > indicating status, assignee, and those kinds of things. It would be > awkward if 2518++ prohibited them from showing these in response to > an ALLPROP. I follow your motivation but not your conclusion. Let's stick to the workflow properties (workprops) example: A generic client will survive workprops returned from an allprop, sure. But will it be able to do anything with it? Most likely not. A workflow client will need the workprops returned from the server. Now there are four possible cases: 1) the client does not use <allprop> but <prop>...list...</prop> 2) the client uses <allprop> and the server returns the workprops with allprop, even though they are live properties. 3) the client uses <allprop> and the server does not return the workprops, because the server does not know these properties. 4) the client uses <allprop> and the server does not return the workprops. The server implements the workprops, but it does not return those on allprop. 1) does not need your allprop "at least" extension, 2) works as you intended, 3) is working, although the client cannot distinguish it from 4), and 4) is not working. What would fix your situtation is implementing our <include> proposal. The server would then know when to return the workprops, and a client knows that the server does not implement workprops if they are not returned. //Stefan
Received on Thursday, 22 November 2001 04:37:02 UTC