Re: Change Proposal 25 for HttpRange-14

Would the Document header be sort of a strengthened version of
Content-Location, with the difference that the returned representation
is not a "representation of the target resource" (i.e., probe URI)?

My understanding then is that the change would entail a modification
of [1], by inserting two new rules (at positions 1 and 2):
"1.  If the response has a Document header field, and that URI is the
same as the effective request URI, the response payload is a
representation of the target resource." (based on the current rule #3)
"2.  If the response has a Document header field, and that URI is not
the same as the effective request URI, then the response asserts that
its payload is a representation of the resource identified by the
Document URI.  However, such an assertion cannot be trusted unless it
can be verified by other means (not defined by HTTP)." (based on the
current rule #4)

There's another possibility that could be considered: a Resource-ID
header. A response having a Resource-ID header field would imply that
"the response is a representation of an anonymous (i.e., unidentified)
resource", regardless of status code (i.e., ignoring rules #1 and #2
[1]), _unless_ there is also a Content-Location header field, in which
case the payload "is a representation of the resource identified by
the Content-Location URI" (according to rules #3 and #4), but still
not a representation of the target resource.

The Resource-ID header field's value would be the probe URI and/or
other URIs (possibly with non-HTTP URI schemes, perhaps urn:isbn for
book resources, etc.). If the Resource-ID is the same as the probe
URI, and a Content-Location is provided, then this should be
equivalent to having a Document header (with the value of the
Content-Location) as in the change proposal.

I'm not sure whether people would find it easier to specify a
Resource-ID than a Document header, or whether the lack of a document
URI (in the case of no Content-Location) would be a problem in some
cases. Perhaps in some workflows, it would be more intuitive (creating
an HTML document, specifying a Resource-ID for it possibly by using a
meta http-equiv element, and the document is then somehow made
available on the Resource-ID URI). It may also be useful to be able to
find out the (canonical) URI(s) for a resource (e.g., for finding it
as a subject resource within RDF content). Browsers could probably do
some cool stuff in their UIs if they had other URIs for the resource
(looking up a book using its ISBN on other websites, offering the user
a choice about which URI to share, etc.).

If you think that this is a good (or at least interesting) idea, a
header such as Resource-ID could be considered in the discussion about
the Document proposal (what I've written here is obviously not a
full-fledged change proposal).

Best regards,
Erik

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-5..1


On Sun, Mar 25, 2012 at 7:48 PM, Tim Berners-Lee <timbl@w3.org> wrote:
> Jonathan,
>
> I have written the below idea up as a change proposal
> http://www.w3.org/wiki/HTML/ChangeProposal25
>
> The number "25" has no semantics.
>
> Tim
>
> On 2012-03 -25, at 12:35, Tim Berners-Lee wrote:
>
>> [...]  the basic idea of giving a way of the server making it
>> explicit that the URI identifies not the document but is subject, without the internet round-trip time of 303,
>> is a useful path to go down.
>>
>> If Ian Davis and co would be happy with it, how about a header
>>
>>       200 OK
>>       Document:  foo123476;doc=yes
>>
>> which means "Actually the URI you gave is not the URI of a this document,
>> but the URI of this document is  foo123476.html (a relative URI).
>>
>> - This is the same as doing a 301 to foo123476.html and returning the same content.
>> - Non-data clients will ignore it, and just show users the page anyway.
>> - Saves the round trip time of 301
>> - Avoids having the same URI for the document and its subject.
>>
>> This will dismantle HTTP range-14 a bit more, but still never give the same
>> URI to two things.  It would mean code changes to my client code and just a reconfig
>> change to Ian's server.
>>
>> Tim
>>
>>
>>
>
>

Received on Sunday, 1 April 2012 12:23:30 UTC