Subject: RE: REVISED draft-ietf-fax-eifax-08.txt

From: Graham Klyne <[email-masked]>
Date: Tue, 27 Oct 1998 11:21:01 +0000

At 16:02 26/10/98 -0800, Dan Wing wrote:
[...]
>> So, if the primary intent is to elicit a capabilities report using the new
>> DSN or MDN reporting extension defined in "reporting-extensions", the best
>> way to elicit this is to send a TIFF file that one does not believe the
>> receiver will be able to process.  
>
>RFC2305 prohibits this, and -eifax- doesn't allow this, so it remains
>prohibited by -eifax-.

Oh yes, my suggestion (elsewhere) likewise fails.  Oh well!

>But there needs to be a computer-parsable mechanism for the recipient to
>understand the image isn't to be "processed":  or else it will try to
>process the image by displaying it to the user or transmitting it (in
>the case of an offramp).

The Content-disposition:metadata proposal springs to mind as *part* of any
possible approach.

#g

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

---

From: Ned Freed <[email-masked]>
Date: Tue, 27 Oct 1998 07:19:55 -0800 (PST)

> The Content-disposition:metadata proposal springs to mind as *part* of any

I completely agree that content-disposition tagging should be part of this, but
I'm not convinced the metadata tag is appropriate here.

Let's first take a look at the history. The concept of probing for capabilities
using specialized message and/or commands isn't a new one. Attempts have been
made to do this as part of messaging as far back as 1980, and probably earlier.
In particular:

(1) SMTP has the VRFY command, whose intent was to provide some support along
    these general lines.
(2) FIPS PUB 98 (X.400-1980, more or less), Message Router, X.400-1984,
    X.400-1988, X.400-1992, and X.400-1996 all incorporate the concept of
    a probe as distinct from a message. A probe results in a report (DSN)
    and included in that information is what amounts to a list of supported
    content types as well as some particular characteristics of that support.
(3) Various proprietary LAN email systems have included variants on these
    ideas.
(4) Various messaging-based applications, most notably list servers, have
    attempted to use empty or specialized messages to determine recipient
    validity, and in some cases, capabilities.

However, the history of deployment and support for these protocol features has
not been good. VRFY has always been required in SMTP, yet many servers either
haven't implemented it or have implemented it badly, with interoperability
problems being the result. Support for probes in X.400 and X.400-like systems
is anywhere from spotty to nonexistant, making this feature entirely useless in
practice. The various facilities in LAN email systems have suffered from
confused and conflicting semantics as well as major issues gatewaying to
standard mail systems (surprise surprise). And although I've seen some
amazingly hostile responses to various things in email, the hostility I've seen
from users over receiving administrative non-messages from list software has
rarely been surpassed.

So what does history tell us? It tells us that:

(a) Protocol extensions to do this, either in the form of a capabilities
    command or a new sort of transaction type (e.g. PROB[E] FROM rather than
    MAIL FROM) won't work because they won't ever be implemented widely enough.
(b) Attempts to do this using only distingushed message content, either in the
    form of a sort of "test message, please ignore" or an illegal TIFF file
    or whatever, will only not only fail, they will be met with considerable
    hostility. (I've regularly seen mail blocked over this sort of thing. And
    less regularly I've seen overtly hostile acts like mail-bombing
    undertaken.)

(b) concerns me greatly. It means that at a minimum we need a strong
standardized indicator of a message's "probe" status in the header, as well as
well defined rules for how such messages are to be handled (basically pretend
to deliver and generate a DSN but don't actually do it), plus probably some DSN
extensions to distinguish such responses. I have no problem moving forward
with these pieces in place, but without them not only is this a nonstarter
standardw-wise, it is an actively dangerous thing to recommend.

Finally, getting back to the possible use of a "metadata" disposition,
I don't see this as a sufficiently strong indicator. Metadata translates
to "don't display", it does not translate to "receipt and discard if possible".
And the latter is what we want if we can get it.

				Ned