Subject: RE: Variant Support for WebDAV

From: Jason Crawford <[email-masked]>
Date: Mon, 14 Oct 2002 01:28:21 -0400

I don't have a lot of time to spend on this given how many discussion 
threads we have
alive right now, but just a quick comment...

Could we possibly implement this in a way that meshes with how we handle 
other
live resources?   Perhaps with the dav:source property?   It can just tell 
you at what
URL's to find the variants and optionally give clues about how the 
variants are
selected?   This might actually be a good defining use-case for the 
dav:source 
property.

Also, what is our target document for this?   Should I add an issue for 
this so that
it doesn't get lost?

J.

------------------------------------------
Phone: 914-784-7569

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 15 Oct 2002 10:51:46 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jason Crawford
> Sent: Monday, October 14, 2002 7:28 AM
> To: Julian Reschke
> Cc: Clemm, Geoff; 'Webdav WG'
> Subject: RE: Variant Support for WebDAV
>
>
>
other
you at what
variants are
dav:source
> ...

I think variants and sources are clearly different things. In HTTP,
"Variant" is a synonym for "representation" -- a resource can have many
representations, and HTTP already defines  how a server can signal depending
on which request criteria a particular variant was chosen ("variant"
header), and optionally what the more specific URI for this representation
is ("content-location" header).

Alternatively, a source of a resource is *not* a variant of the resource,
and thus should not be treated as such.

So at a minimum, a spec about variant handling in WebDAV must

- be compatible with the terminology in RFC2616
- should elevate the vary header and the content location headers to live
WebDAV properties
- should clarify the semantics variant-selection-relevant request headers
for the various WebDAV methods

On the other hand, it may also provide a framework for authoring varying
resources (and I think this is the primary target of Geoff's draft).

Last but not least: we should keep in mind that right now proper variant
handling is only possible if ugly workarounds are use if the client uses IE
as a browser (see bug report at [1] -- note that the bug is *still* present
in IE6).

Julian

[1] <http://bugs.apache.org/index.cgi/full/4118>

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

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 15 Oct 2002 14:39:09 +0200

Hi,

would it possibly make sense to define the BIND response for the case where
the client attempts to create a new binding to a collection, but the server
only supports bindings to non-collections?

---

From: "Jim Whitehead" <[email-masked]>
Date: Tue, 15 Oct 2002 10:40:20 -0700

I don't understand why a server would want to do one, but not the other. 

- Jim

> -----Original Message-----
> [mailto:[email-masked]]On Behalf Of Julian Reschke
> Sent: Tuesday, October 15, 2002 5:39 AM
> To: 'Webdav WG'
> Subject: BIND response codes
> 
> 
> 
> Hi,
>

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 15 Oct 2002 19:49:43 +0200

For the same reason a Unix file system by default behaves this way.

Hard links to collections are dangerous (loops) and in most cases required
(symlinks aka redirect refs to collections in most cases are all that's
required).

Julian

> [mailto:[email-masked]]On Behalf Of Jim Whitehead
> Sent: Tuesday, October 15, 2002 7:40 PM
> To: 'Webdav WG'
> Subject: RE: BIND response codes
>
>
>

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 20 Oct 2002 12:18:47 +0200

Hi,

RFC3253 defines several kinds of resources that MUST NOT be moved, for
instance version resources ([1]) and version history resources ([2]).

How does this impact the ability to create additional bindings?

a) You can't (so do we need additional preconditions)?
b) You can, but you can't delete the original binding (so do we need to
extend the DELETE semantics)?
c) We don't care -- BIND/DELETE may work, although MOVE is forbidden (in
which case I'd like zo understand why).

Julian

[1] <http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.3.15>
[2] <http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.5.8>