RE: Ted's concerns about wastefulness (Accept-* problem)

Suppose we defined a feature called 'fh'. The 'fh' feature
consists of the hash of a feature set. That is:

  a) take a feature set string (as in
    draft-ietf-conneg-feature-syntax)
  b) compute the MD5 hash of the feature set string,
     and represent the result as a string using base64
     encoding, as described in RFC1864, but eliding
     the trailing "==".

The 'fh' feature stands for a full feature set. It can
be combined in booleans, and fully substituted.

You could say

 Media-Accept-features: (& (fh=1ab123342341h) (pix-x<512))

or 

 Media-Accept-features: fh=31aAfXz1234

This doesn't 'waste bandwidth' because it is a very compact
and yet secure representation of what is otherwise a complex
and lengthy feature set.

On the other hand, it does leave the problem of interpretation:
it must be possible to ask someone (e.g., the sender) of a 'fh'
feature to supply the actual feature set for which the proffered
'fh' is the hash.

I could imagine doing this in HTTP using a new error code,
for example, or by adding ANOTHER header which contains the
URL of a 'fh' resolver which might be able to expand proffered
feature hashes. 

In the main case, however -- all interactions after the first,
or interactions where the content doesn't actually depend on
the recipient features -- the extra transmission bandwidth
is small.

Larry