Subject: Re: Capability terminology

From: Graham Klyne <[email-masked]>
Date: Fri, 13 Nov 1998 13:53:45 +0000

At 14:05 12/11/98 -0800, Dan Wing wrote:
>On Thu, 12 Nov 1998, Graham Klyne wrote:
>
>> >"Exchange" is a two-way transaction.  I "exchange" US dollars for
>> >a foreign currency (two-way transaction).  I "exchange" my efforts
>> >at work for my paycheck.  My body "exchanges" oxygen for carbon
>> >dioxide.
>> 
>> True.  I used this form of definition because the term "capability
>> exchange" has also been used in the fax context which is not a two-way
>> communication.
>
>With fax there isn't a symmetric capabilities exchange but there is a
>capabilities exchange between the transmitting and receiving terminals.
>
>However, the existing proposals for capabilities aquisition for email
>such as LDAP, DSN/MDN messages, etc., do not cause the sender to
>provide any of its capability information at all.

I do not see the sender disclosing any of its capabilities to the recipient
in G3 fax.  In eifax, the existence of certain MDN request extensions might
give some clues, but I still see no two-way transaction here.  I think that
is "capability identification".  But it is also called "capability
exchange" by some, hence my definition.

Anyway, do you wish to propose an alternative definition for "capability
exchange"?

And a question to ALL:  are these definitions helpful, and where should
they appear?

>Perhaps this is something we should address:  a sender knows what file
>types it could render a source document in: image/tiff, image/jpeg,
>application/pdf, etc., and maybe it would be useful for the sender to
>query the recipient with details on the recipient's ability to handle each
>individual MIME type.  I am sure in practice that this would degrade to
>http's "Accept: */*" pretty quickly, though....

I'm sure you're right.  One of my goals in the early 'conneg' work was to
devise a system that did not impose constraints on the mechanism used.
Hence the emphasis on symmetry (of expression).

Individual mechanism may, of course, be asymmetric.  It is my view, which I
tried to capture in the conneg -requirements- draft, that the appropriate
form of mechanism is dependent on the protocol/application with which it is
used.  So mechanisms for web browsing would be very different to mechanisms
for fax, etc.

#g

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

---

From: Dan Wing <[email-masked]>
Date: Fri, 13 Nov 1998 11:49:32 -0800 (PST)

On Fri, 13 Nov 1998, Graham Klyne wrote:

> in G3 fax.  

Doesn't the DIS go one directiona and the DCS the other direction
(sender->recipient and recipient->sender)?  I'm not a fax person and my
copy of T.30 is at home (of course) and I'm at work.  I've certainly
been wrong before and am likely to be wrong again.

> In eifax, the existence of certain MDN request extensions might

Your original definition is fine, but I'd just like an additional sentence
or embedded phrase which clarifies that an "exchange" it isn't necessarily
a bi-directional exchange (per the dictionary definition of the word
"exchange").

-Dan Wing

---

From: James Rafferty <[email-masked]>
Date: Fri, 13 Nov 1998 15:16:02 -0500

Graham,  

>And a question to ALL:  are these definitions helpful, and where should
I think the definitions are useful, but overlap considerably with terms
already used in the Internet Fax Goals and Terminology document.   I
believe terms for IETF Internet fax use are best defined in -goals and then
used in other documents.  Where the terms are more general with respect to
capabilities, CONNEG documents may be the best place for the definitions;
see my comments below.  

You have proposed:  

>"capability exchange" describes any transfer of 
>  information between communicating systems that is used to 
>  indicate system capabilities and hence determine the form 
>  of data transferred.
>
A similar definition is in "Goals" already:   

# The exchange of capabilities in Internet Fax should {2} be robust. To

# accomplish this, recipients should {2} be encouraged to provide
# capabilities, even while senders must {1} have a way to send messages
# to recipients whose capabilities are unknown.

>  "capability identification" is a particular form of 
>  capability exchange in which a receiving system provides 
>  capability information to a sending system.
>
Goals uses the term Capabilities "indication" for this as shown below:

# Even minimum-capability recipients of messages should {2} be required
# to provide a capability indication in some reliable way. This might be
# accomplished by providing an entry in a directory service, by offering
# automatic or semi-automatic replies, or by sending some indication of
# in a reply to a message with multiple renditions, or as an addition to
# a negative acknowledgement requiring retransmission.
 
I personally think identification is the better term here than indication.
 I could 
support changing the word "indication" in Goals to "identification".    In
practice, this is what takes place in extended Internet fax as defined in
-eifax.   

>  "capability description" is a collection of data 
>  presented in some specific format that describes the 
>  capabilities of some commincating entity.  It may exist 
>  separately from any specific capability exchange 
>  mechanism.

Goals has done a reasonable job of making the same point (expression or
description being indepedent of mechanism), using the term
capabilities expression, which to me seems equally valid.  I don't see a
need to change this part of -Goals.   

Maybe the place to define this term (capabilities description) is in one of
the Conneg documents, such as in the -reg or the -requirements document.  I
checked the registration document and it already makes the distinction between
expression and mechanism, but does not use the term "capabilties
description". 
A sentence on this could be added in the section  2.1 (Media feature tag
purpose), right after: 

# Feature collections may be composed using a number of individual
#  feature tags [2]. Composition of feature collections is described
#  elsewhere [2].  Examples of feature collections requiring multiple
#  media feature tags are:
#  
#  * teh set of all fonts used by a document
#  * the width and height of a display
#  * the combination of color depth and resolution a display can support  .   

James 
*------------------------------------------------*
James Rafferty			
President, Human Communications 	
12 Kevin Drive			
Danbury, CT  06811-2901		
USA					
Voice/Fax:  +1-203-746-4367
Email:  [email-masked]
	 [email-masked]

HC Web Site:  http://www.humancomm.com  
*---------------------------------------------------