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

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

From: Julian Reschke <julian.reschke@greenbytes.de>
Date: Tue, 19 Mar 2002 13:28:30 +0100
To: "Sohn, Matthias" <matthias.sohn@sap.com>, "Ietf-Dav-Versioning@W3. Org" <ietf-dav-versioning@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCKENAEDAA.julian.reschke@greenbytes.de>
>    >    > 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 07:28:34 GMT

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