- From: Sandro Hawke <sandro@w3.org>
- Date: Wed, 16 Jan 2008 15:18:20 -0500
- To: Erik Wilde <dret@berkeley.edu>
- Cc: "uri@w3.org" <uri@w3.org>
> for recognizing the non-http nature of u1, software has to > dereference the uri, right? Right. (it's annoying, but oh well.) > from the http spec, your usage of 303 seems > to be much more nuanced and semantically loaded then what the spec > suggests. Absolutely. This design sort of fits into the open spaces in the HTTP Spec (and the existing implementations). > so i assume to discover the non-http nature of the resource > identified by u1, there must be some content within the returned > resource that makes that statement. logically, i see three ways how the > non-httpness of the identified resource could be established: > > 1. string matching with a magic prefix > > 2. the 303 returned when dereferencing the uri > > 3. embedded metadata in the returned resource > > what is the official vote on these? it seems that (2) is required, but > it cannot be sufficient given the rather general definition of 303 in > http. would (1) be ok? or is that discouraged? i am sure that (3) is the > w3c's favorite given its inherent rdfness, but i am wondering whether in > this whole approach there still is a chance for non-semantic web users > to understand the non-httpness of the resource identified by u1. The TAG reached consensus on 15 Jun 2005 to use option 2. That is not as "official" as a W3C Recommendation or a new IETF RFC for HTTP, but it's what we've got. See: http://www.w3.org/2001/tag/issues.html#httpRange-14 I don't think anyone is *happy* with this design, but it seems to work and to offer advantages over the alternatives. *shrug* -- Sandro
Received on Wednesday, 16 January 2008 20:20:48 UTC