Variant Support for WebDAV

(Geoff has posted an initial draft at [1], here are some comments)

Geoff,

I see that you are approaching variant handling from a versioning point of
view -- at least you are re-using RFC3253 as framework (which I think makes
sense).

In my point of view, variant handling extensions to WebDAV need to be
compatible with RFC2616 (HTTP), so I was trying to approach the problem from
a lower level.

Let's take a look at a very simple use case that doesn't involve any
extensions of HTTP(1.1) at all:


- Discover a resource through GET or HEAD.

- Through the "vary" header, the server announces that the representation
(variant) it sent varies on one or several of the request headers, such as
"accept-language".

- It may also send a "content-location" header, giving the URI of the
possibly authorable variant of the requested resource.

- Client can then discover that variant, and if this does not vary on any
request header, PUT to it's URI.


How does this translate to WebDAV:

- clarify that PROPFIND acts regarding variants the same way as GET and HEAD

- the information from the vary header should be available as live property

- there should be a generic way to express HTTP headers as WebDAV properties
(RFC2518's approach is broken, because there's no obvious mapping from HTTP
header names to WebDAV properties)


The next step would be to consider

- copy and move behaviour

- authoring of the varying resource

- direct discovery of variants

- define how variants move with the varying resource (I think this is
something you're planning to handle with the variant controller resource,
right?)


Do we have agreement on the goals, or do you really have a different idea of
variant handling?



Julian




[1]
<http://www.webdav.org/deltav/protocol/draft-ietf-deltav-variants-xx.1.htm>
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Thursday, 3 October 2002 14:08:47 UTC