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

From: Graham Klyne <[email-masked]>
Date: Wed, 11 Nov 1998 18:03:27 +0000

Some editorial nit-picks...

#g
--

>draft-ietf-fax-eifax-10.txt
>
>
>                 Extended Facsimile Using Internet Mail

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

This definition seems a little odd.  Intuitively, "processing" means the
_action_ of rendering or transmitting.

Within this memo, I note that "processing" is sometimes used in the sense
stated here (as in "processing confirmation"), and sometimes in the sense
of actually processing (as in "device which performs the processing
function").  Forms of "processing" or "processed" in this memo are in many
cases qualified if ability-to-process is being described.

Thus, I would suggest:

#   The term "processing" indicates the action of rendering or
#   transmitting the contents of the message to a printer, display device,
#   or fax machine.

and

#   The term "processing confirmation" is an indication by the
#   recipient of a message that it is able to process the contents
#   of that message.

>   The term "recipient" indicates the device which performs the
>   processing function.  For example, a recipient could be implemented
>   as a traditional Mail User Agent on a PC, a standalone device which
>   retrieves mail using POP3 or IMAP, an SMTP server which prints
>   incoming messages (similar to an LPR server).

>2.1.  Sender Requirements
>
>   A delivery failure message (in the format described by [RFC1894] or
>   otherwise) may be sent to the envelope-from address specified by the
...............^^^ is this a "MAY"?
>   sender.  Thus, the envelope-from address supplied by the sender MUST
>   be able to properly handle such delivery failure messages.
>
>2.1.2.  Processing Confirmation
>
>   If the sender desires processing confirmation, the sender MUST
>   request Message Disposition Notification [RFC2298 section 2]
>   when sending the message itself.
>
>   Because a recipient may silently ignore a request for an MDN [section
>   2.1 of RFC2298] at any time:
>     *  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
>        done so in the past.
>
>   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 (due to the
>   existence of legacy systems that generate non-RFC2298-compliant
>   responses to the Disposition-Notification-To field).

Should we also say that the address provided in
"Disposition-Notification-To" must match the SMTP return path address?
Otherwise, unattended receiving systems cannot send disposition
notifications without violating RFC2298 (I think).

This is from RFC2298, section 2.1:

   MDNs SHOULD NOT be sent automatically if the address in the
   Disposition-Notification-To header differs from the address in the
   Return-Path header (see RFC 822 [2]).  In this case, confirmation
   from the user SHOULD be obtained, if possible.  If obtaining consent
   is not possible (e.g., because the user is not online at the time),
   then an MDN SHOULD NOT be sent.

   Confirmation from the user SHOULD be obtained (or no MDN sent) if
   there is no Return-Path header in the message, or if there is more
   than one distinct address in the Disposition-Notification-To header.

>3.  Additional document capabilities
>
>   Section 4 of "A Simple Mode of Facsimile Using Internet Mail"
>   [RFC2305] allows sending only the minimum subset of TIFF for
>   Facsimile "unless the sender has prior knowledge of other TIFF fields
>   or values supported by the recipient."
>
>   A recipient MAY support any or all (or any combination) of the TIFF
>   profiles defined in RFC 2301, in addition to profile S.  A recipient
>   which supports additional profiles SHOULD indicate this support as
>   per section 3.2 or 3.3 of this document.  As a consequence, a sender
>   MAY use those additional TIFF profiles when sending to a recipient
>   with the corresponding capabilities.
>
>   A sender SHOULD be able to recognize and process the feature tags as
>   defined in [FAX-SCHEMA] when reviewing the capabilities presented by
>   a potential recipient.  The capability matching rules indicated there
>   (by reference to [CONNEG-FEATURE-SYNTAX]) allow for the introduction
>   of new features that may be unrecognized by older implementations.
>
>   A sender MAY send a message containing both the minimum subset of
>   TIFF for Facsimile (as specified in [RFC23035]) and a higher quality
>   TIFF using multipart/alternative.
>
>   Three methods for the sender to acquire such knowledge are
>   described:
>
>     1.  Sender manual configuration
>     2.  Capabilities in Directory
>     3.  Capabilities returned in MDN or DSN
>
>   Method (3) SHOULD be used.
>
>   An implementation may cache capabilities locally and lose
>   synchronization with the recipient's actual capabilities.  A
>   mechanism should be provided to allow the sender to override the
..............^^^^^^ SHOULD ?
>   locally-stored cache of capabilities.  Also note section 4.1 of this
>   document.

>3.3.1.  Restrictions and Recommendations
>
>   A sender MUST NOT send a message with no processable content to
>   attempt to elicit an MDN/DSN capability response.  Doing so with a
>   message with no processable content (such as a message containing
>   only a request for capabilities or a blank message) will confuse a
>   recipient not already designed to understand the semantics of such a
>   message.
>
>   A recipient SHOULD indicate the profiles and features supported,
>   even if the recipient supports only Tiff Profile S (the minimum
>   set for fax as defined by [RFC2305]) [FAX-SCHEMA].  This allows
>   a sender to determine that the recipient is compliant with
>   this specification.

Could "this specification" be ambiguous here?  Maybe "the eifax
specification" or similar?

>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 [RFC1893] status code of 5.6.1.  This status code may be returned
>   in response to the end-of-mail-data indicator if the MTA supports
>   reporting of enhanced error codes [RFC2034], or after message
>   reception by generating a delivery failure DSN ("bounce").
>
>   Note:  Providing this functionality in the MTA, via either of the
>          two mechanisms described above, is superior to providing the
>          function using MDNs because MDNs must be requested by the
>          sender (and the request may, at any time, be ignored by
>          the receiver).  Message rejection performed by the MTA can
>          always occur without the sender requesting such behavior
>          and without the receiver circumventing the behavior.

This comment is mildly inconsistent with what is said earlier:  unsolicited
MDNs are said to be permitted when processing failure occurs.

#g

---

From: Dan Wing <[email-masked]>
Date: Wed, 11 Nov 1998 15:19:36 -0800 (PST)

> #   recipient of a message that it is able to process the contents

Done.

> >   be able to properly handle such delivery failure messages.

I am unclear on what exactly you're commenting on, but does this phrase
at the beginning of the sentence help to satisfy your concern?

   Because delivery failure may occur (over disk quota, user no longer
   exists, malconfigured mailer), a delivery failure message ....

> notifications without violating RFC2298 (I think).

You're right.  I will add the following sentence:

   The Disposition-Notification-To address and the envelope-from 
   address SHOULD match to allow automated responses to MDN
   requests (section 2.1 of [RFC2298]).

> >   locally-stored cache of capabilities.  Also note section 4.1 of this

Yes, changed.

> specification" or similar?

Changed to "... this Extended Facsimile Using Internet Mail
specification".  I am not using EIFAX because of the trademark concern of
the IETF-FAX WG.

> MDNs are said to be permitted when processing failure occurs.

Yes, but generation of MDNs (unsolicited or solicited) may be disabled
by the recipient (the end user).  Generation of DSNs indicating a message
isn't processable would be controlled by the system administrator or
postmaster and wouldn't be as easily circumvented by the end user.  That's
all I was trying to say. 

I'm not tied to the above Note and will remove it if it is contentious.

I am submitting eifax-11 with Graham's above comments (but with the
Note in section 5.2 as-is).  The only other changes are to Larry's fax
number and to capitalize the titles of all sections.

-Dan Wing