Re: More thoughts on content negotiation

Graham Klyne:
>
>The following message was originally posted to the IETF-FAX discussion
>list, and is in some respects cast in terms more relevant to e-mail than
>HTTP, but touches on some issues which are under discussion here.

Hi Graham,

I think you have done a good job at identifying some of the important
issues.  In particular, I think that the following point you made
cannot be over-stressed:

>* The negotiation procedure should be defined as a clear process which
>leads to an unambiguous result.  (This will generally involve a full
>exchange of negotiable features before any data transfer is initiated.)
>The full negotiation process may be short-circuited by heuristics provided
>it can be shown that the end result is the same as would have been achieved
>by a full exchange.  This is the general approach adopted by Transparent
>Content Negotiation in [1].  The importance of this view is that the
>negotiation procedure and heuristics which optimise the data transfers
>performed can be dealt with as separate issues.

The HTTP-WG started out with a system (Accept- header based
negotiation) in which the negotiation procedure and the optimisation
mechanism were not clearly separated, and I think that the job of
disentangling these two issues slowed us down for at least a year.  It
took us a long time to see that, in order to have good efficiency, it
was *not* necessary to sacrifice any predictability or accuracy.

To any group defining a negotiation system, my advice would be to
proceed as follows: 

1) Temporarily forget about all optimisation mechanisms you have
thought up so far

2) Identify some examples of dimensions of negotiation, and define for
each dimension how negotiation in this dimension should be done,
without any regard to metadata transport or encoding issues.

3) Define a generalised negotiation algorithm which can at least
handle the cases identified in 2.  You may find that examples which
looked completely different in step 2 can nevertheless be generalised
under one single meta-mechanism.

Depending on what you want to do in step 4), you may not need to have
long discussions about whether the generalised algorithm you is the
absolute best one possible.

*Completely* define the following parts of the algorithm:

3.1) input: for every party which is involved in the negotiation
process, define the datatype(s) the party uses to express its
negotiation
parameters as input to the algorithm
3.2) output: define the datatype for the result of the algorithm
3.3) code: define how the algorithm transforms input into output, for
every possible input

Define everything without any regard to metadata transport or encoding
issues.

4) Identify which data types, and which parts of the complete
algorithm, need to be standardised, and which parts you can allow to
be implementation-dependent.  Note that HTTP transparent content
negotiation does not actually standardise any algorithm, only
datatypes and data type semantics, and that PEP standardises even less
in terms of semantics.

5) Determine in which place(s) the algorithm can best be run, and how
negotiation related data can be transported efficiently to these
places.  Consider if any of the mechanisms you forgot about in step 1)
can
be applied, and if any other mechanisms would be simpler or more
efficient.

Of course you may want to cycle through some steps of the above 5-step
scheme more than once, but in general it would be a mistake to pollute
an earlier step with considerations which belong in a step 5, unless
it is shown that such pollution is absolutely necessary to obtain an
efficient enough end result.

I think that it is crucial to do steps 2 and 3.  If these steps are
omitted, you may find out later that you standardised an efficient
metadata transport mechanism which does not define, or is incapable of
delivering, some crucial forms of metadata.  Such a mistake may be
very costly, because implementers will have no choice to make up for
the lost metadata by using heuristics, however unsuccessful they may
be, or by using inefficient extra transport mechanisms.

Both these costly things have happened in HTTP: we have
semi-successful User-Agent header matching as heuristics, and the
encoding of preferences in cookies as an inefficient extra transport
mechanism.

Koen.

Received on Saturday, 21 June 1997 04:45:37 UTC