Subject: Decode-error case in Eifax(RFC2532)

From: Hiroshi Tamura <[email-masked]>
Date: Fri, 11 Jun 1999 14:09:04 +0900

I read RFC2532(Eifax) again.

From the terminal manufacuture point of view(not PC software),
some questions arised to me.

In the box type Eifax, decode error may often happen.
For example, terminal doesn't support 400x400dpi, but
if it receives the 400x400dpi document, what kind of
action or type should it respond as delivery confirmation(DSN)
or processing confirmation(MDN) ?

And, those kind terminal doesn't decode MS-WORD documents.
What should it do when it receives WORD doc ?

Case A: the SMTP type terminal which receives DSN request
In RFC1894(DSN) there are 5 action-values.
 failed / delayed / delivered / relayed / expanded

Should it respond with "failed" ? But,... in RFC1894,
there are the following explanations of this item.

- begin quote -
"failed"     indicates that the message could not be delivered to the
             recipient.  The Reporting MTA has abandoned any attempts to
             deliver the message to this recipient.  No further
             notifications should be expected.
- end quote -

In this case the message itself reached the terminal.
Just decode-error.
I don't think "failed" is appropriate response.

Case B: the POP3 or IMAP4 type terminal which receives MDN request
In RFC2298(MDN) there are 6 disposition-types.
 displayed / dispatched / processed / deleted / denied / failed

In RFC2298 there the following explanations.

- begin quote -
   "displayed"    The message has been displayed by the UA to someone
                              reading the recipient's mailbox.  There is
                              no guarantee that the content has been
                              read or understood.

   "dispatched"   The message has been sent somewhere in some manner
                              (e.g., printed, faxed, forwarded) without
                              necessarily having been previously
                              displayed to the user.  The user may or
                              may not see the message later.

   "processed"    The message has been processed in some manner (i.e.,
                              by some sort of rules or server) without
                              being displayed to the user.  The user may
                              or may not see the message later, or there
                              may not even be a human user associated
                              with the mailbox.

   "deleted"      The message has been deleted.  The recipient may or
                              may not have seen the message.  The
                              recipient might "undelete" the message at
                              a later time and read the message.

   "denied"       The recipient does not wish the sender to be informed
                              of the message's disposition.  A UA may
                              also siliently ignore message disposition
                              requests in this situation.

   "failed"       A failure occurred that prevented the proper
                              generation of an MDN.  More information
                              about the cause of the failure may be
                              contained in a Failure field.  The
                              "failed" disposition type is not to be
                              used for the situation in which there is
                              is some problem in processing the message
                              other than interpreting the request for an
                              MDN.  The "processed" or other disposition
                              type with appropriate disposition
                              modifiers is to be used in such
                              situations.
- end quote -

In decode-error case, is "failed" the appropriate response or not ?
From the above explanation it doesn't seem to be appropriate.

.

Another question for the POP3 or IMAP4 type terminal.
When it receives, decodes and "prints"(normal case of box type),
should it respond with "dispatched", not "displayed", not "processed" ?

...

Any comments or answers are welcome !

Regards,

--
Hiroshi Tamura, Ricoh Company, LTD.
Mail: [email-masked]
Tel: +81-462-28-7459  Fax: +81-462-28-7500 (SUB/F-code 5727)

---

From: Geoff <[email-masked]>
Date: Tue, 15 Jun 1999 04:32:38 -0400

Hello Vivian,

Hiroshi...

> What should it do when it receives WORD doc ?

Vivian

I am assume either of the following combination:
1) DSN: "delivered"/"success" & MDN: "processed"/" error"
2) DSN: respond with [RFC1893] status code of 5.6.1 regardless if DSN was
requested.
    MDN may also be sent but not required, since the DSN status code should
be sufficient. 

In an environment where only 50% of servers support DSN it seems preferable to always request an MDN. DSN status code may be sufficient if you get one, but if not ?

About the only reliable response from DSN is 'failed'. 

For example

I'm interested to know how the sending MUA should distinguish between the following responses.

MUA sends IFAX to <fax no>@domain.com

CASE A
domain.com is a fax gateway which delivers the IFAX direct to a PSTN fax machine and reports 'delivered'

CASE B
domain.com is a normal MTA. The MTA delivers the IFAX to mailbox <fax no> and reports 'delivered' BUT the IFAX is never retrieved by 'fax no' and the server deletes the message after (say) 30 days.

In both cases DSN has reported 'delivered'.

A tad misleading

Geoff

---

From: Graham Klyne <[email-masked]>
Date: Wed, 16 Jun 1999 17:03:28 +0100

At 19:48 15/06/99 -0700, Dan Wing wrote:

>Mike's Internet Draft described coverpages, but it also described 
>recommended behaviors for coverpages.  I believe Mike has abandoned
>the document.

Abandoned?

I was under the impression that it was in abeyance, pending some other
pieces of the overall puzzle fitting into place.

(Or maybe that's just wishful thinking on my part :-)

#g

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