- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Tue, 21 Jul 2009 18:27:26 +0200
- To: HTTP Working Group <ietf-http-wg@w3.org>
The "resource" discussion again highlighted the fuzziness on what "requested resource" really means. When reading the specs again I can only agree that it's still quite fuzzy, but for other reasons. The way "requested resource" vs "representation" is currently used confuses matters a bit. Intuitively "requested resource" should refer to the resource identified by the Request-URI. But in fact it's not.. To me it seems that quite many of the places which today say "requested resource" maybe should say "requested representation" (if one can say anything like that) to align them better with the language used for server driven content negotiation, or perhaps we should use the term "variant" consistently pretty much anywhere we say "requested resource" or "selected representation". But neither is good if there exists resources with no representations associated... If not that then the concept of "requested resource" and language used for describing server driven content negotiation both needs to be adjusted/clarified to connect them together. Some examples: p3 4. Content Negotiation "content negotiation" -- the process of selecting the best representation for a given response when there are multiple representations available. p3 4.1 Server-driven Negotiation ... select a representation ... etc, quite consistent use representation to identify what was selected and acted upon. Oddly this chapter talks very little about resources however.. However, in other areas "requested resource" or even "variant" (wasn't variant supposed to be killed some time ago?) is used for referring to pretty much the same thing. For example p4 6.5 If-Unmodified-Since If the requested resource has not been modified since ... p4 6.6 Last-Modified ... the variant was last modified. p2 8.2.1 200 OK GET & HEAD ... the requested resource ... While in some other areas "requested resource" seems to refer to the "resource" identified by the URI, regardless of any content negotiation taking place. And yes, Server driven content negotiation IS confusing to terminology as it causes the notion of a resource to be quite twisted and in reality is often implemented as several independent resources sharing the same URI... Sorry, head a litte dizzy now trying to sort some sense out of these terms when content negotiation is used.. can't really say I see a light yet. Regards Henrik
Received on Tuesday, 21 July 2009 16:28:02 UTC