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

Yes,

I was going to mention that myself.

If your extensions implement new methods, reports or live properties, the
complete discovery framework is already there. Don't abuse OPTIONS for it.

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Tuesday, March 19, 2002 2:18 PM
> To: Ietf-Dav-Versioning@W3. Org
> Subject: RE: how to specify extension features in response to OPTIONS
> requ est
>
>
> If you hope other servers will
> start supporting some aspects of your proprietary extensions, you might
> want to consider using DAV:supported-method-set,
> DAV:supported-live-property-set,
> and DAV:supported-report-set.  This allows a client to determine whether
> or not a given server supports the features it needs, as opposed
> to looking
> for a particular bundle of functionality that one server chose to
> implement.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
> Sent: Tuesday, March 19, 2002 7:29 AM
> To: Sohn, Matthias; Ietf-Dav-Versioning@W3. Org
> Subject: RE: how to specify extension features in response to OPTIONS
> requ est
>
>
> >    >    > From: ietf-dav-versioning-request@w3.org
> >    >    > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of
> >    >    Sohn, Matthias
> >    >    > Sent: Tuesday, March 19, 2002 10:20 AM
> >    >    > To: Ietf-Dav-Versioning@W3. Org
> >    >    > Subject: how to specify extension features in
> >    response to OPTIONS
> >    >    > request
> >    >    >
> >    >    >
> >    >    > Hi,
> >    >    >
> >    >    > is it possible to specify extension features (that are not
> >    >    defined in the
> >    >    > DeltaV spec) in the response to a OPTIONS request ?
> >    >
> >    >    It's possible, but I would strongly recommend not to do that.
> >    >
> >    > Why ?
> >    >
> >    >    If you need a non-intrusive way to signal server extensions,
> >    >    use a custom
> >    >    live property.
> >
> >    Because OPTIONS headers don't have a concept of namespaces
> >    -- it's just a
> >    flat namespace. WebDAV properties are identified by
> >    (namespace, name), so by
> >    definition there won't be any confusion. Finally, the
> >    PROPFIND semantics
> >    defined in RFC3253 allow you not to report your extension
> >    property unless
> >    somebody (your client) is specifically asking for it.
> >
> > Do you think it would be ok to use OPTIONS in the following way to
> > signal server extensions ? In this approach XML namespaces would be
> > used to prevent name clashes :
> >
> > >>REQUEST
> >
> > OPTIONS /doc HTTP/1.1
> >   Host: www.webdav.org
> >   Content-Type: text/xml; charset="utf-8"
> >   Content-Length: xxxx
> >
> >   <?xml version="1.0" encoding="utf-8" ?>
> >   <D:options xmlns:D="DAV:"
> > xmlns:x="http:/www.sap.com/xyz/DAVExtensionSchema.xsd">
> >     <x:extension-feature-set/>
> >   </D:options>
> >
> > >>RESPONSE
> >
> >   HTTP/1.1 200 OK
> >   DAV: 1, version-control, checkout-in-place, version-history, workspace
> >   Content-Type: text/xml; charset="utf-8"
> >   Content-Length: xxxx
> >
> >   <?xml version="1.0" encoding="utf-8" ?>
> >   <D:options-response xmlns:D="DAV:">
> >     <x:extension-feature-set>
> >       <x:my-special-feature-1/>
> >       <x:my-special-feature-2/>
> >       <x:my-special-feature-3/>
> >     </x:extension-feature-set>
> >   </D:options-response>
>
> I would object to this for the same reasons why I think RFC3253 should not
> have touched OPTIONS request / response bodies.
>
> There's no technical reason why you would need to extend OPTIONs to do
> something a live property can do as well.
>
>

Received on Tuesday, 19 March 2002 08:30:25 UTC