W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2001

RE: [ACL] Principal Identity

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 23 Nov 2001 09:01:48 +0100
To: "Lisa Dusseault" <lisa@xythos.com>, "Stefan Eissing" <stefan.eissing@greenbytes.de>, "Webdav WG" <w3c-dist-auth@w3c.org>
Message-ID: <JIEGINCHMLABHJBIGKBCOEFEDIAA.julian.reschke@gmx.de>
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Thursday, November 22, 2001 11:53 AM
> To: Stefan Eissing; Webdav WG
> Subject: RE: [ACL] Principal Identity
>
>
> > 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.

A "regular" client (knowing just RFC2518) will rely on allprop returning
*all* properties. A "new" client (aware of deltaV) will know about
{DAV:}supported-live-property-set.

> > 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.

The existing RFC2518 syntax does suffice. However, that was modified in
deltaV and ACL. We just think that the modification isn't complete without
the inclusion facility. The compelling reason again is: performance (one
requests rather than two).
Received on Friday, 23 November 2001 03:02:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:59 GMT