- From: Henry Story <henry.story@bblfish.net>
- Date: Thu, 9 Jan 2014 11:18:34 +0100
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Tim Berners-Lee <timbl@w3.org>, TAG List <www-tag@w3.org>, Arnaud LeHors <lehors@us.ibm.com>, Eric Prud'hommeaux <eric@w3.org>, 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 20 Dec 2013, at 01:42, Mark Nottingham <mnot@mnot.net> wrote: > Hi Tim, > > > On 20 Dec 2013, at 3:55 am, Tim Berners-Lee <timbl@w3.org> wrote: > >> >> >> 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 > > Couldn't you distinguish that using the media type of the response? It is a bad idea to put semantics into media types. Media types are there to help interpret the representation coming back from the resource, not for describing the resource itself ( since after all the same resource could have a number of different representation in different formats, as we do in RDF land regularly ) > >> - You asked for a large thing, this is the first page of it. See Proposal [1] > > That seems like it's buried in the semantics of the response media type (as Atom does). yes, Atom could not do any better, given that it restricted itself to solve evertything just using XML. Now everyone is on the JSON bandwaggon, and so Atom feels old hat, and irrelevant. Even Twitter stopped using it. Had Atom been specified in terms of semantics, then the fashion switch between XML and JSON would have had no serious impact on the protocol. I proposed such an Atom semantics during the Atom working group, but that working group then rewrote its charter to renegg on its promise. (The semantics is here btw http://bblfish.net/work/atom-owl/2006-06-06/AtomOwl.html ) In any case the LDP working group ( http://www.w3.org/2012/ldp/wiki/Main_Page) is continuing on in my view from Atom, which I would like to add was for its time a very good step forward. It's just this reliance on being specified at the syntax level that has proved to be its undoing. > >> - 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] > > As Julian says, 303. That requires one more round trip and it is often not necessary. What is wanted is something that does what 303 does, but returns the content immediately. Here is an attempt to think out this issue aloud: -- Modified 303? -- Perhaps a modified 303 would do that would return the content of the Location header? Ideally one would force the implication that the Location is different by requiring the client to interpret the relative URIs with respect to the Location given in the header. Things are a bit more complicated perhaps, as one would like the HTTP headers to also be interpretable with respect to the Location resource. Btw. the http-bis spec for 303 seems a bit out of date here: [ http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-25#page-57 [ This status code is applicable to any HTTP method. It is primarily used to allow the output of a POST action to redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response in a form that can be separately identified, bookmarked, and cached independent of the original request. ]] Atom and LDP use 201 for that, which seems like a much better answer than 303. All of the LinkedData folks are using 303 primarily to redirect urls about things to documents that describe them. On the negative side: sending the content with a 303 means that for resources such as those described by foaf ( eg: http://xmlns.com/foaf/0.1/knows ) where a number of resources all redirect to the same definition document, would mean that returning the definition of all the resources for a GET on each of the uris defined thereing would be a waste of bandwidth. But then, I suppose it would be easy for Dan Brickley to create a number of smaller definition docs, one for each concept defined. > > In all of these, I think the central question is "what truly generic semantics, independent of the media type, need to be surfaced, and to whom?" It is: the information you are looking for is at the URL over there. But we'll give it to you the pure unchanged representation here. Questions to deal with would also be: are the HTTP headers the same as the headers for the other resource. > The latter part of the question is the meat, I think. In most cases, status codes are added because software doesn't want to touch the body, and the distinction is so important / fundamental that merely a new header won't do the trick. > > >> 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 > > Please have a look at: > http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-25#section-8.2.2 > > > > >> >> 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 >> >> >> >> >> >> > > -- > Mark Nottingham http://www.mnot.net/ Social Web Architect http://bblfish.net/
Received on Thursday, 9 January 2014 10:19:41 UTC