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:
  <http://example.org/uri> - 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: <http://example.org/uri-documentation>; 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 http://example.org/uri is the content of http://example.org/uri (or that http://example.org/uri identifies an information resource), but there is an implication that what you get from http://example.org/uri-documentation is the content of http://example.org/uri-documentation (and that http://example.org/uri-documentation 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.

Best,

> 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: http://example.com/uri-documentation>
>>>>
>>>>   * using a Link: response header with link relation 'describedby' ([rfc5988],      [powder]), e.g.
>>>>
>>>>     200 OK
>>>>     Link: <http://example.com/uri-documentation>; 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 :<http://www.iana.org/assignments/relation/>
>>>>     <http://example.com>        :describedby <http://example.com/uri-documentation> ;
>>>>       .
>>>>
>>> Seeking clarification,
>>> Given some arbitrary thing and a description of that thing, let's say:
>>>  <http://example.org/uri> is described by <http://example.org/uri-documentation>
>>> 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 :<http://www.iana.org/assignments/relation/>
>>> <http://example.com> :describedby <http://example.com/uri-documentation>
>> PREFIX :<http://www.iana.org/assignments/relation/>
>> <http://example.org/uri> :describedby <http://example.org/uri-documentation>
>>
>> c+p error, apologies.
>>
>>> Is this correct?
>>> TIA
>>
>>
>

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