Re: draft of 209 proposal

On 2014-03-13 14:45, Jonathan A Rees wrote:
>
>
>
> On Wed, Mar 12, 2014 at 10:11 PM, Mark Nottingham <mnot@mnot.net
> <mailto:mnot@mnot.net>> wrote:
>
>
>     On 8 Mar 2014, at 2:56 am, Eric Prud'hommeaux <eric@w3.org
>     <mailto:eric@w3.org>> wrote:
>
>      > * Mark Nottingham <mnot@mnot.net <mailto: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

Again: if you make it a 2nn status code, clients now knowing about the 
new status code will treat it just like 200. Are you ok with that?

Best regards, Julian

Received on Monday, 17 March 2014 10:07:20 UTC