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

Roy T. Fielding:
>
>Koen writes:
>
>> Perhaps paradoxically, though the diffs below simplify many aspects of
>> the protocol, they also add language which _overspecifies_ the future
>> transparent content negotiation mechanism, and which sometimes
>> directly contradicts things the content negotiation subgroup has
>> consensus on.
>
>I checked my diffs, and then read the entire conneg mailing list
>again article-by-article, 

There are over 150 articles in the conneg archive, and some of them
are very long.  I find it hard to believe that you read all of them
again.

>and neither statement is true.

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.

>  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.

> 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.

>> 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.

"Hooks" never meant that. A reference:
http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q2/0022.html
says:

 - 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:

 Content
 negotiation is the process of selecting the best representation when a
 GET or HEAD request is made on the generic resource.
 (section 15)

and

 An
 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'.

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
negotiation'.

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 <http://www.organic.com/public/conneg/mail/date.html>, 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.

>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.

d) introduction of new mechanisms

   Not acceptable at this stage of the game without _very_ convincing
   arguments.

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.


>>>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
decision.

>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.]

Koen.

Received on Tuesday, 28 May 1996 22:34:51 UTC