- From: Koen Holtman <koen@win.tue.nl>
- Date: Mon, 18 Mar 1996 23:26:55 +0100 (MET)
- 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 desired. 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 header. 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. Koen.
Received on Monday, 18 March 1996 14:34:48 UTC