Re: part 2, 5.1 "the response payload is a representation of the target resource"

On 11/02/2012 3:28 a.m., Jonathan A Rees wrote:
> I think my previous email expresses the problem, but should there be
> any question, I wrote up the issue in a bit more detail in a blog
> post:
>
> http://odontomachus.wordpress.com/2012/02/09/when-identification-and-representation-fight-who-wins/

"If both kinds of authority hold, then Jabberwocky is a representation 
of the Magna Carta, since a URI owner can say both that the URI 
identifies the Magna Carta and that Jabberwocky is a representation of 
what is identified. But this is not true. How to resolve this paradox?"

Your argument is built on the assumption that the authority server can 
lie. It cannot. By definition whatever it says is fact.

Consider very carefully the question "how did the URI owner state the 
Magna Cart was its resource?".

  * In HTTP it makes that statement by producing a 200 status and a 
valid representation.

So... if what was produced was 200 and Magna Carta. What statement was 
just made?
   --> That the URI resource is represented by a Manga Carta.

So... if what was produced was 200 and a Jaberwock. What statement was 
just made?
   --> That the URI resource is represented by a Jaberwock.

Now where does that confusion come in? Only if you assume that one of 
those is 100% truth for the entire resource.

Neither spec says anything about one representation being the whole of 
the resource. Only that it is *a* representation for the resource and 
resource itself is loosely defined as being "whatever might be 
identified by a URI".

So if your authority the URI owner is stating both Magna Carta and 
Jaberwock are valid representations. It must be a set of (Jaberwock | 
Magna Carta). The URI owner cannot lie.

Or to summarize in symbolic what you argue that:
   J is a subset of (J, MC)
   MC is a subset of (J, MC)
   therefore J == MC -> which is false.

Now, getting back to your proposed "solution". You have confused what 
the authority is saying with what gets delivered. None of the specs 
define them as being the same. In fact several mechanisms are built 
around verifying the delivered item was what got said by the authority.

Kitten-net with adaptation is not producing authoritative images of your 
set (Jaberwock | Magna Carta). Even though Kitten-net proxies produce 
200 and a representation, they are *not* the authority for that URL and 
are violating HTTP if they use 200 to deliver the kitten. (The proper 
way is to 3xx redirect to a different URI for the kitten.)

Your solution (1) sounds like having the spec mandate Conten-Location be 
set whenever the payload is not representing the requested URI. Does it 
not do so already?
   If not that would enable adapters to alter the payload without 
setting such as Content-Location and thus allow Kitten-net authoritative 
lies stating that Magna Carta == Kitten123.  "K is a subset of (J, MC)". 
They can already do that today, but we need grounds to beat up on 
adaptators who fail to set truthful Content-Location or use 3xx redirects.

Your solution (2) only works for static resources. Prohibiting dynamic 
URI resources by requiring the representation negotiation of HTTP (and 
all possible related protocols) to be encoded explicitly in the URI. 
This has the additional problem that negotiation only exists because the 
client cannot know in advance which representation the server will 
produce for it, so cannot encode that representations parameters in the URI.

AYJ

> Best
> Jonathan
>
> On Tue, Feb 7, 2012 at 10:08 AM, Jonathan A Rees wrote:
>> The confusion I pointed out in 7.3.4 is also present in section 5.1. We have
>>
>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-18#section-5
>>
>> "1.  If the response status code is 200 or 203 and the request method
>>       was GET, the response payload is a representation of the target
>>       resource."
>>
>> If you mean "representation" in an ordinary-language sense, then the
>> status code only *indicates*, it does not *imply*. So we cannot
>> conclude that the payload is a representation of the target resource;
>> we can only conclude that the server *says* it is a representation of
>> the target resource. We would need more information, such as trust in
>> the server, to conclude that it actually *is* a representation. (This
>> is true even if the server is the origin server.)
>>
>> In the language of that section, one would say "the response payload
>> is a representation *associated with* the target
>>       resource [by the server]" - i.e. the server has made the
>> association, and that association might be incorrect, and that's
>> OK, it's up to the application to sort it all out.
>>
>> There is another solution to this problem besides changing 5.1 and
>> 7.3.4: You could define "representation" as a term of art, making it a
>> static property of HTTP exchanges, one that is decided by fiat by the
>> server, not an ordinary-language word. This would be rather tricky I
>> think, and again I don't think it's what you intend, but I'm not sure.
>>
>> Yet another solution would be to say that the identity of the
>> identified resource is determined by the authoritative representations
>> that are or might be transmitted, or that it must be such that those
>> representations are correct. Then there would be no way for the two to
>> get out of sync in the way I suggest. But I don't think that's what
>> you mean, either.
>>
>> I checked for "representation of" throughout part 2 and didn't find
>> any other difficulties with the use of this expression, so whatever
>> fix you choose is likely to be quite localized. Part 1 seems OK. The
>> single use in part 6 would need to be scrutinized. I didn't check the
>> other parts or other phrases.
>>
>> Best
>> Jonathan

Received on Saturday, 11 February 2012 05:42:32 UTC