Re: Thought: 207 Description Follows

Hi Kjetil, Nathan,

I wonder if you would put together a brief change proposal [1] along these lines and send it to www-tag@w3.org. The TAG is meeting on Monday and will be looking at the range of proposals that have been put before it to decide which one(s) to pursue.

Thanks,

Jeni

[1] http://www.w3.org/2001/tag/doc/uddp/change-proposal-call.html

On 28 Mar 2012, at 10:02, Nathan wrote:

> Hi,
> 
> I believe TimBL has suggested this previously with a 208, however both 207 and 208 are already assigned or mentioned in various DAV communities, thus 209 or higher would have to be used I believe.
> 
> Personally, I like the idea a lot, and the usefulness for IoT is great too - any convergence between the semantic web and IoT, especially at HTTP and descriptor level, would be great.
> 
> Best,
> 
> Nathan
> 
> Kjetil Kjernsmo wrote:
>> Hi all!
>> I hope it is OK that I just burst in here without having followed the discussion. Admittedly, I haven't been terribly interested, I've always enjoyed the 303 dance, I wrote the code and it was easy, and the IR/NIR distinction has always served me well. However, I also see that it is a bit painful to have to do follow a redirect, both for end users and for code, and the bit about cachability, CORS problems, etc makes it clear there is room for improvement.
>> So, how about a new HTTP response code, e.g. 207 Description Follows? I.e., it is like 200 OK, but makes it clear that what you're dereferencing is not an IR. Instead, you're getting a description of the thing.
>> This would have implications well beyond our community, GETting the URI of a device in the Internet of Things would  also reasonably return a 207. Without having thought too deeply about this, I suggest this means it satisfies the orthogonality of specifications constraint.
>> I just quickly hacked a server to test how browsers would react to a 207 code, and all browser I have did it gracefully. I therefore conjecture that clients needing to know the IR/NIR distinction will be able to figure it out by looking at the status code only, those that need not, would not need to be bothered.  Deployment costs should thus be very low. We're also working to get our code into Debian (older versions are already in Ubuntu), so if we have this settled before Debian Wheezy freezes in June, it would be available in mainstream hosting solutions late this year. I think that's a key, because many users control very little of their server setup, and custom code is "dangerous", but with the support of Debian the costs for hosters are marginal. Naively Yours,
>> Kjetil
> 
> 
> 

-- 
Jeni Tennison
http://www.jenitennison.com

Received on Wednesday, 28 March 2012 09:10:14 UTC