Feature set registration scenarios

All,

This message is a call for ideas...

Exchanges between myself and Bill Newman suggest to me that we're still
trying to define the problem to be solved.  In best IETF tradition, how
about some scenarios?


I can think of three offhand:

(1) [per W3C CC/PP paper] providing a shorthand mechanism to capture the
common characteristics of some identifiable device or system, which may
then be augmented by additional information.  If such a feature set is
considered an appropriate unit for caching, this can reduce the need to
transfer *all* characteristics, only those that are different from some
baseline set.

(2) [per <draft-ietf-fax-feature-schema-05>, Appendix B] providing a means
to indicate standard feature sets.

(3) [see below] providing an expression of corporate policy with respect to
media capabilities.


What are the motivations for using such feature sets, rather than the
corresponding capability expression?  I suggest:

(a) reducing the size of capability expressions:  bandwidth saving, etc.

(b) allowing access to feature set definitions that may be introduced after
an application is deployed.

(c) allowing access to feature set definitions that may change over time
(e.g. the standard fax receiving capability for ACME corporation?).


This prompts another question:  what is the role here for *registration* of
feature set definitions vs the role for some kind of online *access* to
machine-readable feature set definitions?

#g

------------
Graham Klyne
([email protected])