Re: content negotiation flap (resend)

jg@w3.org:
>
>        Please be aware that as far as I can tell, there is only a few
>items in the Content Negotiation chapter (15 in draft 03) as rewritten
>by Roy that are normative (i.e. use the words MAY, SHOULD, MUST), and
>therefore constrain any future course of action for the content
>negotiation facilities.

I am aware of that.  Most normative things I object to are outside of
Roy's new content negotiation chapter, for example in the 300 and 406
status code definitions.

[...]

>        Complete silence, as you suggest by deleting the section Roy
>wrote on Transparent negotiation, while clearly leaving things
>completely open, also leaves the specification open to attack by those
>who then don't understand why base facilities exist as they do. 

Please understand that an explanation of transparent
(alternates-based) content negotiation is _not_ needed to justify the
presence of the Vary and If-None-match headers.  The possibility to do
opaque negotiation (what is called server-driven negotiation in Roy's
text) under plain 1.1 offers enough justification for these features.

Only the Alternates header and the reserving of the 300 code for
future use in the 1.1-03 draft would need a justification based on the
existence of a planned transparent negotiation mechanism.  As these
two things add no complexity in implementations beyond the complexity
already required to support the Vary header, there is no real need to
include long motivations for these features in the 1.1 draft.  A
mention of planned extensions will do, and this is all what is in the
03 draft.

In Roy's text, which eliminates all normative requirements for the
Alternates header, the need for such explanations is even smaller.  As
a side remark: I could live with Roy's elimination of the Alternates
header being an alias for Vary: {accept-headers}, but I would prefer
keeping it because this will mean less bytes over the wire half a year
from now.

> I am
>very sensitive to John Klensin's criticism of draft 02 as it looked as
>though the design was by committee, rather than there actually being
>two real ways for content negotiation to work.  Without some
>understandable explanation, we're in for trouble in review outside the
>working group, and we must address this kind of criticism.

If you really feel a strong need to include motivations touching on
transparent negotiation for outside reviewers, put these motivations
in an appendix, so that they cannot constrain the future content
negotiation discussion.  

I myself am very sensitive to the risk that last-minute editorial
changes which introduce new normative requirements or claims, or
change existing normative requirements, rather than just deleting
requirements, could cause someone who disagrees with these changes to
delay the acceptance of the draft.

An editorial group introducing last minute changes has to be very
careful not to cross a line at which people can start accusing editors
of trying to sneak their pet mechanisms into the draft just before the
consensus deadline.  In my mind, some parts of Roy's diffs already
cross this line.  I don't use the words `utterly unacceptable' for no
good reason.

If you really want to include long explanations of how transparent
negotiation is going to work, put them in an appendix, where they are
guaranteed to be non-normative.

>        The only paragraph in Roy's version in the section on transparent
>negotiation that is normative is:
>
>"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."

As plain 1.1 does not define any way for a cache to perform
transparent negotiation, this requirement does not belong in the 1.1
draft.  The requirements with respect to the Vary header made for all
caches are already sufficient to allow transparent negotiation on top
of 1.1.

[...]
>                        - Jim

Koen.

Received on Monday, 27 May 1996 12:42:53 UTC