Subject: requested resource / entity / representation / variant again..

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 21 Jul 2009 18:27:26 +0200

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

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 22 Jul 2009 10:45:05 +1200

how about...

call it a response.  That way we don't make any assumptions about 
anything nor set any limitations.  You make a request, and you get a 
response.  The response may have changed or not since last time.  The 
response may vary on Accept-* headers.  The response may be cached.  The 
response may have been generated at a time specified in a Last-Modifed 
header.  The response may be the content of a file whose location 
matched the path part of the requested URI.  Or it may not.  The server 
can choose any response it wishes without any restriction.

This is basically the reality anyway.

To distinguish between the entire response message and the part of the 
message that is deemed to be "transferred", we could add some other noun 
to refer to the content (+ attributes) or refer to the response message 
as just that - the response message.

Just an idea.

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 23 Jul 2009 10:15:41 +1000

I had a quick look through the drafts, and found only one place where  
"requested resource" means anything other than "the resource  
identified by the target-URI (regardless of conneg)":

p3 3.2.1:
> Content-Encoding may be used to indicate any additional content  
> codings applied to the data, usually for the purpose of data  
> compression, that are a property of the requested resource. There is  
> no default encoding.

Here, conneg does (obviously) need to be taken into account (and I've  
created <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/183> to  
track this).

Did I miss any?

In other places where "requested resource" is used I think it is  
appropriate and switching to "requested representation" (or whatever)  
would be a mistake; e.g., the last-modified time *is* a property of  
the resource as a whole, not a specific representation. We do have a  
related open issue here, tangentially: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/107 
 >.

The only one where I had to stop and think was in p2 3.2.1 (semantics  
of 200 for a GET, as H points out); however, that's probably dependent  
upon the resolution of <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/69 
 > (which accounts for many of the surviving uses of "variant", BTW).

I've put a note in #69 to have a look at p2 3.2.1 to revisit this  
section as part of that issue's resolution. If you can find other  
places like that, please add them (or send to me).

I agree that conneg would benefit if it were mentioned that it's  
scoped to a requested resource.

All of that said, I'd very much like to see us take a systematic  
approach to determining the scope (server/resource/representation/ 
response/etc.) of metadata in the spec, because IME it's often been  
misinterpreted, and sometimes led to interop problems.

WRT "variant" -- that issue has not yet been closed, I think the  
editors are planning to work on it soon. See: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/109 
 >.

Cheers,

On 22/07/2009, at 8:45 AM, Adrien de Croy wrote:

> response.  The response may have changed or not since last time.   
> The response may vary on Accept-* headers.  The response may be  
> cached.  The response may have been generated at a time specified in  
> a Last-Modifed header.  The response may be the content of a file  
> whose location matched the path part of the requested URI.  Or it  
> may not.  The server can choose any response it wishes without any  
> restriction.
>
> To distinguish between the entire response message and the part of  
> the message that is deemed to be "transferred", we could add some  
> other noun to refer to the content (+ attributes) or refer to the  
> response message as just that - the response message.
>
> Just an idea.
>
> Adrien
>
>
> Henrik Nordstrom wrote:

--
Mark Nottingham     http://www.mnot.net/

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 23 Jul 2009 12:12:58 +0200

> created <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/183> to  

I have not done a full investigation to be honest. Just did a quick
reading and noticed that it is obvious the language used is still quite
inconsistent and ambiguous and want to kick the discussion alive again
at the broader scope. This is an issue that really needs to be solved
top-down by first defining and agreeing on a terminology drawing out the
map we work within and then applying it consistently to the documents
and would even argue that it's one of the more important tasks for
HTTPbis to resolve.

> related open issue here, tangentially: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/107 

Switching to variant here as the term is still defined for the purpose
and imho describes the thing reasonably well.

Last-Modified, ETag etc is a properties of the variant, not the URI
resource as a whole.  For example changes to the English variant do not
automatically means the Swedish variant change as well. Nor do a
detected change to one variant invalidate the other known variants of
the same URI. Each variant of a URI resource MAY be identified by a
unique URI as indicated by Content-Location if desired (see also below).

The conditionals all operate on the variant, and not the resource as a
whole. This is simply from the fact that the information they are based
on is that from a variant (Last-Modified, ETag) and not from the
resource as a whole where there may be many different such tuples one
for each variant.

Part of the issue here is that some operations operate on the variant,
while some operations operate on the URI resource. For example GET/HEAD
always operate on a variant, while PUT & DELETE operate on the URI
resource. Conditionals however all operate on the requested variant
which complicates life somewhat for the methods operating on URI
resources if applied to a resource having content negotiation.

As one way to resolve this for those methods HTTP provides the option to
use Content-Location to identify a specific variant, enabling DELETE and
friends to operate on that specific variant by switching to the
variant-specific URI as learned from a GET/HEAD operation.

For DELETE I can perfectly well imagine there is different
implementations out there operating either on the resource or the
variant. In fact I would probably expect most to operate on the variant
and not the resource if at all accepted on a negotiated resource.

>  > (which accounts for many of the surviving uses of "variant", BTW).

Indeed, and #109.

We need to settle on one terminology which describes these aspects
reasonably well, and use it consistently.

> places like that, please add them (or send to me).

We should settle on the language/terms first, then look over the
document where [requested] resource / variant / entity /
representation / response etc and their plural forms is used and change
as appropriate. But until we have settled on a language I can only point
out examples of how the existing language is used inconsistently using
the same terms but not really meaning the same thing or where the use
does not match current definitions.

In most cases it will be trivial (editorial) to select the proper term
for the section in question once we have settled on the terms.

Some sections such as Content-MD5 and 206 may need a little more
discussion but such discussions is best done after we have all settled
on the terminology or it will just drain energy from the terminology
discussion.

wait.. I withdraw that.. 206 is an important parameter to include in the
terminology discussion just as content negotiation is (beware, there is
a a whole can of worms there). But Content-MD5 should wait a bit imho.

> scoped to a requested resource.

I am sorry, but what exactly do you refer to by "requested resource"
when there is content negotiation?

> misinterpreted, and sometimes led to interop problems.

Which at the heart is what this is all about.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Jul 2009 08:17:56 +1000

> when there is content negotiation?

The resource at the target-URI, of course. All I'm saying is that when  
you're talking about selecting a representation to send in a response*  
when connect is in use, the pool of possible representations is  
bounded by those associated with / belonging to the requested resource.

* What p6 2.6 currently calls the "selected response", although I  
suspect that may eventually need to change if we're to properly  
address the terminology issue.

> Which at the heart is what this is all about.

Agreed.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Jul 2009 08:34:07 +1000

Regarding 'requested resource', would it be better if we used  
'targeted resource' consistently?

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 24 Jul 2009 00:57:36 +0200

> 'targeted resource' consistently?

I can¨t really comment on that before we have had a serious terminology
discussion as it's not at all helpful going around changing one term at
a time. But I think I prefer requested resource over targeted resource
assuming it intends to mean the same thing (Request-URI).

Related to this there also needs some explanatory text describing why
operations operating on an URI as such like PUT/DELETE and content
negotiation do not mix very well.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 24 Jul 2009 01:24:54 +0200

> address the terminology issue.

for now I would probably remove selected response from p6 2.6 as
follows:

from:

        The stored response with matching selecting request-headers is
        known as the selected response.

        If no selected response is available, the cache MAY forward the
        presented request to the origin server in a conditional request;
        see Section 2.4.

To:

        If no response with matching selecting request-headers is
        available, the cache MAY forward the presented request to the
        origin server in a conditional request; see Section 2.4.

unless there is plans to actually define "selected response" as a term
and use it elsewhere as well.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Jul 2009 10:09:11 +1000

The term was added because it was needed in 2.4;
> When a cache has one or more stored responses for a requested URI,  
> but cannot serve any of them (e.g., because they are not fresh, or  
> one cannot be selected...

> When sending such a conditional request, the cache SHOULD add an If-  
> Modified-Since header whose value is that of the Last-Modified  
> header from the selected (see Section 2.6) stored response, if  
> available.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Jul 2009 10:16:24 +1000

> assuming it intends to mean the same thing (Request-URI).

Request-uri is now request-target; I suggested that term to reflect  
that, as well as avoid the resource vs respresentation confusion that  
"requested" brings about.

Regarding having a serious terminology discussion - of course it needs  
to be considered as a whole, but we have to start somewhere. We've had  
these issues on our list for quite some time and have only made stop  
and start progress so far; I'm hopeful that next week will be an  
opportunity to make more significant inroads.

> negotiation do not mix very well.

I think that depends on how #69 goes...

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 24 Jul 2009 02:29:43 +0200

> > header from the selected (see Section 2.6) stored response, if  

Ah, it is used already. A quick search did not find that due to the
comment.. To be more consistent and easier to find it should perhaps
read

        [...] from the selected response (see Section 2.6), [...]

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 24 Jul 2009 02:42:17 +0200

> opportunity to make more significant inroads.

YEs. With serious I mean a discussion trying to cover them all in
context of how they relate to each other.

The problem is that trying to discuss them isolated one at a time looses
too much of the big picture of how they relate resulting in too many
"what is really X" questions instead of "what do we call X". And the
fact that we already are changing terminology here and there "at random"
does not really help much.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 24 Jul 2009 02:59:17 +0200

> "requested" brings about.

Sorry, did not realize it had been changed.

request-target to me too easily gets confused with the selected
representation when there is content negotiation (same problem as
"requested resource"). Put I won't propose undoing that change at this
time.

Regards
Henrik