Re: Accept-Charset support

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

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

At least then others would have some test cases.

Larry

Received on Saturday, 7 December 1996 17:43:28 UTC