Re: Content negotiation requirements

Graham Klyne:
>
>On further reflection about the issues of content negotiation, I am coming
>to think that there should be two (mainly) orthogonal issues here which
>could be dealt with by separate statements of requirements (in either
>common or separate requirement document[s]):
>
>(1) Negotiation framework and metadata requirements which address the broad
>goals of negotiation in a protocol-independent fashion.
>
>(2) Specific requirements which relate to negotiation issues specific to
>operating in an HTTP context (e.g. relation to HTTP protocol operations,
>cache interactions, security issues, existing HTTP negotiation mechanisms,
>application to variant selection, etc.).
>
>My thoughts are prvoked in part by my reading of the Koen Holtman (et al)
>negotiation draft:  he has clearly trying to separate protocol-dependent
>issues from protocol-independent issues but I feel that the negotiation
>metadata structures are still very much oriented to HTTP operations
>(unnecessarily so, IMO).

If I understood your latest set of comments to the TCN draft right (I
am still working on writing a complete reply to these, and will send
it later), you seem to prefer a negotiation protocol which has
symmetric metadata, i.e. the metadata at the sender side has the same
format as the metadata at the recipient side.

TCN is very asymmetric with respec to metadata: you have variant lists
at the sender side and feature sets at the recipient side.  However,
there are good reasons for these formats being asymmetric.  They are
not asymmetric because of insufficient separation from HTTP.

In TCN, negotiation is not really between two machines, it is between
a human being, a content author who writes a variant list, and a
simple machine (web browser).  Intelligence-wise, this relation is
asymmetric (at least with the current state of browser technology).
It should therefore not be surprising that both parties have different
kinds of information to contribute to the choice process, and this is
reflected in the asymmetry of the metadata formats.

In other types of negotiation, where two machines are involved, a
symmetric metadata format may be a nice win, but not so in TCN.  In
TCN, it would just add to the complexity of defining the choice
process.

One could conceivably create a very general negotiation framework in
which both human-machine and machine-machine negotiation can be done
nicely.  However, I do not have very high hopes that such a framework
could be created soon, or that it would be simple.

I would therefore not be in favour of a `universal negotiation
framework' programme which would try to be applicable to both
author-machine negotiation (as in web content negotiation, or
selection of a part from multipart e-mail, or conditional HTML) and
machine-machine negotiation (as in fax or telnet option negotiation).

On a related note, transport level simplicity considerations can be a
very dangerous guide when designing a negotiation mechanism.  Case in
point: though the WILL/WONT/DO/DONT transport primitives in telnet
option negotiation are simple and symmetric, actually using them to
reach a decision turns out to be extremely difficult.  A separate RFC
(RFC1143) was needed to fix the mistakes in the usage guidelines of
the original specification.  RFC1143 is very instructive reading if
you are considering negotiation between two machines.

>GK.

Koen.

Received on Friday, 4 July 1997 11:17:52 UTC