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: Wed, 24 Apr 2002 20:37:22 +0200
To: <tim@ellison.name>, "'Deltav WG'" <ietf-dav-versioning@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCMEJEEHAA.julian.reschke@greenbytes.de>
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Tim Ellison
> Sent: Wednesday, April 24, 2002 5:50 PM
> To: 'Deltav WG'
> Subject: RE: Label header vs PROPFIND depth 1
> Stefan Eissing wrote:
> > The result of a GET has to be cacheable by HTTP proxies.
> I see nothing to prevent the response from a GET including a
> 'Cache-Control:
> no-cache' header.  Why do you say that?
> > For the LABEL header to be compliant with GET, it has to
> > select a variant (as variant in rfc2616) of the resource
> I disagree that it has to select a variant (or at least I haven't
> been shown
> why yet).

I think the situation is as follows: regarding the label header, RFC3253
defines a behaviour for GET that clearly makes the selected version a
variant of the VCR (according to RFC2616). No matter what RFC3253 says, GET
is defined by RFC2616. If a server exposes behaviour for GET that makes a
resource a variant according to the text of RFC2616, it *is* a variant (no
matter what another RFC says). If "the other" RFC says it isn't a variant,
it clearly breaks the HTTP protocol.

That aside, why are you so opposed to this interpretation?
Received on Wednesday, 24 April 2002 14:38:07 UTC

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