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

From: Graham Klyne <[email-masked]>
Date: Mon, 05 Oct 1998 17:37:44 +0100

All,

A mixture of comments follow:  a few on the content, a couple on process
matters and several editorial.

#g
--

[...]
>1.  Introduction

[...]
>1.1.  Definition of terms
>
>   The term "processing" indicates the ability to successfully render or
>   successfully transmit the contents of the message to a printer, on a
>   display device, or to a fax machine.

I think the word 'successfully' is redundant here (twice).

I think you might mean "..., or a display device, ...".

>   The term "recipient" indicates the device which processes the content
>   of the mail message and renders it to the user by transmitting it to
>   a remote fax machine, printer, displaying it on a terminal.  For

Some of this simply repeats the definition of "processing" given above.

>   example, a recipient could be implemented as a traditional Mail User
>   Agent on a PC, a standalone device which retreives mail using POP3 or
.................................................^^ 'ie'
>   IMAP, an SMTP server which prints incoming messages (similar to an
>   LPR server).

[...]
>1.2.  GSTN Fax Gateways ("onramp"/"offramp")
>
>   The behavior of gateways from GSTN fax to SMTP ("onramps") and from
>   SMTP to GSTN fax ("offramps") are not described in this document.
>   However, such gateways SHOULD have the behavior characteristics of
>   senders and recipients as described in this document.
>
>2.  Delivery and Processing Confirmation
>
>   In traditional GSTN-based realtime facsimile, the receiving terminal
>   acknowledges successful receipt and processing of every page [T.30].
>
>   In Internet Mail, the operations of Delivery (to the mailbox) and
>   Disposition (to paper or a screen) may be separated in time (due to
>   store and forwarding of messages) and location (due to separation of
>   delivery agent (MTA) and user agent (MUA)).  The confirmation of
>   these two operations are supplied by two different standards-track
>   documents:  Delivery Status Notifications (DSN) [RFC1891, RFC1894]
>   and Message Disposition Notifications (MDN) [RFC2298], respectively.

That's *three* documents.  I think you may mean "two different Internet
standards"?

>   This section defines requirements for devices or services that are to
>   be considered compliant with the delivery and processing confirmation
>   section of this memo.
....[------------------]  I suggest: "features of Internet fax".

>2.1.  Sender Requirements
>
>   A delivery failure message (in a non-standard format or in the format
>   described by [RFC1894]) may be sent to the envelope-from address
...............................[-----------------------------------------
....----------------------]
I would prefer to give the DSN format higher priority here; e.g. "(in the
format described by [RFC1894], or otherwise)".

>   specified by the sender.  Thus, the envelope-from address supplied
>   by the sender MUST be able to properly handle such delivery failure
>   messages.
>
>2.1.1.  Delivery Confirmation
>
>   If the sender desires delivery confirmation, the sender MUST request
>   Delivery Status Notification by including the the esmtp-keyword
>   NOTIFY with the esmtp-value SUCCESS [section 5.1 of RFC1891].
>
>2.1.2.  Processing Confirmation
>
>   If the sender desires processing confirmation, the sender MUST
>   request Message Disposition Notification using the method described
>   in section 2 of [RFC2298].
>
>   Because a recipient can always silently ignore a request
........................[--------] "may"?

>   for an MDN [section 2.1 of RFC2298]:
>     *  MDNs MUST NOT be used for delivery confirmation, but are only
>        useful for disposition ("processing") notification.
>     *  the sender MUST NOT assume the recipient will respond to an MDN
>        request in a subsequent message, even if the recipient has
>        always responded to MDNs in the past.
.........[----------------------] "done so"?

>   The address provided by the sender on the Disposition-Notification-To
>   field MUST be able to receive Message Disposition Notifications
>   messages [RFC2298] and be able to receive messages that are not in
>   the Message Disposition Notification format (due to the existence of
>   legacy systems that generate non-RFC2298-compliant responses to the
>   Disposition-Notification-To field).

I'm going to make a process observation, then duck out of the debate.  Is
it appropriate to say effectively "MUST <conform with broken legacy
implementations>"?  I might suggest that should be a SHOULD.  i.e. "The
address provided by the sender on the Disposition-Notification-To field
MUST be able to receive Message Disposition Notifications messages
[RFC2298] and SHOULD be able to receive messages that are not in the
Message Disposition Notification format ..."

>2.2.   Recipient Requirements

[...]
>2.2.1.  MDN Recipient Requirements
>
>   Recipients MUST be configurable to silently ignore a request for an
>   MDN ([section 2.1 of RFC2298]).
>
>   If the recipient is an automated message processing system which is
>   not associated with a person, the device MAY be configurable to
>   always respond to MDN requests, but in all cases MUST be configurable
>   to never generate MDNs.
>
>   A recipient MUST NOT generate an unsolicited MDN to indicate
>   successful processing, but a recipient MAY generate an unsolicited
>   MDN (sent to the envelope-from (Return-Path:) address) to indicate
>   processing failure following the rules in the above paragraph.

The cited "above paragraph" isn't really about generating unsolicited MDNs.
 I would suggest "... MAY have an option to generate an unsolicited MDN
(...) to indicate processing failure, but subject to the requirement that
it MUST always be possible for an operator to disable unsolicited MDN
generation."

>2.2.2.  Recipients using Mailbox Access Protocols
>
>   A recipient using [POP3] or [IMAP4] to retrieve its mail is not
>   allowed to generate a Delivery Status Notification message [RFC1894].
>
>   The recipient MUST NOT use anything but the POP/IMAP username to map
>   to a single destination.  For example, using any RFC822 field or
>   information within the message body or MIME parts to make a decision
>   about the destination is not permitted.

While I understand its general purpose, I found this paragraph awkward,
both in intent and specific wording.  The word "single" in the first
sentence seems odd:  may be "specific" would capture the intent better?

More broadly, I am not sure that this is a reasonable requirement as
stated.  It implies, for example, that a recipient system that finds (say)
a voice message or audio/xxx content would be prohibited from forwarding it
to a local voice mail server.

Further, I am not sure that MUST NOT is appropriate for something that is
not strictly about interoperability between sender and receiver (but more
about consistency of handling by the receiver).  This is an issue that has
dogged other working groups: the extent to which an IETF specification
should dictate 'local' as opposed to 'global' requirements.  Personally, I
think that discussion of 'local' requirements is appropriate, but not at
the level of MUST.  Again, having offered a PoV, I shall try to duck out of
any "process" debate.

So, after talking around the issue, I'll attempt an alternate phrasing for
the paragraphs above:

#   A recipient using [POP3] or [IMAP4] to retrieve mail MUST NOT
#   generate a Delivery Status Notification message [RFC1894].
#
#   The recipient SHOULD NOT use any information other than the POP/IMAP
#   username to determine the destination mailbox or addressee of a message.
#   For example, no RFC822 field or other information within the message
body or
#   MIME parts should be treated as destination address information.

(BTW, as I see it, the first paragraph *is* an interoperability
requirement.  Without this, rules for responsibility to generate DSN may be
broken.)

>2.3.  Messaging Infrastructure Requirements
>
>   This section explains the requirements of the SMTP messaging
>   infrastructure used by the sender and receiver.  This infrastructure
>   is commonly provided by the ISP or a company's internal mailers but
>   can actually be provided by another organization with appropriate
>   service contracts.
>
>
>2.3.1.  Sender Infrastructure
>
>   For the sender's infrastructure to provide conformance with
....[----------------------------------------------------------
>   this document, support for DSN [RFC1891] MUST be provided by the mail
....--------------]  I think that's redundant.

>   submission server [SUBMIT] used by the sender and MUST be provided
>   up to the mailer responsible for communicating with external
>   (Internet) mailers.
>
>   Also see section 5.1 of this document.
>
>2.3.2.  Receiver Infrastructure
>
>   Support for DSN [RFC1891] MUST be provided by the external
>   (Internet-accessible) mailer, and MUST be provided by each mailer
>   between the external mailer and the recipient.  If the recipient is
>   implemented as an SMTP server it MUST also support DSN [RFC1891].
>
>3. Additional document capabilities
>
>   Section 4 of [RFC2305] only allows sending the minimum subset
...........................[-----------------] "allows sending only"

>   of TIFF for Facsimile "unless the sender has prior knowledge
>   of other TIFF fields or values supported by the recipient."
>
>   A recipient SHOULD indicate which features and values from among
>   those available in [FAX-SCHEMA] are supported using one of the
>   mechanisms defined below.
>
>   Three methods for the sender to acquire such knowledge are
>   permitted:
>
>     1.  Sender manual configuration
>     2.  Capabilities in Directory

I think some directory schema extensions will be needed.  (I have an action
to find out more about how to address this issue.)

>     3.  Capabilities returned in MDN or DSN

Reference reporting extensions memo here?

[Later: I now see these are revisited with below] 

>   In any implementation it possible for a locally-stored
............................^ "is"
>   cache of capabilities to lose synchronization with the
>   recipient's actual capabilities.  A mechanism should be
>   provided to allow the sender to override the locally-stored
>   cache of capabilities.  Also note section 4.1 of this
>   document.
>
>3.1.  Sender manual configuration
>
>   One way a sender can send a document which exceeds the minimum
>   subset allowed by [RFC2305] is for the user controlling the sender
>   to manually override the default settings, usually on a
>   per-recipient basis.  For example, during transmission a
>   user could indicate the recipient is capable of receiving
>   high resolution images or color images.
>
>   While awkward and not automatic, this mechanism reflects the current
>   state of deployment of configuration for extended capabilities to
>   ordinary Internet email users.
>
>3.2.  Capabilities in Directory
>
>   A future direction for enhanced document features is to create a
>   directory structure of recipient capabilities, deployed, for example,
>   through LDAP or DNS. The directory would provide a mechanism by which
>   a sender could determine a recipient's capabilities before message
>   construction or transmission, using a directory lookup. Such
>   mechanisms are not defined in this document.
>
>   There is active investigation within the IETF to develop a solution
>   to this problem, which would resolve a wide range of issues with
>   store-and-forward messaging.
>
>3.3.  Capabilities Returned in MDN or DSN
>
>   As outlined in section 2 of this document, a sender may request a
>   positive DSN or an MDN.
>
>   If the recipient implements [REPORTING-EXTENSIONS], the
>   DSN or MDN that is returned can contain information describing
>   the recipient's capabilities.  The sender can use this information
>   for subsequent communications with that recipient.
>
>   The advantage of this approach is that additional infrastructure is
>   not required (unlike section 3.2), and the information is acquired
>   automatically (unlike section 3.1).
>
>4. Security Considerations
>
>   As this document is an extension of [RFC2305], the Security
>   Considerations section of [RFC2305] applies to this document.
>
>   The following additional security considerations are introduced by
>   the new features described in this document.
>
>4.1.  Inaccurate Capabilities Information
>
>   Inaccurate capability information (section 3) could cause a denial
>   of service.  The capability information could be inaccurate due to
>   many reasons, including compromised or improperly configured
>   directory server, improper manual configuration of sender,
>   compromised DNS, or spoofed MDN.  If a sender is using cached
>   capability information, it SHOULD be manually confirmed by a user
>   before it is automatically used.
>
>
>4.2.  Forged MDNs or DSNs
>
>   Forged DSNs or MDNs, as described in [RFC1892, RFC1894, RFC2298]
>   can provide incorrect information to a sender.
>
>5.  Implementation Notes
>
>   This section contains notes to implementors.
>
>5.1.  Submit mailer does not support DSN
>
>   In some installations the generally available submit server may not
>   support DSNs.  In such circumstances, it may be useful for the sender
>   to implement [RFC974] mail routing as well as additional submission
>   server functions [SUBMIT] so that the installation is not constrained
>   by limitations of the incumbent submission server.
>
>5.2.  Recipient Recommendations
>
>   To provide a high degree of reliability, it is desirable for
>   the sender to know that a recipient could not process a message.
>   The inability to successfully process a message may be detectable
>   by the recipient's MTA or MUA.
>
>   If the recipient's MTA determines the message cannot be processed,
>   the recipient's MTA is strongly encouraged to reject the message with
>   a [RFC1893bis] status code of 5.6.--???-TBD-????--.  This status code
>   may be returned in response to the end-of-mail-data indicator if the
>   MTA supports [RFC2034], or after message reception by generating a
................^ Insert: "reporting of enhanced error codes"
>   delivery failure DSN ("bounce").

Question:  is there a WG dealing with RFC1893bis?
If so, what is its mailing list details?

>
>   Note:  Because DSN bounces are not requested by the sender and are
>          not 'approved' by the receiver, DSNs can provide a more robust
..............^ Insert: "required to be" ?
>          mechanism than performing this function in the MUA using MDNs.
>
>   If the message contains an MDN request and the recipient's MUA
>   determines the message cannot be processed, the recipient's MUA is
>   strongly encouraged to repond to an MDN request and indicate that
>   processing failed with the disposition-type "processed" or
>   "displayed" and disposition-modifier "error" or "warning" [RFC2298].

[...]

---end--- #g

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