Subject: RE: [VPIM] Re: draft-ema-vpim-pndn-00.txt

From: "COLES, RICHARD J. (JSC-EV)" <[email-masked]>
Date: Mon, 24 Jan 2000 09:03:50 -0600

From Graham Klyne:
>In the absence of a critical part indicator, then I 
>would suggest that failure to deliver any part should 
>be regarded as failure to deliver the message.

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.

In fact, I thought this particular point was settled more than a year ago.
Maybe 2 years, I don't really recall any more.

Tnx/RJC

-----Original Message-----
From: Graham Klyne [mailto:[email-masked]]
Sent: Monday, January 24, 2000 5:41 AM
To: [email-masked]
Cc: IETF fax WG; IETF VPIM List
Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt

At 08:02 PM 1/20/00 -0600, [email-masked] wrote:

>Open questions:
>
>1. A general principle for Internet protocols is field order doesn't
>matter.  In the above proposal, all body parts belonging to a given
>per-recipient-field block must be contiguous.  That is, we cannot use a
>blank line to separate the per-part-fields, as proposed in
>draft-ema-vpim-pndn-00.txt.  This is because existing DSN implementations
>would interpret the blank line to be a separator for the
>per-recipient-fields, not per-part-fields.  One solution is to require the
>part-action-field precede any other per-part-fields.  The choice of
>part-action-field is because it's one of the two required fields.  Is this
>a reasonable solution?

I would like to avoid the position dependence if possible, but don't have a 
concrete proposal at this stage.  I would suggest retaining the standard 
DSN format of per-recipient groups, and incorporating per-part headers 
within these groups by indicating the part id (somehow) within each such 
header.

>2. What should we do for the action-field and status-field for the message
>as a whole?  If we have a critical-part indicator, then it's easy: if the
>critical part got delivered, then the PNDN is an informational message;
>otherwise, the PNDN is a failure notice.  If there isn't a critical-part
>indicator, then there are three choices:
>    a)  Always return failure
>    b)  Always return success
>    c)  Let the developer choose what's best
>As a developer with a marketing department, I know which result we'll
>return :-)  Actually, given that reality, I'm leaning to have PNDN be a
>success/informational message, unless there's a critical-part indicator.

In the absence of a critical part indicator, then I would suggest that 
failure to deliver any part should be regarded as failure to deliver the 
message.

#g

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Jan 2000 11:34:46 -0500

> that failure to deliver even the smallest part of a message is a failure,

It might be true for fax, but I don't think it's true in general.
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?).

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.
just because you recognize a content-type doesn't mean that you
understand how to deal with every variant of that content-type.

Keith

---

From: Mark Fraser <[email-masked]>
Date: Mon, 24 Jan 2000 09:27:15 -0800

Either a system "takes responsibility" for delivery and notification, or it
does not.

You may treat personal email in a cavalier manner, but don't force its
failings onto FAX carriage.  And while I personally feel that there are
still many dozens of bandaids needed to make email conform to some
minimal standard of performance, I would rather see this model be
fixed, rather than further compromised by relaxing the definition of
"delivered".   Just my $0.0166 / mark

---

From: [email-masked]
Date: Mon, 24 Jan 2000 09:13:36 -0800 (PST)

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

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

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

> 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

---

From: [email-masked]
Date: Mon, 24 Jan 2000 09:50:43 -0800 (PST)

> failings onto FAX carriage.

Mark, I don't think anyone here is treating personal email in a cavalier
manner. I must say I also find it borderline offensive for you to imply that
email has failing but existing FAX does not. The fact of the matter
is that both services have their issues -- failings if you will -- that
the new service we're building needs to address.

This is why there's significant technical justification for a partial delivery
notification. Like it or not, the range of devices and the range of formats
people are going to use is such that partial delivery is going to be
inevitable. In particular, it is simply not possible to constrain this service
to a single set of universally acceptable formats. This has been tried in both
the email and FAX worlds and has been a failure in both.

The question to my mind is that given the inevitability of partial delivery
occurring is a mechanism for making it visible to users useful. My previous
message explained my position on this issue.

> And while I personally feel that there are

This sort of comment is entirely nonconstructive. Please desist.

				Ned

---

From: Graham Klyne <[email-masked]>
Date: Mon, 24 Jan 2000 18:35:49 +0000

>support for parsing and correlation of regular DSNs, I'm pretty pessimistic

I take your point, but it is interesting to note that one of the drivers 
for considering partial delivery notification has come from the traditional 
fax community -- As I recall, ITU-T SG8 have asked for Internet fax to 
report how many pages have been delivered.  (I include below what I 
understand to be the requirements from SG8.)

(I'm less clear about the driver from the voice mail community.)

#g

2.2  Request - 2.2    The fax processed status information in RFC2530
needs to be enhanced. We need a facility to enable the total number of
pages and pages in error to be returned to the sender in a MDN to
indicate successful processing.  We need further precision on the fax
status information using DSN and/or MDN.

2.3    Request - Similarly the specification within RFC2298 for the
value processed need to be enhanced. We need further precision to ensure
that the specific MDN response that is generated clearly indicates that
the MIME body part(s) has been successfully processed (i.e. printed or
displayed).

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

---

From: Mark Fraser <[email-masked]>
Date: Mon, 24 Jan 2000 10:49:49 -0800

I didn't make my point clearly, for which I apologize.
I was not commenting on the reliability of fax, but on the dangers of
relaxing the need to report a problem.  Fax lacks many of the
mechanisms to detect or evaluate the seriousness of a particular
impairment, to be sure.  I also agree that users will have vastly
different interpretations of any reported problem.
That should not remove the responsibility to report any difficulty
encountered during transmission.  I was reacting to the implied
suggestion that partial delivery be treated as completed delivery.
Failing a list of possible impairments and combinations of
impairments, against which we could assign a "pass/fail" parameter,
I am in favor of full reporting. / mark

---

From: "Herman R. Silbiger" <[email-masked]>
Date: Mon, 24 Jan 2000 14:35:46 -0500

We seem to be ascribing different meanings to partial delivery. If we fail to
deliver all the pages in a fax, returning this information to the sender will allow
the sender to retransmit the missing pages.  The same is true for a multipart
message when on or more of the parts were not successfully delivered.

It is true that the criteria for declaring a particular page not to be successful
in fax are not defined in the standard and thus each manufacturer has defined their
own.  This accounts for the variability noticed by earlier commenters. In any case,
we are dependent on the interpretation of the particular manufacturer for the
decision as to whether it was successful or not.

My personal take on this is that the delivery information to be returned should be
useful and allow appropriate action to be taken.  Sometimes we may have to
retransmit the entire message even when we know where the error occurred because it
is not feasible to only retransmit that part of the message.

---

From: [email-masked]
Date: Mon, 24 Jan 2000 11:40:44 -0800 (PST)

> message when on or more of the parts were not successfully delivered.

Actually, the differences are even greater than this. The FAX world's issues
with partial delivery have to do with the analog lines used and the resulting
possibility that some portions of a transmission can be garbled. In such
cases there is a reasonable expectation that retransmitting will help.

This is not the case in the email world. Partial losses due to garbling of
message content on analog lines are extremely rare. Losses in the email world
generally are the result of some system being incapable of handling some
particular media type. And in such cases retransmitting the same message to the
same address is a total waste of time.

However, at least one of the goals here is to standardize a way to report
tranditional FAX errors when gatewaying from email to FAX. So I basically
see the issues of describing FAX errors as a subset of a much larger and
more complicated problem this proposal is attempting to address.

> decision as to whether it was successful or not.

Then perhaps we should carry this over to the present case and allow some
leeway in what constitutes an error when gatewaying.

> is not feasible to only retransmit that part of the message.

Perhaps this argues for focusing on reporting more about how to deal with the
error than the specifics of the error itself. In the FAX case there should be
something to indicate retransmission would help. In the case of a dropped part
because the system cannot deal with it an alternate address would perhaps make
sense. (SMTP used to have some redirect facilities, but they have fallen into
disuse.)

				Ned

---

From: [email-masked]
Date: Mon, 24 Jan 2000 11:24:40 -0800 (PST)

> encountered during transmission.

My point is that while I agree with you from a standpoint of abstract standards
and protocol development, my experience with this in practice with real world
products doesn't agree at all. Far from liking it when absolutely all
difficulties were reported, our users disliked it so much that our choice was
simple: Either disable reporting of problems below a certain threshhold or else
lose many of our customers.

And if the behavior of most of the FAX machines I use is any indicator, their
makers have reached the same conclusion we did.

> I was reacting to the implied

Well, the delivery most certainly has been completed to the extent it ever
will be, so I don't have a problem with calling it "completed". I think
you meant to say "complete". If so, please remember that the structure
of delivery reports is such that we have to assign a success/failure indicator.
We simply don't have a choice in the matter. And if we elect to assign a
"fail" indicator to any problem whatsoever, we run smack into all the
problems I've already described.

> impairments, against which we could assign a "pass/fail" parameter,

Even assuming we could reach agreement on such thing, which I doubt, such a
list would have to be so context-sensitive that its size would explode in a
combinatoric fashion. And it would have to be constantly updated to be useful.
In short, while I understand the motiviation and to some extent agree with it,
I don't think such a list is viable.

> I am in favor of full reporting. / mark

Believe me, I'd like to be, but without certain guarantees from the user agents
in regards to information correlation I don't think it is practical to do this.

				Ned

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Jan 2000 19:48:35 -0500

> Either a system "takes responsibility" for delivery and notification, or it

no question there, but I fail to see how it applies to the current situation.

> failings onto FAX carriage.

there's nothing cavalier about it.  my point was that in a world where
different recipients have drastically different capabilities, it's 
fairly hard to define "successful delivery" in a way that actually
makes sense.  the "obvious" definition - require that every part 
be delivered or else it's a failure - turns out to produce 
counterintuitive behavior in a significant number of cases.
which doesn't mean that the obvious answer is the wrong one, 
but it probably does mean that it needs a closer look.

and I don't believe for a millisecond that email-to-foo gateway
vendors/operators are going to be willing to return "failure"
DSNs every time they can't translate every single portion of the 
message content.  

Keith

p.s. I don't see why we should force FAX's limitations onto email, either.

---

From: [email-masked]
Date: Mon, 24 Jan 2000 17:52:22 -0800 (PST)

> DSNs every time they can't translate every single portion of the

Yup. And this isn't going to change no matter what the standards say.

				Ned

---

From: MAEDA toru <[email-masked]>
Date: Sat, 29 Jan 2000 21:31:23 +0900

Thanks Graham,

I am waiting the discussion and answer about the ITU-T communication 
which you wrote below for long time.

Toru MAEDA

> the MIME body part(s) has been successfully processed (i.e. printed or

＊＊＊＊＊＊＊＊＊＊＊＊＊＊
前田　徹
キヤノン（株）
映像事務機第3技術推進部