Subject: RE: Capability terminology

From: "Herman R. Silbiger" <[email-masked]>
Date: Sat, 14 Nov 1998 00:18:51 -0500

It's an exchange, but not a capabilities exchange.  The capabilities declaration went only in one direction.

Herman Silbiger

----------

So:  "DIS: This is what I can receive", and "DCS: This is what I'm going
to send".  Right?  

That's an exchange.

-Dan Wing

---

From: Al Gilman <[email-masked]>
Date: Sat, 14 Nov 1998 12:29:33 -0500 (EST)

to follow up on what Herman R. Silbiger said:

> It's an exchange, but not a capabilities exchange.  The
> capabilities declaration went only in one direction.

In the common parlance, an exchange of capability for anything is
a capability exchange.  It need not be an exchange of capability
for capability.  All it needs to be is an exchange of capability
for something in return, which this is.

On the other hand, if this is going to be a stumbling block
for people working in the FAX field, we should come up with
an equally suitable term that works both in plain English
and for this audience.

What would people think of saying "for the communication of
capability" instead of "for the exchange of capability" in
describing the domain of application of the registry and algebra?
That clearly connotes both monologues and dialogs.

In the CONNEG context, it is clearly the intention that the 
capability-description capability is meant to be done in a way
which is applicable across a broad range of protocols in which
capability knowledge flows one way or both ways.  The 
way we "capture capability in order to communicate it" wants
to be innocent of the unidirectional or bidirectional nature
of the information flow.

On the other hand, we clearly have a comprehension barrier
because there is here a community which will read "exchange" in a
particular narrow way.  Since this community is an important
stakeholder for the CONNEG technology, we should scrub our
terminology to avoid even the appearance of saying what we don't
mean.

Please note that adaptive styling done entirely by the client
also needs a way of capturing these same capabilities.  If we can
set up the facilities for display-capability characterization so
it works both problems, we can use a common lexicon and the
payback and uptake will be better for both applications of the
characterization facilities.  Otherwise we are leaving money on
the table and creating a ready-made power base for a competing
way of doing the same thing.

Al