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

Re: draft of 209 proposal

From: Jonathan A Rees <rees@mumble.net>
Date: Sat, 15 Mar 2014 17:06:46 -0400
Message-ID: <CAGnGFM+rKer=EVCFy5XFBB+uNi96a+99TxyOPS_1qp65pQ62Yg@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
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>
On Sat, Mar 15, 2014 at 3:39 PM, Mark Nottingham <mnot@mnot.net> wrote:

> 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?

Well, if I understand the HTTP philosophy correctly, and I've tried hard
to, the terms "resource", "identifies", and "is a representation of" are
intentionally not defined by HTTP, but are rather determined (or
specifically interpreted) at the application layer.  Linked data is one
application at that next layer up. My understanding is that according to
linked data, there is currently a commitment to the existence of at least
one resource (sensu linked data) that has no representations (sensu linked
data) and yet is identified (sensu linked data) by an http: URI. GET of
that URI therefore can't yield either a 200 or a Content-location: header.

As I say I'm not keen on this design - I can't defend it, and I'm beginning
to think this whole 303/209 business is kind of silly. But while you might
argue that this commitment is a bad idea in the design of the linked data
application, it can't be ruled out by the HTTP spec.


> --
> Mark Nottingham   http://www.mnot.net/
Received on Saturday, 15 March 2014 21:07:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:24 UTC