Re: draft of 209 proposal

On 02/24/2014 07:40 AM, Eric Prud'hommeaux wrote:
> = 209 Draft =
> I have drafted a 209 proposal for Philippe to bring to IEFT London.
>    <http://localhost/2014/02/2xx/draft-prudhommeaux-http-status-209>

You meant this URI, right?
http://www.w3.org/2014/02/2xx/draft-prudhommeaux-http-status-209

David

> I included 3 test cases <http://www.w3.org/2014/02/2xx/tests/> for
> browser compatibility but note that the real consumers of this will
> be linked data applications.
>
>
> = Timing =
> IETF London is next week. IETF would need a proposal to be accepted
> by TAG and LDP in order to seriously consider it as an RFC. The LDP
> WG needs 209 by the end of LC in order to not fall back to an extra
> 303/200 round trip. In the interest of LDP's progress, I've drafted
> a summary of the conversation to date in hopes of gaining efficient
> acceptance of this or some draft for IETF. We have very little time
> to experiment with new ideas; any proposals for new schemes should
> be weighed against the possibility that they will derail the efforts
> to put this in LDP.
>
>
> = Summary =
> Below is the threaded view of TimBL's proposal for a 2xx response code.
> Interspersed are my summaries (underneat) and responses (in []s).
>
> A new HTTP response code say 209                Dec 19 Tim Berners-Lee
> │                   use case for a 209
> ├─>Re: A new HTTP response code say 209         Dec 19 Daniel Appelquist
> │                   London f2f logistics
> ├─>Re: A new HTTP response code say 209         Dec 19 Julian Reschke
> │ │                 299 as placeholder
> │ │                 why not 303 or 202?
> │ └─>                                           Dec 20 Tim Berners-Lee
> │                   payload conflict of 303
> │                   202 for asynchronous
> │                   303 fine logically but requires round trip
> ├─>Re: A new HTTP response code say 209         Dec 20 Mark Nottingham
> │ │                 use media type instead?
> │ │                 HTTPbis 8.2.2.  Considerations for New Status Codes
> │ └─>                                           Jan 09 Henry Story
> │   │               media types describe representation, not resource
> │   ├─>                                         Jan 09 Henry S. Thompson
> │   │ │             define in terms of 303+200
> │   │ ├─>                                       Jan 09 Henry Story
> │   │ │ │           +1 but propose 3xx instead of 2xx
> │   │ │ └─>                                     Jan 09 David Sheets
> │   │ │   │         respond with message/http
> │   │ │   ├─>                                   Jan 09 David Booth
> │   │ │   │ │       broaden 209 to cover 300, 301, 302 and 307
> │   │ │   │ └─>                                 Jan 09 David Booth
> │   │ │   │         or 300, 301, 302 or 307 + multipart body
> │   │ │   └─>                                   Feb 13 Reto Gmür
> │   │ │             confuses clients interpreting 2xx as 200
> │   │ │             could work in 303
> │   │ ├─>Fwd: A new HTTP response code say 209  Jan 09 Jonathan A Reese
> │   │ │             no evidence that 200 has intended semantics in practice
> │   │ └─>                                       Jan 09 Julian Reschke
> │   │   │           use 3xx code. 2xx response would apply to request-URI
> │   │   └─>                                     Jan 09 Henry S. Thompson
> │   │     │         Content-location understood wrt conneg
> │   │     └─>                                   Jan 09 Julian Reschke
> │   │       │       says there's a more specific URI
> │   │       └─>                                 Feb 10 Ashok Malhotra
> │   │         │     Arwe: propose: 303 + Prefer: return=representation
> │   │         └─>                               Feb 13 Yves Lafon
> │   │               dangerous, changes 303, would need Vary: Prefer. 2xx more applicable
> │   └─>                                         Jan 09 Julian Reschke
> │                   wording of 303
> └─>Re: A new HTTP response code say 209         Dec 19 Jonathan A Reese
>                      note http://www.w3.org/2001/tag/doc/urls-in-data-2013-04-27/
>
> draft-prudhommeaux-http-status-209 follow the advice of Henry
> S. Thompson Jan 09 to define the semantics in terms of 303+GET on the
> location. (Note that 308's definition leans on the definition of 301:
> <http://tools.ietf.org/html/draft-reschke-http-status-308-07#section-3>).
>
>
> = Issues =
> == 2xx vs. 3xx ==
>
> Browsers appear to treat unknown 2xx and 3xx identically as "good
> enough" representations of the retrieved resource. Proxies cache the
> response code so they also won't care about the difference. I think
> that the only applications we need to worry about are e.g. crawlers
> and Semantic Web clients. (In trying to build an infrastructure that
> descriminates between information resources and non-information
> resources, we're trying not to break machinery which makes exactly
> that distinction.) Many hand-tooled apps will fail with an unknown 2xx
> or 3xx status code. For that reason, the Deployment Considerations
> suggests that 209 be deployed conservatively. From the perspective of
> the LDP protocol and many emergent SemWeb protocols which will use
> 209, that's acceptable as they are yet to be deployed.
>
> It seems very hard to justify a 3xx in the face of Yves's point about
> the 303 body applying to the redirect and not to the target resource.
>
>
> == media type ==
>
> As Henry pointed out, media types really are meant to describe the
> representation. The media type proposals also all applied to 3xx,
> which again conflicts with 303's defintion of the body semantics.
>
>
> == 303 + Prefer ==
>
> This could probably work in a new protocol (with some civil disobedience)
> but it does violate the rule about the 303 body semantics.
>
>
> == Code Number ==
>
> Julian Reschke proposed using 299 but I was concearned that, given the
> number of tools that are likely to adopt this quickly, we'd be unable
> to eliminate 299 (à la "x-www-form-urlencoded"). 209 seems to be the
> safest bet.
>
>
> Many thanks for your focus and contributions. I hope we can solve this
> SemWeb-old problem quickly.
>

Received on Monday, 24 February 2014 14:27:25 UTC