W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2002

RE: Label header vs PROPFIND depth 1

From: Julian Reschke <julian.reschke@greenbytes.de>
Date: Tue, 23 Apr 2002 00:15:40 +0200
To: <tim@ellison.name>, "Deltav WG" <ietf-dav-versioning@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCMEEKEHAA.julian.reschke@greenbytes.de>
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Tim Ellison
> Sent: Monday, April 22, 2002 8:12 PM
> To: Deltav WG
> Subject: RE: Label header vs PROPFIND depth 1
> Julian wrote:
> > "variant
> > A resource may have one, or more than one, representation(s)
> > associated with it at any given instant. Each of
> > these representations is termed a 'variant.' Use of the term
> > 'variant' does not necessarily imply that the resource
> > is subject to content negotiation."
> >
> > So any representation you can GET on a URI is a variant of this
> resource.
> Don't see how that follows.
> If you delete a version-controlled resource it does not delete the version
> resource -- they are different resources.

Interesting point, but does RFC2616 say that deleting a resource must delete
all it's variants if those have separate URIs (returned as

If this would be the case, I would conclude that using the Label header so
select a version upon GET is a violation of RFC2616.

> > > If DeltaV implies that a version is a variant of a version-controlled
> > > resource then that must be fixed.
> >
> > I'd turn it around: if you strongly believe that a version should not be
> > considered a variant of a resource, then at least the label
> > header semantics must be removed from the spec.
> I see no reason why the label: header cannot be defined to 'redirect' the
> method to another resource.

Well, that's not supported by RFC2616. Either it *selects* the version (then
it is a variant by definition), or it causes an HTTP redirect. I don't think
you can have both.
Received on Monday, 22 April 2002 18:16:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC