ned.freed@innosoft.com
Mon, 24 Jan 2000 09:13:36 -0800 (PST)
> > I have not posted to the FAX-WG in a VERY long time, but I must agree here,
> > that failure to deliver even the smallest part of a message is a failure,
> > period.
> It might be true for fax, but I don't think it's true in general.
FWIW, it certainly isn't true for existing FAX services. I've seen more than
one instance where a FAX got hopelessly garbled but the FAX machine reported
that it was successfully sent. And I've also seen cases where a tiny error --
a couple of bits in one scan line -- was reported as a failure. The
range of reporting and interpretation of these sorts of failures seems to
be very wide in practice.
We grappled with this reporting problem at some length when designing our FAX
software. We originally decided to report the actual facts to the user -- a FAX
sent but with this many errors on page whatever sort of message. And we found
that users simply hated it and complained vehemently until we removed the
feature. There simply was no interest in or tolerance of gray; the users wanted
this to be a black and white result. (Of course this then begs the question of
how many errors you tolerate before calling it a failure. I believe we picked
some threshhold and then tweaked it in light of subsequent experience.)
Worse still, user interpretation of such messages was more a matter of their
own personality than anything the message actually said: The optimistic sorts
assumed success even when the report listed many errors on every single page
and the pessimistic sorts assumed failure even when the report listed a single
error on a blank page. This was definitely a factor in our decision to remove
the feature from our software.
Now, the enhancement to DSNs presently being discussed is fairly different in
character -- we're talking about noting damage to or loss of specific message
parts, not loss of bits in an image. But I'm nevertheless worried about the
user perception of this facility, especially given past experience in how these
things can be misinterpreted.
I guess my conclusion is that unless the user agents do a stellar job of
correlating the partial delivery information with the original message this
feature isn't going to be useful. And given the very slow uptake of user agent
support for parsing and correlation of regular DSNs, I'm pretty pessimistic
about this entire thing.
> In particular, if a body part cannot be delivered because it cannot
> be translated into the recipient's environment, that's not necessarily
> a failure. (e.g. should my palm pilot report delivery failure because
> it doesn't understand ms-tnef documents?).
This is an excellent example because it illustrates yet another problem with
partial reports very nicely. For those of you who aren't familiar with TNEF, it
is a Microsoft-proprietary format that can be used in one of two ways:
(1) As an adjunct to a regular MIME message containing additional information
about the message as a whole.
(2) As a completely self-contained message format in its own right. (The
most common use of this all-inclusive format is, ironically enough, for
receipt notifications. Are we circular or what? ;-)
Now, in the first case, the loss of the TNEF part is harmless since it
contained nothing useful. But in the secon case you have lost the entire
message when you don't have the TNEF part.
And this, of course, is the conundrum: How do you tell the difference between
the two cases? Short of looking inside the TNEF part to see what's there, I
don't know of a way to do it. And examining the content of the original message
for criticality information seems, well, a bit extreme.
> and there's a very fine line between 'cannot be translated because
> the recipient's environment doesn't support this content-type'
> and, say, 'cannot be translated because the message is garbled'.
> at times it will be impossible to tell the difference between the two.
FWIW, X.400 tried to do this in its error reporting and failed miserably.
> just because you recognize a content-type doesn't mean that you
> understand how to deal with every variant of that content-type.
This was definitely one of the factors that led to the failure of this
mechanism in X.400.
Ned
This archive was generated by hypermail 2.0b3 on Mon Jan 24 2000 - 19:39:54 IST