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

From: Jonathan A Rees <[email-masked]>
Date: Tue, 7 Feb 2012 10:08:52 -0500

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

---

From: Jonathan A Rees <[email-masked]>
Date: Fri, 10 Feb 2012 09:28:03 -0500

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/

Best
Jonathan

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 11 Feb 2012 18:41:56 +1300

> 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:

---

From: Jonathan A Rees <[email-masked]>
Date: Sat, 11 Feb 2012 09:24:14 -0500

I have answered your email as a comment on my own blog post.
Continuing here too much would fatigue the readership of the list, I
fear.

Jonathan