- From: Koen Holtman <koen@win.tue.nl>
- Date: Tue, 6 Feb 1996 14:38:00 +0100 (MET)
- To: mogul@pa.dec.com (Jeffrey Mogul)
- Cc: http-caching@pa.dec.com
Jeffrey Mogul: [...] >Consider a single resource with multiple variants (e.g., a document that >has been translated into several dozen languages). Consider a proxy which >already has several variants in its cache (for concreteness, let's >say it has three such variants: English, French, and German). Let's >also assume that the server sent "Vary: Accept-Language" because it >didn't want to encode all of the possible variants in a URI: header. I find this a strange assumption: I can't think of any frequently occurring cases where the server does not want to encode the available variants in an URI header. (See my `New content negotiation sections' text at http://weeble.lut.ac.uk/lists/http-caching/0241.html for a definition, with examples, of the kind of URI header I mean.) In my opinion, it makes little sense to include a variant-ID/variant-set mechanism in HTTP unless we can find some frequently occurring case where the server does not want to use the URI header. We would just be duplicating the `variant-if-modified-since' mechanism of URI content negotiation with no good reason. Can you think of a frequently occurring case? [....] >The server goes through its normal content-negotiation algorithm >to decide which variant to return Ugh. Please do not use the term `normal content-negotiation algorithm' when referring to an algorithm that selects a variant response. We will get very nasty terminology clashes. May I suggest the terms `variant computation' and `variant response' as counterparts to the terms `content negotiation' and `variant resource' in the `New content negotiation sections' text at http://weeble.lut.ac.uk/lists/http-caching/0241.html ? (Hm, maybe the description of content negotiation with URI headers sould not use `variant' but another term. `Version' doesn't work. Alternative? Representation?) >-Jeff Koen.
Received on Tuesday, 6 February 1996 14:04:31 UTC