W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002

RE: how to specify extension features in response to OPTIONS request

From: Julian Reschke <julian.reschke@greenbytes.de>
Date: Wed, 20 Mar 2002 10:12:26 +0100
To: "Lisa Dusseault" <ldusseault@xythos.com>, "'Greg Stein'" <gstein@lyra.org>, "'Sohn, Matthias'" <matthias.sohn@sap.com>
Cc: <ietf-dav-versioning@w3.org>, <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCAEOKEDAA.julian.reschke@greenbytes.de>
> From: Lisa Dusseault [mailto:ldusseault@xythos.com]
> Sent: Wednesday, March 20, 2002 3:24 AM
> To: 'Greg Stein'; 'Julian Reschke'; 'Sohn, Matthias'
> Cc: ietf-dav-versioning@w3.org; w3c-dist-auth@w3.org
> Subject: RE: how to specify extension features in response to OPTIONS
> request
>
>
> > There was some amount of consensus a while back on the DAV WG
> > list that the
> > DAV: header should allow Coded-URLs in it. mod_dav took this
> > approach, so an
> > OPTIONS response looks like:
>
> If Greg's approach is taken to avoid conflicts, then I see no
> strong reason
> to prefer live properties over OPTIONS header values in the general case.

...other that in this case this way to extend the DASL header must be
documented somewhere...?

> However, if the feature is one which relates only to some resources (e.g.
> all collections support the feature, or all resources in the
> directory foo,
> etc) then it might be helpful to advertise support for the feature only on
> those resources, using a live property as suggested.
>
> OPTIONS * still seems to be the most appropriate place to marshall
> server-wide features, with the conflict-avoidance caveats already
> mentioned.

How can this be the appropriate place if RFC2518 doesn't document how to do
that?
Received on Wednesday, 20 March 2002 05:18:17 GMT

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