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

> The lookup problem bothers me, because I believe there will be
> relatively few cases where the hash as given would be instantly
> recognizable (since it includes both features and feature values).

   (SONY_VGA_MODELXXX) :-
      (| (& (pix-x=640)
            (pix-y=280)
            (color=256))
         (& (pix-x=1028)
            (pix-y=1028)
            (color=256)))
is equivalent in this regard to
   (fh=1aXb124AsDfg) :-
       (| (& (pix-x=640) ...)

i.e., there's a value that expands to other values, that you
either know or have to look up. The advantage of "fh" is that
if Sony's VGA display's features are the same as NEC's, you
don't need to keep both in the table.
 
> In the case of user agent features, some of the hashes could be
> pre-loaded into appropriate places, but it is not clear how effective
> that would be. 

As effective as any other 'preloaded features'.

> Bill's examples seem to indicate that the number will
> be significantly above zero for some caches, but I remain convinced
> that the number of cases where it is not obvious will be a large
> portion of the total.
> 
> So the question for the "fh" possibility is: how and when do we allow
> for the hash to be disaggregated?

Yes, but it's not so different for any of the other proposals
for aggregated feature.

> I suppose we can create a feature that is, in fact, a request for fh
> to be disaggregated.  

I think that's mixing descriptive information and protocol in
an unfortunate way. I think disaggregation is likely to be
protocol dependent, even though the semantics of "fh" is
protocol independent.

> So fhmiss=31aAfXz1234 would be a request that
> the value of 31aAfXz1234 be disaggregated.  

Besides, your transmission is in the wrong way:

sender   <------ capabilities -------------  message recipient
         --- request for disaggregation -->  (capability expander)
         <------ capabilities expansion ---  (capability expander)
         ----------  data ---------------->  message recipient

The sender GETs capabilities (from the recipient or from
a directory describing the recipient).
If the sender requires an expansion, it has to ask the recipient,
the directory, or a service that the recipient or directory have
delegated to.

The request for expansion can't piggyback on top of a capabilities
expression since the request doesn't flow in the same direction
as capabilities themselves.

In HTTP, a 'capability expansion request' might come as
an HTTP error response.

If capabilities are in a directory, then a directory attribute
might point to a capability expansion service.

Alternatively, a capability expression that includes
a feature hash might come with the URL of the service
that is willing to expand the hash. This is similar to
the proposal that you send along a URL as well as
a hash, but turning it upside down.

Larry