Re: Important Change to HTTP semantics re. hashless URIs

On 3/25/13 4:42 AM, Mo McRoberts wrote:
> On Sun 2013-Mar-24, at 17:39, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>
>> All,
>>
>> Here is a key HTTP enhancement from Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content note from IETF [1].
>>
>> "
>>    4.  If the response has a Content-Location header field and its
>>        field-value is a reference to a URI different from the effective
>>        request URI, then the sender asserts that the payload is a
>>        representation of the resource identified by the Content-Location
>>        field-value.  However, such an assertion cannot be trusted unless
>>        it can be verified by other means (not defined by HTTP).
>> "
>>
>
> It's good to have the clarification (the wording in the new draft is nicer), but it's probably worth stressing that Content-Location isn't at all new, and this *mostly* amounts to a tidying-up of wording rather than a change in semantics.

Yes-ish. I say so that because you are correct with regards to the 
excerpt above. That said, here's an excerpt (further down in the note) 
that does hone into the matter that's challenged hashless HTTP URI based 
entity denotation for some time now re., Linked Data:

"If Content-Location is included in a 2xx (Successful) response message 
and its field-value refers to a URI that differs from the effective 
request URI, then the origin server claims that the URI is an identifier 
for a different resource corresponding to the enclosed representation.  
Such a claim can only be trusted if both identifiers share the same 
resource owner, which cannot be programmatically determined via HTTP."

Basically, the role of the Content-Location header with regards to 
Linked Data URI disambiguation heuristics is now much cleaner.

>
> Section 14.14 of RFC2616 (HTTP/1.1) states:
>
> “The Content-Location entity-header field MAY be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI."
>
> The biggest change here is actually the “However, such an assertion cannot be trusted..." part!

Anything to do with Trust ultimately lays the foundation for WebID and 
WebID+TLS value proposition comprehension and appreciation :-)
>
> --
> Mo McRoberts - Analyst - BBC Archive Development,
> Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
> MC3 D4, Media Centre, 201 Wood Lane, London W12 7TQ,
> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen