On Wed, Mar 12, 2014 at 10:11 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
> On 8 Mar 2014, at 2:56 am, Eric Prud'hommeaux <eric@w3.org> wrote:
>
> > * Mark Nottingham <mnot@mnot.net> [2014-03-07 09:25+0000]
> >> Hi Eric,
> >>
> >> PLH asked me to give some initial feedback on this draft. If you want
> proper feedback from the IETF, I’d encourage you to submit the I-D :)
> >
> > Happy to, could you tell me what the "I-D" is?
>
> Internet-Draft :)
>
>
> >> 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 3.1.4.1 #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.
Jonathan
Received on Thursday, 13 March 2014 13:45:32 UTC