W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: Content negotiation requirements

From: Graham Klyne <GK@acm.org>
Date: Mon, 07 Jul 1997 12:41:05 +0100
Message-Id: <>
To: Koen Holtman <koen@win.tue.nl>
Cc: hardie@thornhill.arc.nasa.gov, http-wg@cuckoo.hpl.hp.com
At 08:15 PM 7/4/97 +0200, Koen Holtman wrote:
>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.

Yes.  Mainly because I believe it will ultimately yield a simpler solution

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

This suggests that the assymmetry *is* caused by the relationship to HTTP.
Not specifically the HTTP protocol, but the browsing application which HTTP

>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

I'm not convinced.  But I can see I must produce some more concrete
evidence for my view -- I'll think about it (it may take a while).  (See
also later comments.)

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

It may be that we are talking very slightly at cross-purposes here.

I would aim for a symmetric negotiation metadata format, but *not
necessarily* symmetric transport protocol features to conduct the
negotiation.  In the case of HTTP and your comments about complexity of the
choice process, I think the appropriate simplifying constraints could be
enforced by the way in which the transport handles the negotiation (in
effect, implementing a subset of the generic negotiation framework
sufficient to the purpose at hand).

Question:  if I could offer (a) a generic framework and metadata format,
and (b) indicate how these might be subsetted to current HTTP/TCN
capabilities, would you consider that this would address your concerns?
(NOTE: I am NOT proposing to re-design TCN or any part of HTTP!)


Graham Klyne
Received on Monday, 7 July 1997 04:45:35 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:46 EDT