Re: draft of 209 proposal

To/Cc + Julian Reschke, who kindly offered to help me with submission.


* Eric Prud'hommeaux <eric@w3.org> [2014-03-07 10:56-0500]
> * 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?
> 
> 
> > 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."
> 
> Hey TAG folks, is there some writeup of the http-range-14 decisions to use 303 for '/' and 200/appropriate media type for '#' URLs?
> 
> 
> > The GET->303 use case can be met by that, I think, and so can POST->303; these are already widely-understood patterns of use.
> 
> GET->303 works fine but it requires two round trips. The purpose of 209 (2xx) is to avoid a round trip. This is expected to be used in high volume services in the Linked Data Platform.
> 
> 
> > The third use case (partial feeds) is already indicated in content (as per RFC5005, which you reference), so I’m again not sure what a new status code brings to the table.
> > 
> > Specifically, how will HTTP software behave differently when receiving this status code?
> 
> RFC5005 encourages the same identifier to be used for both the entire resource and a page of that resource. Using some syndication format like Atom can disambiguate this through a link rel="self" relationship, but our goal is to page resources directly rather than embedding them in an syndication framework. If some server is unwilling to serve the whole resource in a request, we don't want the metadata about that first page to be taken as the data about the requested resource. For instance, <X> has 500 entries and <X;page=1> has 10 of them or <X> is Bob's patient record and <X/byClinic/Mayo> is Bob's history at Mayo Clinic.
> 
> 
> > Also, you say:
> > 
> > > Caching semantics are for the response are the same as for a 200 response to a GET on the target resource, though it is not necessary to include the Location header field as it is identical to the effective Request URI. Additionally, the 209 response to the initial request MAY be cached but it MUST include the Location header field in cached responses. Thus, a 209 response can be seen as providing two cache entries, a 200 response for the resource expressed in the Location header field and a 209 response for the initial resource.
> > 
> > That is not safe to do; in HTTP resource A can’t provide content to be cached under resource B’s URI. The security folks won’t let this happen, full stop, and the WG has demonstrated strong consensus on this matter in the past.
> 
> Yeah, I expect that even respecting a same-origin constraint won't be sufficient assurance to permit polluting other peoples' caches. That said, app-specific caches are likely to do this routinely; should an RFC mention this?
> 
> 
> > Cheers,
> > 
> > 
> > 
> > On 24 Feb 2014, at 12:40 pm, Eric Prud'hommeaux <eric@w3.org> 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>
> > > 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.
> > > 
> > > -- 
> > > -ericP
> > > 
> > > 
> > > * Tim Berners-Lee <timbl@w3.org> [2013-12-19 11:55-0500]
> > >> 
> > >> 
> > >> We need a new 20X status code (we refer to it as 209, though that can be regarded as a placeholder) to allow information relating to and useful but different from the original thing.
> > >> 
> > >> 209 could be deemed to be definitely equivalent  equivalent to 303 "see also" to another URI which gives 200.  The Location: y   header from the 303 would be the same as the one used in the 209 to identify the URI of the meta resource.
> > >> 
> > >> The fact that existing LD systems use 303 and LDP systems are thinking of it is a serious architectural problem as the extra round trips.
> > >> 
> > >> The payload is machine readable in each case I am interested in.
> > >> 
> > >> Example uses:
> > >> 
> > >> - You asked for massive data, I give you instructions for doing a query for a part of it
> > >> - You asked for a large thing, this is the first page of it.  See Proposal [1]
> > >> - You asked for some thing with URI u, I give you a document about it which has a different URI. Classic linked data use case see eg [2]
> > >> 
> > >> Possible process paths:
> > >> 
> > >> - Just define 209 in the spec, as an unauthorized extension of HTTP.  People do this with headers and HTML tags all the time.  Do this with IESG blessing.   This may not be deemed an appropriate process with in the IETF which has change control.
> > >> 
> > >> - Start an IETF effort to define 209 from the ground up, ASAP.  Problems: the LDP working group's lack of confidence that the process would be timely and would not be waylaid by people who did not have/understand the needs of the linked data community.
> > >> 
> > >> - Reserve the 209 code with a an internet draft -- and then code it into current code, then other of the 
> > >> 
> > >> - Etc ...  many other combinations
> > >> 
> > >> Can we discuss this at the next call?
> > >> Sorry about the short notice.
> > >> 
> > >> Timbl
> > >> 
> > >> Tim
> > >> 
> > >> [1] http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2013.11.04#Proposals_regarding_Paging_.26_209_vs_200
> > >> 
> > >> [2] http://linkeddatabook.com/editions/1.0/#htoc12
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > > 
> > > 
> > > office: +1.617.599.3509
> > > mobile: +33.6.80.80.35.59
> > > 
> > > (eric@w3.org)
> > > Feel free to forward this message to any list for any purpose other than
> > > email address distribution.
> > > 
> > > There are subtle nuances encoded in font variation and clever layout
> > > which can only be seen by printing this message on high-clay paper.
> > > 
> > 
> > --
> > Mark Nottingham   http://www.mnot.net/
> > 
> > 
> > 
> 
> -- 
> -ericP
> 
> office: +1.617.599.3509
> mobile: +33.6.80.80.35.59
> 
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.
> 
> There are subtle nuances encoded in font variation and clever layout
> which can only be seen by printing this message on high-clay paper.

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Friday, 7 March 2014 16:00:08 UTC