- 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>
> 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:22 UTC