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

From: Dan Wing <[email-masked]>
Date: Mon, 5 Oct 1998 23:59:02 -0700

Internet Fax WG,
Keith (see below),

Summary: new Internet Draft has been submitted (see another message),
and differences are in ftp://ftp-eng.cisco.com/dwing/eifax.diff

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

Changed.

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

Changed.

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

Changed.

>[...]
>>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"?

Changed.

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

Changed.

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

Changed.

>>   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"?

Changed.

>>   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"?

Changed.

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

Agreed and changed.

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

Changed.

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

Changed.

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

Some guidance from Keith would be appreciated here - I was trying to
add wording which expressly prohibited using the RFC822 To: header
for processing, which has horrible problems (especially with 
mailing lists and alias files).

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

But this does affect interoperability.  

If a receiver will only process a message if its address appears in
the RFC822 "To:" line, but the receiver is on a mailing list (which
doesn't expand the RFC822 "To:" line to all the recipients but leaves
it alone, which is the normal operation of mailing lists, such as
[email-masked]), there will be no interoperability. 

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

Changed.

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

How about this for the second paragraph:

   The recipient MUST NOT use the RFC822 "To:" field to determine
   the ultimate destination mailbox or addressee, and SHOULD NOT use 
   other RFC822 or MIME fields for making such determinations.

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

Changed.

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

Changed.

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

Changed to:

   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
   locally-stored cache of capabilities.  Also note section 4.1 of this
   document.

[...]
>>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?

No, Greg V. is doing this himself, but I'm sure it'll be reviewed
by the old NOTARY working group's mailing list.  

>If so, what is its mailing list details?

To subscribe send mail to [email-masked] with the
word SUBSCRIBE in the body. 

>>   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" ?

RFC821 requires non-delivery-notifications always be sent - it isn't
an option by the receiving mailer to _not_ generate a non-delivery 
notification message.

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

Thanks for your comments!

-Dan Wing