Subject: draft-ietf-fax-eifax-03.txt

From: Graham Klyne <[email-masked]>
Date: Wed, 09 Sep 1998 18:47:06 +0100

My apologies for the delay in posting these comments...

Some of these have been superseded by later discussions, but it's easier
for me to include all my comments than to try to remember which are no
longer relevant.

#g

[...]
>2.1.  Background
>   
>   This section explains the background of delivery confirmation for
>   facsimile and Internet mail as a justification for the protocol
>   requirements made in section 2.2.
>
>   In traditional facsimile, the sending terminal receives a
>   confirmation when the receiving terminal has finished processing
>   the incoming fax.

(Pedant mode) I think this is not strictly true.  I think it's more a case
of "... when the receiving terminal has accepted the incoming fax and
determined that it is able to complete processing".

[...]
>   b) when they are reported:
>     Delivery status is reported when a message is delivered to some
>     repository or end-point under the control of the recipient.
................................................................^
+  ", or sooner"

>     Disposition notification (MDN) is provided when the message is
>     disposed of by the recipient user, either manually or
>     automatically.
>   
>   c) which agent reports them:
>     Delivery status is reported by the mail transport mechanism, while
>     disposition is reported by the end mail user agent.
.....................................<-> "receiving" ?

>
>   d) what form the reports take:
>     Both DSNs and MDNs are sent in a "multipart/report". DSNs use
>     "report-type=delivery-status"; MDNs use
>     "report-type=disposition-notification".
>   
>   e) the requirement for notification:
>     The standards for MDNs and DSNs differ on the requirement for
>     automatically generating them.  The generation of MDNs by any
>     recipient is entirely optional, and thus no sender can rely on
>     obtaining a MDN from an arbitrary recipient. The generation of some
................*
Here, you say "a MDN".  Elsewhere you say "an MDN".  (I prefer the latter.)

>     kind of DSN (if only a 'relayed' message) is required and a
>     standard part of MTA operation.
>   
>2.2.1.2.  Processing Confirmation
>
>   If an EIFax sender wishes to receive processing confirmation
>   and the final recipient is a Mail User Agent, the EIFax sender 
>   MUST request an MDN [RFC2298].
>
>   If an EIFax sender wishes to receive processing confirmation
>   and the final recipient is a fax offramp implemented as an
>   MTA, the fax offramp will generate processing confirmation
>   in the absense of an MDN request, so an MDN request is not
>   necessary.

I think it should be made clear that an unsolicited MDN will not be sent,
even in the event of failure.  In this case, any unsolicited failure notice
is sent as DSN.
   
[...]
>2.2.2.   EIFax Recipient Requirements
>
>   All EIFax recipients SHOULD implement MDN [RFC2298], and SHOULD
>   implement Fax Extensions for DSN and MDN [REPORT-EXTENSIONS],
>   and MUST be configurable to silently ignore a request for an MDN
>   ([section 2.1 of RFC2298]).

Are we suggesting that offramp MTAs implement MDN?  This seems at odds with
their gateway MTA role.

[...]
>2.2.3.1.  Sender Infrastructure 
>
>   Support for DSN [RFC1891] MUST be provided by the mail submission
>   server [SUBMIT] used by the EIFax sender, and SHOULD/MUST (?) be
>   provided up to the mailer responsible for communicating with external
>   (Internet) mailers.

I like MUST.
   
>2.2.3.2.  Receiver Infrastructure 
>
>   Support for DSN [RFC1891] SHOULD/MUST (?) be provided by the external
>   (Internet-accessible) mailer, and SHOULD/MUST (?) be provided by each
>   mailer between the external mailer and the EIFax recipient.

I like MUST.

#g

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