W3C home > Mailing lists > Public > www-tag@w3.org > March 2014

Re: draft of 209 proposal

From: Mark Nottingham <mnot@mnot.net>
Date: Sun, 16 Mar 2014 06:39:00 +1100
Cc: Eric Prud'hommeaux <eric@w3.org>, Tim Berners-Lee <timbl@w3.org>, TAG List <www-tag@w3.org>, Arnaud Hors <lehors@us.ibm.com>, Yves Lafon <ylafon@w3.org>, Philippe Le Hégaret <plh@w3.org>, Peter Linss <peter.linss@hp.com>, "Appelquist Daniel (UK)" <Daniel.Appelquist@telefonica.com>
Message-Id: <236388AE-A77C-4B48-B76B-6A2933D514F2@mnot.net>
To: Jonathan A Rees <rees@mumble.net>

On 14 Mar 2014, at 12:45 am, Jonathan A Rees <rees@mumble.net> wrote:

> >> First of all, I’d like to understand what you think this status code is giving you over just using a 200 with Content-Location.
> >
> > As you point out below, the semantics we want involve a redirect, specifically "I can't give you X but I can give you Y which describes it."
> But it's not really a redirect; the semantics you want are "you asked for that, but I'm giving you this." That's 200 with a Content-Location, because the resource *is* making an assertion about something, even if it has a separate identity.
> p2 #4 "If the response has a Content-Location header field and its
>        field-value is a reference to a URI different from the effective
>        request URI, then the sender asserts that the payload is a
>        representation of the resource identified by the Content-Location
>        field-value. "
> In the 209-like scenario the payload would *not* necessarily be a representation of the resource identified by the Content-Location field-value. Or equivalently, the sender might not want to make such a warrant.
> So I don't think your suggestion to involve Content-Location in this discussion is appropriate.
> Not that I'm a fan of 209, but I like using Content-Location in this situation even less.

Can you say a bit more about why that wouldn’t be the case?

Mark Nottingham   http://www.mnot.net/
Received on Saturday, 15 March 2014 19:39:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:01 UTC