Hi Kjetil, Nathan, I wonder if you would put together a brief change proposal [1] along these lines and send it to [email protected]. 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
