- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 4 Oct 2002 22:31:43 -0400
- To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
- Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25BD9@SUS-MA1IT01>
From: Julian Reschke [mailto:julian.reschke@gmx.de] 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). Yes, I wanted to make sure that variants and versions interoperated in a sensible way. Now that this has been separated from the versioning protocol though, we should probably reword some of it in a more generic way, so that the interaction with versioning is clear, but that a server can support variants without supporting other aspects of versioning. In my point of view, variant handling extensions to WebDAV need to be compatible with RFC2616 (HTTP), I agree. 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. That all works for me. How does this translate to WebDAV: - clarify that PROPFIND acts regarding variants the same way as GET and HEAD Agree. - the information from the vary header should be available as live property Agree (this is just an important subcase of the next bullet, true?). - 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) Agree. Do you have anything particular in mind here? 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?) I believe the semantics for these items all follow from the current variants draft, do they not? Do we have agreement on the goals, or do you really have a different idea of variant handling? I certainly agree with the goals that you've stated here. Cheers, Geoff
Received on Friday, 4 October 2002 22:32:32 UTC