RE: Capability terminology

[Graham Klyne <GK@xxxxxxxxxxxxxx>]

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
>