Re: Content negotiation and Vary (1.3, 12, 13.5, 14.43)

>To: jg@w3.org
>Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, koen@win.tue.nl
>Subject: Re: Content negotiation and Vary (1.3, 12, 13.5, 14.43) 
>In-Reply-To: Your message of "Mon, 03 Jun 1996 01:39:49 EDT."
>             <9606030539.AA08971@zorch.w3.org> 
>Date: Mon, 03 Jun 1996 01:56:23 -0700
>From: "Roy T. Fielding" <fielding@liege.ics.uci.edu>
>
>>>>content negotiation
>>>>  The mechanism for selecting the appropriate representation when
>>>>  servicing a request, as described in section 12.  Note that response
>>>>  messages may be negotiated, as well as resources.
>>>
>>>This last sentence is confusing.  I suggest that this sentence is
>>>deleted.
>
>So do I -- it was not in my version.  In any case, the "response message"
>is not negotiated -- only the representation of the response entity.
>

I see the complaint.  Hopefully this will help.  I think the note
is needed though, to help straighten out the confusion many have had.
Here's what I'm going with:

representation
  An entity included with a response that is subject to content
  negotiation, as described in section 12. There may exist multiple
  representations associated with a particular response status.


content negotiation
  The mechanism for selecting the appropriate representation when
  servicing a request, as described in section 12. The
  representation of entities in any response can be negotiated
  (including error responses), as well as entities derived from
  resources.

Note that the second sentence of my definition of representation
deletes "of a requested resource" that was in Roy's definition
to:
	1) remove the implication that representations are
	limited to those derived from resources; HTTP can/does
	transfer entities not derived from resources.
	2) reduce the confusing that is implied when representation
	is defined in terms of resources, that tends to imply
	error entities might be handled differently (as in Koen's
	and other's confusion).

>> I think the fact that responses in general are negotiable is
>> worty of note.  See if this sentence does better
>> 
>> Note, therefore that responses of all sorts can be negotiated
>> (including error responses), as well as entities derived from
>> resources.
>
>I find it more confusing to make special mention of something which
>is not a special case -- it causes me to wonder about all the other
>non-special cases which are not specifically noted.  I also think
>the second note is more confusing than the one I would delete anyway. :)
>

Hopefully you'll like the above.  In any case, it is what I'm
going with.

>>>>12 Content Negotiation
>
>>...[other jg changes which look fine to me]
>>>>...
>> The real bug is the definition of representation, which I don't think
>> Roy dealt with properly.  I've reworked the representation definition
>> to make clear we mean any entity, not just those of resources.
>> 
>> representation
>>   An entity included with a response that is subject to content
>>   negotiation, as described in section 12.  There may exist multiple
>>   representations associated with a particular resource.  Likewise,
>>   there may be multiple representation of entities returned in error
>>   responses.
>
>Nope, I disagree.  It should be just
>
>  representation
>    An entity included with a response that is subject to content
>    negotiation, as described in section 12.  There may exist multiple
>    representations associated with a particular response status.
>
>There always exist multiple representations associated with a particular
>resource -- a fact which doesn't imply content negotiation.  The "content"
>in content negotiation refers to the content within the response entity,
>not to the nature of the resource.
>

See above.  I think that by fixing the content negotiation
defn, we can go to a simpler representation definition.

>>...[other jg changes which look fine to me]
>>>>
>>>>12.2 Agent-driven Negotiation
>>>>
>>>Let me repeat my earlier objection to this section: there is no reason
>>>for including this section, as a discussion of transparent negotiation
>>>is not needed to justify the HTTP/1.1 protocol elements defined in the
>>>pre-04 spec.  The inclusion of this section will only increase the
>>>risk that the pre-04 spec is rejected on external review and might
>>>unleash a flood of questions on the mailing list that somebody would
>>>have to answer.
>> 
>> I think it very likely the spec will be rejected on this point.
>
>Jim meant to say "unlikely".
>
>> I think people have to see some idea of where we are going,
>> to understand the requirements we've laid on them.
>
>Me too.  I am also confident that it won't be rejected without a
>specific example which shows it to be broken, and I am fully capable
>of defending it against broken examples.
>
>>>>...
>>>>Transparent negotiation has the advantage of distributing the
>>>>negotiation work that would otherwise be required of the origin server
>>>>and also removing the second request delay of agent-driven negotiation
>>>>when the cache is able to correctly guess the right response and already
>>>                                                              ^^^^^^^^^^^ 
>>>>has that response cached.
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^
>>>
>>>In this case, the cache even removes the second request if it does not
>>>have the response cached, so the marked text above should be removed.
>
>Okay by me.
>

>> How could the cache help if it doesn't have that response cached?
>> Removing the phrase seems to me to reduce the sentence to useless.
>
>When the set of dimensions covered by Alternates matches the set of
>dimensions covered by Vary, the cache may interpret the first (general)
>GET request and replace it with the more specific resource identified
>by the Alternates.  This won't work for some requests (e.g., digest'd ones),
>and is not necessarily a good idea, but it is certainly possible.
>

Ok.  Done.



>>>>A cache performing transparent negotiation MUST include the agent-driven
>>>>negotiation information along with the response, and MUST add a Vary
>>>>header field to the response (defining the dimensions of its variance)
>>>>if a Vary field was not already assigned by the origin server.
>>>>
>>>>These requirements apply to HTTP/1.1 applications even though this
>>>>specification does not specify transparent negotiation, since an
>>>>understanding of these requirements is a necessary prerequisite for any
>>>                                                    ^^^^^^^^^^^^  
>>>>future implementation of these features.
>>>
>>>I read this to mean that HTTP/1.1 applications must be ready to
>>>interoperate with _future_ HTTP/1.1 caches which implement transparent
>>>negotiation, rather than the other way around.
>
>No, it means that any implementation of transparent negotiation must
>obey these requirements in order to avoid breaking HTTP/1.1 caches
>that (by that time) will already exist.
>
>>>In my reading, this part of the pre-04 text makes normative reference
>>>to a standard that has yet to be defined, which is clearly something
>>>that cannot be allowed.
>
>No, it does not.  It states a fact of HTTP (that transparent negotiation
>is possible in HTTP/1.1 even though it has not been STANDARDIZED), and
>then gives the known requirements associated with that fact.
>
>>>I suggest a complete rewrite of the last two paragraphs of 12.3 to:
>>>
>>> This specification does not define any mechanism for transparent
>>> negotiation, though it also does not prevent any such mechanism from
>>> being developed as an extension and used within HTTP/1.1.  A HTTP/1.1
>>> cache performing transparent negotiation MUST include a Vary header
>>> field in the response (defining the dimensions of its variance) to
>>> ensure correct interoperation with all HTTP/1.1 clients.
>
>Which is pretty close to the right thing.
>
>> I see what you are driving at, and talked with Roy about it.
>> This is what I came up with afterwards:
>> 
>> The following requirements apply to HTTP/1.1 applications even though
>> this specification does not specify transparent negotiation, to ensure
>> that a transparent negotiation extension can be added at a later time
>> and used within HTTP/1.1. Any cache that performs transparent
>> negotiation SHOULD include the agent-driven negotiation information
>> along with the response, and MUST add a Vary header field to the
>> response (defining the dimensions of its variance) if a Vary field was
>> not already assigned by the origin server, to ensure correct operation
>> with all HTTP/1.1 clients.
>
>Ummm, no, that's worse because it conflates the notion of transparent
>negotiation (which is defined) and the mechanism for it (which isn't defined).
>I see that was what Koen was really objecting to in draft 04a.
>Having read all three, I would prefer
>
>  This specification does not define any mechanism for transparent
>  negotiation, though it also does not prevent any such mechanism from
>  being developed as an extension and used within HTTP/1.1.  An HTTP/1.1
>  cache performing transparent negotiation MUST include a Vary header
>  field in the response (defining the dimensions of its variance) to
>  ensure correct interoperation with all HTTP/1.1 clients.  The
>  agent-driven negotiation information supplied by the origin server
>  SHOULD be included with the transparently negotiated response.
>

OK, I buy this last try...  Lets keep the language lawyers happy.
				- Jim

Received on Monday, 3 June 1996 08:00:59 UTC