Subject: RE: Variant Support for WebDAV

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 4 Oct 2002 22:31:43 -0400

From: Julian Reschke [mailto:[email-masked]]

   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

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 5 Oct 2002 10:37:30 +0200

> From: [email-masked] [mailto:[email-masked]]On
Behalf Of Clemm, Geoff
> Sent: Saturday, October 05, 2002 4:32 AM
> To: 'Webdav WG'
> Subject: RE: Variant Support for WebDAV
>

Sounds good.

> Agree (this is just an important subcase of the next bullet, true?).

Yes.

> Agree.  Do you have anything particular in mind here?

- An unambigouos mapping algorithm from HTTP header names to WebDAV property
QNames. As as matter of fact, the HTTP extension framework (RFC2774) defines
URIs as namespace names for headers in HTTP extensions. I think we want to
include RFC2774-compatible headers, and the obvious way to map them is to
use a canonical mapping. This leaves us with the problem of choosing a
namespace name for non-RFC2774-compatible "plain" header names. Some choices
would be: a) no namespace, b) something like "urn:ietf:rfc:2616" (but we
don't control this namespace) or c) "DAV:http-header". See also dicussion in
[1].

- Having a QName may not be sufficient -- we may also have to think about
datatypes. The Vary header lists other header names, so a WebDAV property
probably should enumerate QNames of other WebDAV properties, such as

<D:prop xmlns:D="DAV:">
  <h:vary xmlns:h="urn:ietf:rfc2616">
    <h:accept-language/>
  </h:vary>
</D:prop>

> variants draft, do they not?

Do they? They say that I can't move a variant, but they don't say how a move
on the variant controller affects the variants. Maybe you could give an
example for a very simple use case such as two variants (HTML and PDF) --
how would the variant controller and the variant URLs look like?

> I certainly agree with the goals that you've stated here.

[1] <http://lists.w3.org/Archives/Public/ietf-http-wg/2002AprJun/0061.html>

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