W3C home > Mailing lists > Public > www-tag@w3.org > December 2013

Re: A new HTTP response code say 209

From: Tim Berners-Lee <timbl@w3.org>
Date: Fri, 20 Dec 2013 13:52:43 -0500
Cc: TAG List <www-tag@w3.org>, Arnaud Hors <lehors@us.ibm.com>, Eric Prud'hommeaux <eric@w3.org>, Mark Nottingham <mnot@mnot.net>, Yves Lafon <ylafon@w3.org>, "plh@w3.org Le Hegaret" <plh@w3.org>, Peter Linss <peter.linss@hp.com>, "Appelquist Daniel (UK)" <Daniel.Appelquist@telefonica.com>
Message-Id: <FEC84926-1A67-4FFC-A4F1-71F48B8C62A8@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

On 2013-12 -19, at 12:15, Julian Reschke wrote:

> On 2013-12-19 17:55, Tim Berners-Lee 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.
> 
> I would recommend to use 299 as a placeholder. There's a history of people picking the first unallocated code, then deploying code, then forgetting to register, then to find out that there is a collision.

Point taken.  Maybe 233

> 
>> 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.
> 
> Clarifying: you want to shortcut the 303->200 sequence? Where would you put the "other" URI in the 209 response? In Location? That really smells like a special case of 303 to me. Maybe augment 303 instead?

Well, 303 is a redirection, 200 codes deliver data.
If you put a body with a a redirection code then it normally explains why the redirection is happening, it does not provide the final thing which the redirection is to.

Are you thinking of quoting the final entity body somehow within the redirection body?


> 
>> 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.
> 
> Not if the 303 response contains sufficient information so that no round trip is required.

Then is isn't a redirection.

> 
>> 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
> 
> That smells like <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#status.202>.

But is different. 
202 Accepted means "I am started to do what you wanted me to do but I haven't finished at this time".

299 or whatever means "I have not done what you wanted at all, but here is some useful information about things you can do".

There is no asynchronous aspect to 299.


> 
>> - You asked for a large thing, this is the first page of it.  See Proposal [1]
> 
> Maybe 202 as well.
> 
>> - 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]
> 
> That *is* 303, no?

Yes.   The round trip is a severe problem.  Logically, 303 is fine.

> 
>> 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.
> 
> You won't get IESG blessing for something that doesn't fulfill the registration requirements, which *currently* require IETF Review, which implies an RFC (see <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#status.code.registry.procedure>).
> 
>> - 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.
> 
> Yes, that's the way to do it.
> 
>> - Reserve the 209 code with a an internet draft -- and then code it into current code, then other of the
> 
> There is no reservation process for status codes.
> 
>> - Etc ...  many other combinations
>> 
>> Can we discuss this at the next call?
>> Sorry about the short notice.
>> 
>> Timbl
>> ...
> 
> Best regards, Julian
> 

Tim
Received on Friday, 20 December 2013 18:52:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:00 UTC