RE: how to specify extension features in response to OPTIONS requ est

> From: Lisa Dusseault [mailto:ldusseault@xythos.com]
> Sent: Wednesday, March 20, 2002 3:28 AM
> To: 'Julian Reschke'; 'Clemm, Geoff'; 'Ietf-Dav-Versioning@W3. Org'
> Subject: RE: how to specify extension features in response to OPTIONS
> requ est
>
>
>
> > If your extensions implement new methods, reports or live
> > properties, the
> > complete discovery framework is already there. Don't abuse
> > OPTIONS for it.
>
> I don't agree with that recommendation.  The framework may be there for
> DeltaV, but it's not a general part of WebDAV.  If the people
> that asked the
> original question need to interoperate with clients that don't already use
> the DeltaV framework, then it may not be trivial or "already there" for
> them.

Lisa,

1) The question was initially raised on the delta-V list.

2) OPTIONS (as defined in RFC2518) doesn't define any way to advertise
private extensions. OPTIONS as defined in RFC2616 does not define any way to
extend it except by inventing new headers (with the obvious problems in name
scoping).

3) Any server supporting RFC3253 (or ACL) MUST support the live properties
DAV:supported-method-set, DAV:supported-reports-set and
DAV:supported-live-property-set. If a protocol extension affects live
properties, new methods (sigh!) or new reports, the discovery algorithm is
already defined, MUST be defined anyway, and there's no need to invent
another one.

4) Could you please explain why a client would have any problems using the
new RFC3253 live properties for feature discovery? It's no different from
PROPFINDing DAV:supportedlock to discover which locking features are
available.

> I also fail to see why using OPTIONS for its original purpose is abuse.

Because there's no RFC-sanctioned way to extend it except by inventing new
HTTP headers.

Received on Wednesday, 20 March 2002 04:21:54 UTC