Common feature sets (V2): scenarios, terminology, etc.

All,

Further to recent exchanges, here is an updated list of scenarios,
terminology and other key ideas that I offer for guiding discussion...

#g
--


Contents:
---------
(S) Scenarios
(T) Terminology
(G) Motivations and goals
(R) Candidate funtional requirements


Scenarios:
----------

(S1) [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.

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

(S3) Providing an expression of corporate policy with respect to
media capabilities.  For example, an organization might declare a common
capability for incoming Internet faxes, so that detailed capabilities of
each internal system do not have to be published.

(S4) Consider a web server offering several variants of a resource, each
having several features in common and a relatively small number of key
differences.  It is desirable that the common features can be described
just once, and the variants can simply describe their differences from that
common set.  

(S5) A message recipient may wish to refer a potential sender to some other
more accessible location for a copy of the receipient's capabilities.


Terminology:
------------

(T1) "Common feature set" is some feature set that may be used as a common
reference point in the definition of other media feature sets.

(T2) "Indirect reference" is some (presumably short) identifier that can
stand for some composite feature set.

(T3) "Delegation" from one capability expression to another:  a
construction whereby a feature set expression 'C' can defer to some other
expression 'D' for definitions of feature constraints that are not provided
by 'C'.



Motivations and goals:
----------------------

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

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

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

(G4) maximizing interoperability with deployments of capability expression
based on current specifications.  Agents using any new specifications
should be able to accept capability expressions from and deliver
expressions to agents conforming to current specifications.   (This
suggests avoiding changes to the core expression syntax.)


Candidate functional requirements:
----------------------------------

(R1) Extension of capability expressions to allow "indirect references" to
"common feature sets".

(R2) Extension of capability expressions to allow "delegation" between
expressions.  (E.g. allow a selective override to some default, or to
specify a local difference from some commonly known feature set.)

(R3) Procedure for registration of tags to describe common feature sets.

(R4) Interpretation of URIs used to denote common feature sets.

(R5) Guidelines for profiling the use of (R1), (R2) in specific
applications and/or protocols.


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


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