Do Sections 6.1 and 6.2 of 5321bis require clarification and/or rewriting? Notably to eliminate "frivolous"?

[klensin]

As part of a Last Call comment, Don Eastlake wrote:

'Section 6.1, 6.2: I do not quite understand saying that something is mandatory/required and then talking about where it is impossible or impractical to do that thing. Section 6.1 says, concerning a host holding an email message, "It MUST NOT lose the message for frivolous reasons, such as because the host later crashes ...". "frivolous" does not seem very well defined for a mandatory implementation requirement. The only examples given later of non-frivolous reasons seem to be spam or "hostile" (infected?) messages. Maybe this should be more like "In so far as practical, messages MUST NOT be accidentally lost. For example, messages and their processing state should be committed to non-volatile storage until responsibility is taken for that message by the next host in the delivery path." or something like that. In Section 6.2, how does it make sense to say that something is required and impractical?'

WG, note fwiw, that text comes, substantially unchanged, from RFC 1123.

In a followup message, Donald wrote:

'6.2 could be trivially fixed by simply replacing "requires that messages that can be delivered should be delivered" with "benefits when messages that can be delivered are delivered". I do note that this "requires" statement does not use a capitalized keyword and is softened by the lower case "should". I did not notice any self-contradiction as egregious as this elsewhere in the document.'

There is additional discussion in the messages between Donald and myself on the Last Call list. WG?

[toddherr]

Contribution from Murray in chat during Friday 11/7 session at IETF:

"It must take this responsibility seriously. It MUST endeavor to retain any message for which it has accepted responsibility, which implies design capable of withstanding any reasonable failures such as later host crashes or predictable resource shortages. Further discussion appears in Section 7.8."

[brong]

Old Text:

   When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
   message in response to DATA), it is accepting responsibility for
   delivering or relaying the message.  It must take this responsibility
   seriously.  It MUST NOT lose the message for frivolous reasons, such
   as because the host later crashes or because of a predictable
   resource shortage.  Some reasons that are not considered frivolous
   are discussed in the next subsection and in Section 7.8.

Proposed Text:

   When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
   message in response to DATA), it is accepting responsibility for
   delivering or relaying the message. This is a serious responsibility.
   The message MUST be preserved until the next system has taken
   responsibility, or the message has been deliberately discarded,
   in a way which is robust against predictable failure modes (such as
   reboots, server crashes, disk failures, or resource shortages.)

   Some reasons that a receiver-SMTP may choose not to deliver or relay a
   message are discussed in the next subsection and in Section 7.8.

[toddherr]

I would wordsmith Bron's text as follows:

   When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
   message in response to DATA), it is accepting responsibility for
   delivering or relaying the message. This is a serious responsibility.
   The message MUST be preserved in a way which is robust against 
   predictable possible loss (such as reboots, server crashes, disk failures, 
   or resource shortages.) until the next system has taken responsibility or 
   the message has been deliberately discarded.

   Some reasons that a receiver-SMTP may choose not to deliver or relay a
   message are discussed in the next subsection and in Section 7.8.

Main change was from "predictable failure modes" to "predicate possible loss" and moving that clause closer to that which it modifies ("in a way which is robust")

[brong]

I would take out the word "possible" - "predictable loss" is fine. and the extra - but I like it. My updated proposal:

   When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
   message in response to DATA), it is accepting responsibility for
   delivering or relaying the message. This is a serious responsibility.
   The message MUST be preserved in a way which is robust against 
   predictable loss (such as reboots, server crashes, disk failures, 
   or resource shortages) until the next system has taken responsibility, or 
   the message has been deliberately discarded.

   Some reasons that a receiver-SMTP may choose not to deliver or relay a
   message are discussed in the next subsection and in Section 7.8.

[toddherr]

I concur with Bron's latest proposal

[klensin]

Latest text above incorporated into working draft.

[klensin]

Dave Crocker proposed, in email, different text:

'When the receiver-SMTP sends a "250 OK", in response to a DATA command, they are accepting responsibility for delivering that piece of mail, for relaying to the next email handling agent that takes further responsibility for it, or for judiciously deciding to discard the message, possibly also returning a failure notification to the SMTP Mail From address. Responsibility includes robustness against predictable loss, such as reboots, server crashes, disk failures, or resource shortages.'

[klensin]

Comment on Dave's proposal: For those whose main objection to the prior text was the lack of precision and testability of "frivolous". is "judicious" appreciably better?

[klensin]

Title changed to split off Ticket #122 and separate off the question of how normative Section 6.1 is (including the use of "MUST") in that ticket from motivating terminology such as "frivolous" in this one.