Re: Capability terminology

[James Rafferty <jrafferty@xxxxxxxxxxxxxxxx>]

Graham,  

At 01:53 PM 11/13/98 +0000, Graham Klyne wrote:
>At 14:05 12/11/98 -0800, Dan Wing wrote:
>>On Thu, 12 Nov 1998, Graham Klyne wrote:
>>

>>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?
>
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:  JRafferty@xxxxxxxxxxxxxxxx
	 J_Rafferty_HC@xxxxxxxxxxxxxx

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