Subject: RE: Capability terminology

From: "Cancio, Vivian" <[email-masked]>
Date: Fri, 13 Nov 1998 15:50:19 -0800

> > 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

---

From: Dan Wing <[email-masked]>
Date: Fri, 13 Nov 1998 15:59:48 -0800 (PST)

> the users to discover the problem you describe, when or if it occurs.

Well, it's certainly reasonable.  

Graham and I had vetted out an idea based on
draft-lundblade-1pass-mult-alt-01.txt which would allow both the MIME
content-type as well as the CONNEG-style information to be included in the
inforamtion describing the various alternates.

This could be included in the Content-Type, too, like:

  Content-Type: image/tiff; application=color; feature=blahblah
                                               ^^^^^^^^^^^^^^^^

where the "feature=" would use CONNEG-style syntax to describe, in
detail, the contents of the image/tiff.

I think implementation experience will help us determine if we need
MIME-level descriptions of the content-type.  The state of the art today
with MUAs is that they only use the MIME content-type (type/subtype)
to launch a viewer that can view that content-type and have no mechanism
to launch a different viewer based on other attribute-value pairs
in the Content-Type header (such as feature=blah versus feature=foobar).

-Dan Wing