"Constant feature sets"

First, my apologies for the delay in commenting on the work Bill and
Graham have put forward; second, my thanks to both of them for taking
on the hardest problem this group has left to solve.

Having named it hard, I would like to take a crack at defining the
problem and discussing what methods there are for solving it.  (In
the text below, I use the term "grouping" to talk about features
which are associated with each other, but do not fully describe
the features of a resource or the capabilities of a device.  It's
not a particularly great phrase, and replacement suggestions are
welcome).


The Problem:

When there are multiple, static representations of a particular
resource, the features which describe the differences between the
representations are bounded and the method by which the resources can
be distinguished are pretty clear.  In our current architecture the
method for doing so requires, however, that the features which do not
distinguish between them be repeated in every group.  This means that
a representation which can be printed on a4 paper, in 16 shades of
grey, using postscript level 2, using a times-roman 12 point font must
be distinguished from a representation which can be printed on
na-letter, in 16 shades of grey, using postscript level 2, using
courier 12 point font.  (Note, by the way, that the groupings in the
example imply that you can fit things on to na-letter only by changing
fonts; you cannot simply vary both the paper and the font).  The
constant features cannot be left out, because the devices need to
compare their capabilities against them, but the waste of repeating
them goes up enormously with the number of representations; with
dynamic representations, this gets even worse.  Having some way to
reference the constant features without repeating them would obviously
be a win.  

The same is true on the flip side; there are a lot capabilities within
devices, most of them constant.  Having some way to reference the
constant set without repeating them is also a big win, especially
where bandwidth is low.


The Example in many of our minds:

In HTTP, sending a full set of Accept-* headers got to be so wasteful
that many devices stopped using that method for negotiation and
shifted to User-Agent or other methods (this was, of course, only part
of the problem, and a full treatment would include the "Accept */*"
problem and other things).  In a sense, User-Agent became a feature
grouping identifier; it wasn't a good one, though, because it often
either implied capabilities which had been disabled or did not include
extensions.



Possibilities:

As Bill and the CCPP work implies, you can use a URI that points to a
constant grouping.  That URI can be used as a token, for situations in
which both negotiating parties understand the feature grouping it
implies.  The URI token will not, sadly, be known to both parties in
all situations.  If the URI gives a pointer to a location with a
canonical representation of the features it implies, chances of
success go up, but it will not always be possible to retrieve the
representation and disaggregate the features.  (Both for the case in
which a device cannot use the URI scheme and for the case in which the
canonical representation of the resource is not available).  A
traditional URI won't help in the "multiple inclusion" aspect of the
problem, because you need to assign the groupings dynamically.  We
could steal the work of the mhtml work and assign an "internal" URI to
the set of constant items as part of the message, then use that
identifier as an internal reference.

The primary problem with the URI method is update; it requires systems
to constantly keep up with new URIs, some of which will represent the
same constellation of features.  On the cell phone side, for example,
Qualcomm dhas branded the phone I have with 5 different company names
that I am aware of, and I would bet each would require references to
*their* URI space.

Several folks have implied that we could use hashes of features rather
than pointers to feature groupings.  I can certainly see that working
in the "multiple representation" side, but I am not sure about the
external reference side.  Any proponents willing to speak out?

Any other possible solutions that scale to the extent we need?

			regards,
				Ted Hardie
				[email protected]