Subject: RE: Capability terminology

From: "McIntyre, Lloyd" <[email-masked]>
Date: Wed, 11 Nov 1998 10:53:40 -0800

The ITU-T meeting definitely indicated that this clarification is
needed.

Lloyd

> -----Original Message-----
> From:	Graham Klyne [SMTP:[email-masked]]
> Sent:	Wednesday, November 11, 1998 8:33 AM
> To:	conneg WG; [email-masked]
> Subject:	Capability terminology
> 
> All,
> 
> Following some terminology confusion at the recent ITU-T T.37 fax
> meeting,
> I have proposed some new terminology in my working version of the fax
> feature schema document:
> 
>   "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.
> 
>   "capability identification" is a particular form of 
>   capability exchange in which a receiving system provides 
>   capability information to a sending system.
> 
>   "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.
> 
> I think we should determine:
> (a) if this terminology is appropriate, and
> (b) where the terminology should be explained.
> 
> I believe it is clear that we need at least some terminology to
> distinguish
> between capability information, and mechanisms for communicating such
> information.
> 
> I have placed these in the fax schema document for now as a
> placeholder, so
> they doesn't get lost in a last-minute rush.
> 
> #g
> 
> ------------
> Graham Klyne
> ([email-masked])

---

From: Graham Klyne <[email-masked]>
Date: Thu, 12 Nov 1998 12:44:02 +0000

At 16:14 11/11/98 -0800, Dan Wing wrote:
>On Wed, 11 Nov 1998, Ted Hardie wrote:
>
>> Dan,
>> 	Does Graham's "capability identification" match those
>> EIFAX uses that "exchange" does not?
>
>Yes.  "Capability identification" would be fine, I think.

I agree that what EIFAX does is "capability identification".

#g

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

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Fri, 13 Nov 1998 09:47:28 -0800

> Sent:	Friday, November 13, 1998 5:54 AM
> To:	Dan Wing
> Cc:	conneg WG; [email-masked]
> Subject:	Re: Capability terminology
> 
> 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.
	[McIntyre, Lloyd]  snip ...
>  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?
	[McIntyre, Lloyd]  Definitely helpful, eifax seems like a good
home since that is were the top view of capabilities resides.

	[McIntyre, Lloyd]  snip..

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Fri, 13 Nov 1998 14:38:34 -0800

> From:	Dan Wing [SMTP:[email-masked]]
> Sent:	Friday, November 13, 1998 1:36 PM
> To:	McIntyre, Lloyd
> Cc:	Graham Klyne; conneg WG; [email-masked]
> Subject:	RE: Capability terminology
> 
> On Fri, 13 Nov 1998, McIntyre, Lloyd 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.
> > 	[McIntyre, Lloyd]  The DCS does not provide capability
> > information. It sets the session parameters based on the
> capabilities
> > defined in the DIS.
> 
> So:  "DIS: This is what I can receive", and "DCS: This is what I'm
> going
> to send".  Right?  
	[McIntyre, Lloyd]  Yes.

> That's an exchange.
> -Dan Wing

---

From: Graham Klyne <[email-masked]>
Date: Mon, 16 Nov 1998 13:55:25 +0000

I have sympathies on both sides of this argument, so I'm not going to
express an opinion (for now).

But I observe that there was an idea kicked around a while ago for a MIME
'Content-features' header or content-type parameter to describe the
enclosed data using capability syntax.

#g

At 15:50 13/11/98 -0800, Cancio, Vivian wrote:
>> > that it would have been nice if we could
>> > send some 'description' of the TIFF attachment being attached
>(outside
>> > of the TIFF file - don't know where) -  matching the model of the
>DCS -
>> > so that receiving SMTP IFax servers could determine a mismatch to
>the
>> > capabilities of the recipient's and could send back a NAK DSN
>> > immediately, without the message ever being opened or processed. I
>was
>> > told this was not that simple, so I didn't insist, but if we could
>do
>> > that, it will be close to how you use a DCS.
>> 
>> Neat idea on the surface, but what should a receiver do when 
>> the external
>> file format description doesn't match the internal (TIFF) description?
>> 
>> I know we could specify that in a standard, but because the 
>> information is already in the self-describing TIFF file, it seems
>unnecessarily
>> redundant and prone to error:
>
>I was trying to avoid the "processed/opened" implications once you have
>to look inside the TIFF file, in which case you can only send an MDN.
>
>I understand of the possibility that the "sender's TIFF file descriptor"
>or the "sender's TIFF capabilities" may be "destroyed" somehow and not
>match the actual TIFF image and therefore causing the problems you
>described. I don't have an answer, so therefore I don't insist. I don't
>know how often that (problem) would happen vs. the advantages it offers
>when and if it does work. A concern will also be how long will it take
>the users to discover the problem you describe, when or if it occurs.
>
>Vivian
>
------------
Graham Klyne
([email-masked])

---

From: Graham Klyne <[email-masked]>
Date: Mon, 16 Nov 1998 13:55:19 +0000

At 11:49 13/11/98 -0800, Dan Wing wrote:
>On Fri, 13 Nov 1998, Graham Klyne wrote:
>
>> I do not see the sender disclosing any of its capabilities to the recipient
>> in G3 fax.  
>
>(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

I, too, could be wrong.  But my reading is this:

For a normal fax transmission, called terminal sends DIS to indicate
capabilities, and the caller sends DCS to indicate actual parameters
relating to the image sent (as opposed to capabilities).

When (and only when) the calling terminal is polling for a message, it
sends DTC to indicate its capabilities and the called terminal sends DCS to
indicate specific image parameters.

See T.30 section 5.1 for sequences, and Table 2/T.30 bits 16, 17-18, 44,
49, 76-79 for indication of difference between DIS/DTC bits and DCS bits.

>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").

That's fine -- and matches my intent.

#g

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

---

From: Graham Klyne <[email-masked]>
Date: Mon, 16 Nov 1998 13:55:09 +0000

#g

---

From: Graham Klyne <[email-masked]>
Date: Mon, 16 Nov 1998 13:55:12 +0000

#g

---

From: Graham Klyne <[email-masked]>
Date: Mon, 16 Nov 1998 17:45:27 +0000

>On Fri, 13 Nov 1998, Graham Klyne wrote:
[...]
>> Anyway, do you wish to propose an alternative definition for "capability
>> exchange"?
>

Revised text (still in fax-feature-schema for now):

"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.  This term covers both one-way and 
two-way transfers of capability information.

#g

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