W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2002

RE: Marshalling DAV:xxx-collection-set as a live property, and no t an OPTIONS request.

From: Julian Reschke <julian.reschke@greenbytes.de>
Date: Mon, 8 Jul 2002 10:21:30 +0200
To: "Sohn, Matthias" <matthias.sohn@sap.com>, "'Clemm, Geoff'" <gclemm@rational.com>, "DeltaV \(E-mail\)" <ietf-dav-versioning@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCIEHDEOAA.julian.reschke@greenbytes.de>

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Sohn, Matthias
> Sent: Monday, July 08, 2002 7:49 AM
> To: 'Clemm, Geoff'; DeltaV (E-mail)
> Subject: RE: Marshalling DAV:xxx-collection-set as a live property, and
> no t an OPTIONS request.
>
>
>
> Hi,
>
> I vote for (c)
>
> I am not sure on which resources these live properties
> specifying server wide properties (which in general are not a property of
> a specific resource) should be exposed, I would appreciate some
> standardized
> way to define these server wide features.

In general, they *aren't* server wide. They only apply to a partition of the
namespace on that server. If these live properties are the same for all
resources on a server, you'll likely PROPFIND them on "/".

> In addition I would like to see that the same mechanism can be used to
> advertise
> server specific extension features preventing name clashes by the
> namespace
> of the respective live property

Could you please give an example of what you're trying to achieve? If your
server implements a specific extension, you can advertise it using
DAV:supported-method-set (not recommended :-),
DAV:supported-live-property-set or DAV:supported-report-set. If it doesn't
fit ito any of the categories, just define a new live property that acts as
a container element into which you can put all your extension information.
Received on Monday, 8 July 2002 04:21:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:43 GMT