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).  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.  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?

I suppose we can create a feature that is, in fact, a request for fh
to be disaggregated.  So fhmiss=31aAfXz1234 would be a request that
the value of 31aAfXz1234 be disaggregated.  

Along those lines, some special value to indicate that you should
never send this device a hash could be created so that devices that
couldn't handle them could be sure to avoid them (fhmiss=ALL).

Even with that, I believe we would need to come up with some way of
sending the full set along with the hash thus created.  Perhaps a
better way to do this would be to reserve h. as a prefix and then
use


h.HASH=Yes (To indicate that feature grouping is in use)
h.HASH=No (To indicate that the hash was not understood and the disaggregated
         expression is needed)
h.HASH=Disaggregated expression (To pass the full meaning)
h.none=Yes (To indicate that no HASHes will be understood).


Any thoughts on that?
			Ted Hardie








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