Re: Changes to Content Negotiation, Entity Tags, and If-*

!comments after !...
		- Jim

From: (Koen Holtman)
Message-Id:  <>
Subject:  Re: Changes to Content Negotiation, Entity Tags, and If-*
Date:  Tue, 28 May 1996 22:34:51 +0200 (MET DST)
To: (Roy T. Fielding)
In-Reply-To:   <> from "Roy T. Fielding" at M
ay 28, 96 02:47:47 am

The explanations you gave for your diffs have not caused me to change
my mind.  I maintain that your diffs overspecify things, and that
these overspecifications sometimes directly contradict things the
content negotiation subgroup has consensus on.  You can find my
way of detecting consensus of the content negotiation subgroup in an
earlier message to Larry.

! there isn't much in Roy's stuff Ive seen I've seen that overspecifies things.

>  My diffs
>have no negative impact on future content negotiation

Your rewrites of the 300 and 406 status code do have this negative
impact.  They imply that a computer-readable list of representation
will be defined in future, _and that this list will be sent in the
entity body_.  The content negotiation subgroup however has consensus
that this list should be sent in the Alternates header.  The plain 1.1
draft should be silent about where and when this computer-readable
list will appear, and your text is not.

! As far as I can see (as I read Roy's text), there is only one word that even 
! implies that the entity would be parsed; that is the second instance of
! the word format, marked -format- below, that is unneeded anyway.
! "Unless it was a HEAD request, the response SHOULD include an entity
! containing a list of resource characteristics and locations from which
! the user or user agent can choose the one most appropriate. The entity
! format is specified by the media type given in the Content-Type header
! field. Depending upon the format and the capabilities of the user
! agent, selection of the most appropriate choice may be performed
! automatically. However, this specification does not define any
! standard -format- for such automatic selection."
! Roy's requirements on 300 and 406 in general look exactly correct
! to me, so that an entity can be returned to a dumb client that does
! not do content negotiation, while smart clients can use Alternates
! and not bother the user.  In fact, to have a chance of deploying
! any sort of content negotiation, the requirement to send and entity
! back (probably in text/html) that allows the end user to
! select the representation desired, is needed.  Without these
! requirements, end users using old browsers (not supporting content
! negotiation) would not even be able to fetch the negotiated
! documents at all.  So I conclude the 03 draft is badly broken without
! the requirements on 300 and 406.

> other than
>requiring Vary to be sent even when Alternates is present (which is
>the right thing to do anyway and only costs a few bytes).

You may think this is the right thing to do.  Both Daniel DuBois and
I have already expressed contrary opinions.

! and the larger group of us last week agreed that the 7 bytes to say
! "Vary:*" would not be too much.

>> Technically, this overspecification is unnecessary.  Process-wise, this
>> overspecification is *utterly unacceptable*: the wg has consensus to
>> postpone the transparent content negotiation discussion until after 1.1
>> is finished, and to put only minimal `hooks' for transparent content
>> negotiation 1.1.  The overspecifications unnecessarily constrain the
>> outcome of the future content negotiation discussion.  Below, I will
>> indicate changed which remove all unacceptable overspecifications of the
>> content negotiation mechanism.
>"Hooks" meant a correct specification of existing practice, the Vary
>header field, and what it means when a cache receives Vary.
! see my comments above.  Without the 300 and 406 changes we do not have the
! hooks for later deployment; we're screwed without them.
"Hooks" never meant that. A reference:

 - There will be `hooks' in the 1.1 draft to ensure that all HTTP/1.1
 caches will be compatible, though not in an optimally efficient way,
 with a transparent content negotiation mechanisms like the mechanism
 defined in draft-holtman.  Thus, transparent content negotiation
 (which is what Section 12 of the old 1.1 draft covered incompletely)
 won't have to wait for HTTP/1.2 if HTTP/1.2 turns out to take too
 long, it can be done on top of HTTP/1.1. 

>  Draft 03
>incorrectly describes the consensus on Vary and contradicts all existing
>implementations of negotiation (CERN, Apache, and Spyglass servers)
>regarding the negotiation of error responses.

Draft 03, nor the content negotiation subgroup, intend the term
`content negotiation' to cover _all_ kinds of dynamic response
generation.  Draft-03 says:

 negotiation is the process of selecting the best representation when a
 GET or HEAD request is made on the generic resource.
 (section 15)
! and the definition in 03 was also broken.  For example, GET or HEAD
! are clearly not the only methods which might apply.

 origin server need not be capable of selecting an entity for every
 possible incoming request on a generic resource; it can choose to
 generate a 3xx (redirection) or 4xx (client error) type response for
 some requests.
 (section 18.46)

In no way does draft-03, nor the consensus of the content negotiation
subgroup, prevent servers from dynamically generating error messages
in an appropriate language -- such generation is just not called
`content negotiation'.
! If it were just a few error messages, I wouldn't complain.  But
! HTTP often returns entities (more than a simple string) to users
! to explain something.  There is NO need to make the distinction (and
! in terms of generality, I would argue it is a bad idea, to distinguish
! between entities returned from a resource (variants) and entities
! elsewhere in the protocol.
! I think Roy is right.  Entities in general get negotiated...

Your claims that draft-03 prevents dynamic selection of error messages
are incorrect.  They seem to be the result of first making a private,
much broader definitions of the term `content negotiation', and then
reading the language in the spec with this definition in mind.  It is
no surprise that the language in the spec would mean the wrong thing
under another definition.  However, this does not in any way imply
that the mechanisms as defined in the spec are wrong.  Most of your
comments about the incorrectness of the text in the 03 spec can be
traced back to use of a private, faulty, definition of `content
! Roy is not the only person to believe our terminology, and definitions
! have been broken.  That is why we've been sweating blood over them.
! The draft I'll make available later today is alot closer to correct;
! 03 was still pretty badly broken.
If you want the term `content negotiation' to be used in a broader
sense than it is used now in the 03 spec, by all means say so.  I'm
open for terminology discussions.

>If this is truly what the conneg subgroup intended, then the conneg
>subgroup failed.  However, having just read the mailing list archive
>at <>, I can tell
>you quite frankly that your interpretation of conneg consensus on these
>issues is bogus -- you just didn't make the right changes to draft 01.

I disagree.  If I was as wrong as you say I am, someone in the wg
would have spoken up when I posted the various pieces of my text on
the mailing list.
! People are busy, just as I'm too busy to generally read messages as long
! as this one.  Silence DOES NOT imply consent in this kind of forum.
! It implies consent in face-to-face meetings, but not on a mailing
! list.  And you have a tendency to write very long messages that
! make it difficult for people to wade though to find the meat of them.
>The fact that it has taken so long for me to propose these changes is
>because I have been extremely busy with ALL aspects of the protocol,
>and this part wasn't my responsibility any more.  That does not mean
>that is okay to go forward with a description that is clearly wrong.

The description is not clearly wrong.  It may be complex, it may use
terminology you do not like, but the mechanism described is correct,
is compatible with existing practice, and can be implemented.

You proposed changes fall into a number of categories

a) simplifications by cutting features
   example: eliminating variant-ids  

   These I am prepared to consider

b) edits which do not change the mechanisms defined by the protocol

   These I am prepared to consider.

c) changing an (extensible) mechanism into an equivalent mechanism
   with another syntax
   example: change of the Vary header syntax

   I'm not willing to accept, at this stage of the game, gratuitous
   changes without _very_ convincing arguments, arguments much more
   convincing than I have heard so far.  It is too late to needlessly
   twiddle syntax and move complexity around.  We are past the syntax
   twiddling stage, by waiting this long to make your comments, you
   have lost the right to make the syntax look nicer in your eyes.
! Roy is not the only person who has complained about HTTP/1.1 getting
! too complicated.  Vary, for something so simple, was very complex
! in the 03 draft (both BNF and in wording).  This is ok, for a draft, but 
! simplicity is worth working hard for.  This should be as simple
! as possible, and no simpler.

d) introduction of new mechanisms

   Not acceptable at this stage of the game without _very_ convincing
! I've seen nothing that involves introducing new mechanisms.  Entities
! are often returned in the protocol.  I've seen removal of unneeded
! mechanisms, when we've figured out ways to do things better/simpler.

e) changes which break the spec

   No comment

>>>  Some of the extensible aspects of the Vary header have been
>>>removed because it was clearly impossible for any such extensions
>>>to be deployed without breaking Vary (and thus they would be better
>>>done via a separate header field anyway).
>> As far as I know, the extension stuff in the draft-03 Vary header
>> section is *not* broken.  Please back up this `clearly impossible to
>> deploy' claim.  I can live with the extension stuff going, but the only
>> valid reason I see for removing it is the desire to reduce complexity.
>See prior message.

Your prior message makes it clear that you to not like the syntax of
the extension mechanism, but does not contain any explanation of why
it would not work.  In fact, your comment

>We gain the exact same
>extensibility via a separate field, e.g.
>    Vary: "*"
>    My-extension: fred
>where My-extension is defined as modifying the semantics of Vary.

implies that the mechanism is not broken at all (at least not more
broken than your proposed replacement).
Your counter-proposal just moves complexity around, and even does so
in a particularly yucky way (My-extension is defined as modifying the
semantics of Vary? Bleah!).  As I said above, I am not prepared to
accept such twiddles if the only justification is that you like your
syntax better.

! It means that HTTP/1.1 implementers don't have to parse yet
! another complicated BNF in the Vary header; they only
! have to deal with complexity when/if they need to deal with it, rather than
! making 1.1 harder to deal with.

>>>The editorial group has
>>>also decided that caches can be almost always as efficient, and much
>>>simpler, without variant-ids.
>> Ugh.  _The members of the editorial group who met last week_ may have
>> decided that, but I have not.  My opinion is that removal of
>> variant-ids will make caches less efficient and more complex.  I could
>> live with variant-ids being removed, but do not agree with your claim
>> that this makes caches simpler.
>The editorial group (those people doing the editing of the draft) agreed
>to the change -- it was not a unanimous decision.  

As far as I know, I am in the editorial group (I coined the term
`editorial group', so I should know).  I was not consulted on this

! You were sitting there in Paris when we met and discussed this.
! I do not remember objections.  I do not understand how you can
! claim you were not consulted on this decision.  At the time,
! we left it for people to go off and think about, to see if there
! were any problems we could not see at the time.

>In actuality, the
>agreement was that it should not have been added in the first place.

[This is all I have time for today.  I must say that I do not envy Jim
Gettys for the position this discussion is putting him in.  Jim, I
advise you not to wait with releasing a draft until Roy and I agree.
I think the best solution at this point is to mark some parts as of
the draft as controversial.]
! People might comment more on your messages if you kept them shorter
! and to the point.
! My opinion is that this draft is conceivably going to be submitted
! to the IESG, and statements about controversy, particularly when it
! has been primarily from a single individual rather than the group at large,
! do not belong in a document at this stage.
!				- Jim

------- End of Forwarded Message

Received on Tuesday, 28 May 1996 15:43:00 UTC