W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Content negotiation status

From: Koen Holtman <koen@win.tue.nl>
Date: Mon, 18 Mar 1996 23:26:55 +0100 (MET)
Message-Id: <199603182226.XAA10649@wsooti04.win.tue.nl>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Cc: Koen Holtman <koen@win.tue.nl>

As input to discussions (either on this list or in future phone
conferences), here is my personal view of the status of the various
content negotiation issues.  We will have to decide on how much
content negotiation to put in the HTTP/1.1 draft fairly soon; see the
end of my message for a proposal.

1. Status of the content negotiation discussion

The content negotiation subgroups and caching subgroups have consensus
on many aspects of content negotiation.  There is text for the 1.1
draft in draft-holtman-http-negotiation-00.txt, this text captures
many of the points there is consensus on, but also adds some new
elements not previously discussed that were necessary to get a
complete mechanism.

Some people in the http-wg have reviewed
draft-holtman-http-negotiation-00.txt and posted comments, but many
have not.  I have the impression that this absence of discussion does
not indicate consensus, but a lack of review.

draft-holtman-http-negotiation-00.txt is a complicated text.  It is
unknown whether those people who have not yet reviewed draft-holtman
would agree to it being incorporated into 1.1.

Roy has said that content negotiation text in the current 1.1 draft is
no longer his current proposal for content negotiation.

2. Long term goals for content negotiation

The content negotiation subgroup has consensus on the following scheme
for content negotiation.  This is what we want to be supported in the
long term.

   Resources can be 

     1) un-negotiated: there is only one version of the content

     2) negotiable as in draft-holtman-http-negotiation-00.txt,
        the Alternates header specifies all available alternates,
        the user agent allows the user to select another alternate if

     3) negotiable with a Vary header.  The origin server has multiple
        variants, and selects one based on, for example, the contents
        of the user-agent header in the request.  There is no standard
        mechanism to allow the user to select other variants.

   Type 3 is to be used in cases where use of type 2 is not possible
   for some reason.

In the long term, content negotiation must allow for

   - negotiation on mime type, charset, and language
   - small accept headers
   - feature negotiation
   - near-optimal caching

3. draft-holtman-http-negotiation-00.txt

My current proposal for content negotiation consists of draft-holtman
with the following changes:

 - the Rep-Header mechanism is removed and replaced by a
   content-ID/Unless-ID mechanism, according to emerging consensus in
   the caching discussion.

 - negotiation on Content-Encoding is moved outside the main
   negotiation mechanism.  This allows proxies and server to encode
   and decode (zip and unzip) relayed content on the fly, depending on
   the capabilities of the next client in the chain.

 - the origin server restriction is weakened to `the alternate URI up
   to its last slash must be equal to the negotiable resource URI up
   to its last slash'.  Text is added to make the scope of this
   restriction more clear.

 - the following rule is added to make future addition of more
   negotiation dimensions smoother: `Proxies should not engage in
   alternate selection calculations on behalf of the origin server if
   an unrecognized attribute is present in the Alternates header.'

 - the charset all browsers are supposed to be able to handle may be
   changed to from US-ASCII to ISO-8859-1, if the http-wg has
   consensus about this change.

 - the `mxb' stuff may be taken out to simplify things

I believe draft-holtman to be technically mature.  Given the large
requirements on content negotiation (must be downwards compatible,
must be completely optional, must allow small Accept headers, must
allow a large number of supported MIME types, must work optimally with
caches, must be extensible, must be as fast as possible, must be
secure, must protect privacy, ...), I do not believe that the
negotiation text can be made much simpler.

The main problem with the text is acceptance.  Unlike some other http
internet drafts currently under review, draft-holtman completely
defines all aspects of negotiation and its interaction with other http
features.  This completeness may paradoxically delay acceptance rather
than speed it up.

4. Proposal

I propose to put `docking rings' for content negotiation in the 1.1
draft of April 1.  I will release a new content negotiation internet
draft at the same time.  This new draft will also define the Vary

The docking rings consist of text that adds requirements to 1.1 to
ensure that 1.1 caches

  - can interoperate with content negotiation as defined in a 
    future separate standards document or in HTTP/1.2.
  - can cache such negotiation with a reasonable efficiency.

In other words, the docking rings put in the foundations on which a
future content negotiation mechanism can be built, allowing a smooth
transition to negotiation-capable software.

The docking rings will allow for negotiation by origin server side
algorithms in 1.1, for example on negotiation on language.  1.1
proxies will have to contact the origin server whenever getting a
request on such a 1.1 server-negotiated resource, and can then get a
short response saying `return the entity X you have cached'.

To allow for origin server side negotiation, short descriptions of the
various Accept-* headers will be included in the draft.

I am confident that I can make docking ring text that satisfies the
above requirements.  Note that this text _will_ make 1.1 proxies a bit
harder to implement.  This is the price we pay for laying foundations.

This proposal allows us to delay consensus on the April 1 content
negotiation draft until after May 1, when we must have consensus on
the core 1.1 draft.  If we have consensus on content negotiation
before May 1, drafts can of course be merged.

Received on Monday, 18 March 1996 14:34:48 EST

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