RE: [ACL] Principal Identity

> 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