- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sat, 11 Feb 2012 18:41:56 +1300
- To: ietf-http-wg@w3.org
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