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

Re: Accept-Charset support

From: Larry Masinter <masinter@parc.xerox.com>
Date: Sat, 7 Dec 1996 14:43:29 PST
To: kweide@tezcat.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, www-international@w3.org
Message-Id: <96Dec7.144329pst."2694"@golden.parc.xerox.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2041
It's important to look at content negotiation from the point of view
of the content PROVIDERS, and then design the protocol so that clients
can ask for things that providers are willing to provide. In general,
it does us no good to let clients ask for things that information
sources aren't really willing to deal with anyway.

In general, content is available in one language and one charset and
non-negotiation, and in general, this is a good idea. Sometimes,
if content is negotiable, content providers might want to provide a
FEW alternatives, but not many, and certainly not lots of

Given this situation, "expressivity of desires", although nice in the
abstract, doesn't really do us much good, if the desires we're
expressing aren't really things that are variable. So, while 'feature
negotiation' might include things like 'screen size', it's hard to
imagine a content provider doing anything USEFUL with the factoid that
'this client can render latin42 characters encoded with UTF8' in
comparison with a client that doesn't say anything like that.

Perhaps one of the requirements for 'feature registration' should be a
that the registration form contain N different URLs where the content
actually differs depending on whether the feature is or is not

At least then others would have some test cases.

Received on Saturday, 7 December 1996 14:49:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:18 UTC