Re: httpRange-14 Change Proposal

Jeni Tennison wrote:
> Nathan,
> Yes, that's correct. With no constraining Accept headers, it could alternatively return HTML with embedded RDFa with a <link rel="describedby"> element, for example.

Is that universally true?

Suppose /uri identified a PDF formatted ebook, or a digital image of a 
monkey in JPEG format, or even an RDF document.

Question A:

Currently we have:
  <> - a JPEG image of a monkey.

When you issue a GET on that URI the server currently responds
   200 OK
   Content-Type: image/jpeg
   Link: <>; rel="describedby"

So under this new proposal, the server can return the contents of 
/uri-documentation with a status of 200 OK for a GET on /uri?

If yes, this seems like massively unexpected functionality, like a 
proposal to treat "Accept: some/meta-data" like a DESCRIBE verb, and 
seems to exaggerate the URI substitution problem (as in /uri would be 
taking as naming the representation of /uri-documentation).

If no, where's the language which precludes this? (and how would that 
language go, given that it's exactly the same protocol flow and nothing 
has changed - other than the reader presuming that /uri now identifies 
something that does have a representation that can be transferred over 
HTTP vs identifying something that doesn't have a representation that 
can be transferred over HTTP).

Question B:

How would conneg work, and what would the presence of a Content-Location 
response header mean? Would HTTPBis need to be updated?

Question C:

Currently 303 "indicates that the requested resource does not have a 
representation of its own that can be transferred by the server over 
HTTP", and the Link header makes it clear that you are dealing with two 
different things (/uri and /uri-documentation), but where does this 
proposal make it clear at transfer protocol level that the 
representation included in the http response is a representation of 
another resource which describes the requested resource (rather than it 
being as the spec defines "a representation of the target resource")?

> Either way, there is no implication that what you've got from is the content of (or that identifies an information resource), but there is an implication that what you get from is the content of (and that is an information resource).

Sorry I don't follow, how is there an implication from a 200 OK for 
<uri-a> that it's not an IR and for <uri-b> that it is an IR?

If there was a Set of all Things (Set-A), then that set would have two 
sets, "the set of all things which can be transferred via a transfer 
protocol like HTTP" (Set-B), and then everything else (Set-C) which 
comprises Set-A minus Set-B. As far as I can tell, the one thing that 
determines whether something is a member of the Set-B or Set-C, for 
HTTP, is that 200 OK in response to a GET, hence why we need the 303.

This proposal appears to try and override that "rule" (fact) by saying 
let the content of a representation define what is a member of Set-B or 
Set-C, however the act of dereferencing itself is what determines 
whether an identified thing is a member of Set-B, as Set-B is the set of 
all things that can be dereferenced. Hence my confusion at this proposal.

Hope that makes sense, and that I've not totally misunderstood.


> Jeni
> On 28 Mar 2012, at 14:46, Nathan wrote:
>> Nathan wrote:
>>> Jeni Tennison wrote:
>>>> # Details
>>>> In section 4.1, in place of the second paragraph and following list, substitute:
>>>>  There are three ways to locate a URI documentation link in an HTTP response:
>>>>   * using the Location: response header of a 303 See Other response [httpbis-2],      e.g.
>>>>     303 See Other
>>>>     Location:>
>>>>   * using a Link: response header with link relation 'describedby' ([rfc5988],      [powder]), e.g.
>>>>     200 OK
>>>>     Link: <>; rel="describedby"
>>>>   * using a ‘describedby’ ([powder]) relationship within the RDF graph created by      interpreting the content of a 200 response, eg:
>>>>     200 OK
>>>>     Content-Type: text/turtle
>>>>     PREFIX :<>
>>>>     <>        :describedby <> ;
>>>>       .
>>> Seeking clarification,
>>> Given some arbitrary thing and a description of that thing, let's say:
>>>  <> is described by <>
>>> Previously we could GET /uri and either:
>>> a) follow the value of the Location header in a 303 response to get to /uri-documentation
>>> b) follow the value of the Link header to get to /uri-documentation
>>> With this proposal though we'd be able to say issue a GET to /uri with an Accept header value of text/turtle, and the server could return back the contents of /uri-documentation, with a status of 200 OK, and where the text/turtle response contained:
>>> PREFIX :<>
>>> <> :describedby <>
>> PREFIX :<>
>> <> :describedby <>
>> c+p error, apologies.
>>> Is this correct?
>>> TIA

Received on Wednesday, 28 March 2012 15:08:39 UTC