RE: [ACL] Principal Identity

> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Thursday, November 22, 2001 11:53 AM
>
> > The defined way to do so, is to include these properties in the
> > {DAV:}supported-live-property-set. Then the client knows that the
> > server gives special meaning to these properties.
>
> However, supported-live-property-set is not part of RFC2518.  Therefore,
> regular DAV clients cannot rely on knowing what properties are
> live and what
> properties are dead on any given server.  Therefore, regular DAV clients
> cannot rely on knowing what properties they will get back on an 'allprop'
> request if 'allprop' is defined as returning 2518&dead properties.
>
> > Coming back to <allprop/>: a dead "image-height" property would
> > be reported, while a live property would not be reported. A client
> > interested in seeing "image-height" in either case, should attach
> > a <include>...</include> to allprop in our proposal.
>
> I think it's simpler to not use allprop at all.  Since so few
> properties may
> be returned by allprop, and all by propname, why not just use propname &
> then a specific query?  I'd want to see a rather compelling reason before
> inventing new syntax when existing PROPFIND syntaxes, without allprop,
> suffice.

Well, I don't know if this is compelling for you, but reasons for allprop
are:
- it's a single request. Typical use case for me is PROPFIND/allprop on
  a collection with Depth=1.
- To achieve the same with 2 propname/prop requests, I'd have to make a
  PROPFIND/propname Depth=1, calculate the closure of all propnames for
  all resources in that collection. Then perform a PROPFIND/prop with
  Depth=1 where <prop/> includes the set of all property names of all
resources.
- PROPFIND/propname is not for free. To calculate the exact set
  of live properties of a resource is often more expensive than answering
  an allprop request.

//Stefan

Received on Friday, 23 November 2001 03:55:30 UTC