Re: Color content negotiation

Harald.T.Alvestrand@uninett.no:
>I'm beginning to think that the problem of matching UA capabilities to
>available formats is a problem that needs to be addressed outside the
>HTTP spec.

I'm beginning to think this too.  The way I see it, there are two
subproblems in content negotiation:

 1) what to negotiate on (MIME type? charset? language? response
    length?  color?  screenwidth?  maximum allowed cuteness of inline
    images?  all of the above?)

 2) how to implement the negotiation in the HTTP protocol (do it
    at the server side, at the client side, allow both, what are the
    headers, ...)

In my opinion, it would, to a large extent, be possible to disentangle
1) and 2).  The spec already has some disentanglement in the area of
MIME types, but it could provide more, e.g. by replacing the headers

  Accept-Charset, Accept-Encoding, Accept-Language

and possible future

  Accept-Color, Accept-Screenwidth, Accept-Cuteness

headers by a more general

  Accept-Parameter

mechanism, as suggested by Larry Masinter.

More disentanglement would be a good idea, because the http-wg is not
necessarily the right group to decide whether to negotiate on cuteness
or not: we can leave this to the browser authors, browser users, and
service providers.

In other words: subproblem 1), thinking up things to negotiate on, is
not a technical subproblem, but a social one, it should therefore not
solved by http-wg, but by the entire web community.  

However, the solution space for 1 is determined by http-wg, because
http-wg solves subproblem 2.  Thus, http-wg should try to determine
which solution space is wanted, e.g. by asking on www-talk.

>I believe we would be well served by trying to write down what it makes
>sense to say about UA capabilities, what a content sender should do when
>it knows the UA capabilities, and what possible formats exist for expressing
>those capabilities.

Yes.  I don't think we need to have a complete list of capabilities
before we can start solving our subproblem 2.  A set of representative
examples of what people _may_ want content negotiation for would be
good enough to determine the solution space wanted for 1, and that is
all we need.

>When we have that, it makes sense to talk about how to move this info
>in an HTTP transaction.

Yes.  Though I don't think we will need to redesign HTTP content
negotiation from scratch: the current negotiation stuff in the spec is
a good starting point.

>Now - is the right place to hash it out on this list, create a new WG, or
>to do something else?

I think www-talk would be the best place to get a list of examples
that would generalize into a set solution space requirements.  Service
providers probably know best what kinds of negotiation would be
needed: they are the ones who notice it when the protocol does not
provide a mechanism for something that needs doing.  It was my
experience as a service provider that made me propose color content
negotiation.

Having made such a list of examples on www-talk, we could develop the
HTTP mechanisms (solve subproblem 2) on http-wg.


Subproblem 1, deciding what things to negotiate on, does not need to
be solved in one go by a spec workgroup, this could be an ongoing
process done in a decentralized way by individual browser authors,
users, and service providers.

The only thing that needs to be centralized is the registration of
negotiation identifiers.  There should be one, central, heavily
annotated list like this:

  dimension     values                            match method
  ----------+----------------------------------+------------------------
   encoding      gzip, compress                    exact match
   language      en, en-US, en-cockney, ...        initial portion match
   charset       iso-8859-5, unicode-1-1, ...      exact match
   color         monochrome, 8bit-color, ...       exact match
   cuteness      none, pets, ewoks, smurfs, all    exact match
   version       <integer>(.<integer>)*            exact match (?)
   max-colors    <max_number_of_colors>            matches if less than
   max-width     <number_of_pixels>                matches if less than
   ....

Note that this list is orthogonal to the list of MIME types.  In fact,
one could add a dimension

   mime-type     text/html, image/gif,  ...        wildcard match

to the list.

Valid questions are:
  is it best to put the above list in the HTTP spec document?
      (I think it would be best to separate it, this allows for
       faster updates of the list. The http spec could contain
       relevant portions (e.g. the stuff about the encoding dimension)
       in an appendix however.)
  who should maintain this list?  Who decides whether a new dimension
  is added?
  who should maintain the collection of allowed values for each
  dimension?
      For the language dimension, it would be IANA.
      For encoding, it could be http-wg.  
      By default, it could be the wg maintaining the whole list.

Note that this question on who maintains the list belongs to
subproblem 1, not 2.  As a bootstrap measure, however, http-wg would
have to be the author of the first version.

The design of the list format belongs to subproblem 2.  We could, for
example, make a list format rule that any dimension beginning with
`max-' and `x-max-' is an integer dimension with the `matches if less
than' match method.  Such a rule would make `navigating the solution
space' of subproblem 1 much easier: new max- headers could be
introduced painlessly, without any need to modify servers or clients.

>             Harald A

Koen.

Received on Saturday, 9 September 1995 08:26:46 UTC