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:18:13 UTC