RE: 3xx vs RFC2518 vs redirect-ref spec

Lisa,

> This proposal clearly has a lot of support.  I too favour a single
> client-feature-advertisement header. However, I'd like to caution the
group
> that we won't be able to demonstrate the interoperability of this header,
> and thus we take the risk that this won't be considered a suitable feature
> to take to the next standards phase (draft standard).

If we define the following:

- A DAV: request header MAY be sent by the client indicating compliance to a
specific WebDAV feature (in the same syntax as defined for the DAV: response
header)

	*and*

- Each protocol extension must explicitly declare what sending a specific
feature token indicates

	*and*

- If there's no such definition, clients MUST not send that token (thus we
can avoid the situation where clients start enumerating all kinds of
extensions although this info is completely useless to the server)


then there shouldn't be an issue at all. RFC2518bis would just provide the
marshalling framework for other specs, and *those* would need to show
interoperability.

The first canditates for actually *using* this IMHO are

- binding spec (client indicates that it knows about new bind-loop-detected
condition in multistatus response)

and

- redirect ref spec (client indicates that it knows how to deal with
Location info in multistatus)

(side note: interestingly, both use cases are about PROPFIND response
formats).




Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Sunday, 19 October 2003 07:26:45 UTC