- From: Julian Reschke <julian.reschke@gmx.de>
- Date: 2002年10月15日 10:51:46 +0200
- To: "Jason Crawford" <nn683849@smallcue.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
- Message-ID: <JIEGINCHMLABHJBIGKBCAEFEFJAA.julian.reschke@gmx.de>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]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 > > > > 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. > ... 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
Received on Tuesday, 15 October 2002 04:52:25 UTC