Re: Last Call: <draft-melnikov-smtp-priority-07.txt> (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I had expected that we'd deal with my shepherd review before doing the
last call on the document.  Because that didn't happen, I'll re-post
my review here, as public last-call comments.  Maybe that will prevent
people from raising the same things I've already raised.

First, two additional points:

1. As to Murray's comment about explicitly declaring text to be
informative, I'm with Tom on this: I think it's at worst harmless, and
possibly very useful as a clarification, to explicitly say "this
[paragraph, section, whatever] is not normative."  It might be
unnecessary, but where's the harm?

2. I, too, noticed all the lower-case "should" and "may" words.  I
suggest that the best way to handle this is to make the following
change to the RFC 2119 citation text at the beginning of section 2:

NEW
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119] when they appear
   in ALL CAPS.  These words also appear in this document in lower case as plain
   English words, absent their normative meanings.

My review, which was already sent to Alexey and Pete:

----------------------------------------------------------------

Section 4.1
  1.  A conforming SMTP server SHOULD NOT refuse a MAIL command based
      on the absence of the PRIORITY parameter.

I agree with Pete's MUST NOT -- also because at this point, the server
has no idea whether the message is coming from a non-supporting
server, and whether or not there's an MT-Priority header field in the
message.  This really needs to be MUST NOT.

-----
Section 4.4
  1.  A PRIORITY parameter MUST NOT appear in the MAIL command issued
      when relaying the message.

  2.  The relaying MTA MUST first remove any and all existing MT-
      Priority header fields from the message, and then add its own MT-
      Priority header field with the value determined by the procedure
      in Section 4.2.  One exception to this rule is that a message
      which didn't contain any MT-Priority header field and which
      didn't have the PRIORITY MAIL FROM parameter specified doesn't
      need to be updated to contain the "MT-Priority: 0" header field.
      Syntax of the MT-Priority header field is specified in Section 7.

Because of the exception, I think there's a slight unclear point here
(and I also don't like the passive voice in bullet 1).  Let me re-work
this thus:

NEW
  1.  The relaying MTA MUST NOT use the PRIORITY parameter in the
      MAIL command issued when relaying the message.

  2.  The relaying MTA MUST first remove any and all existing MT-
      Priority header fields from the message.

  3.  If the message had a PRIORITY specified in the MAIL FROM
      parameter *or* there was an MT-Priority header field
      removed in step 2, then the relaying MTA MUST add its own
      MT-Priority header field with the value determined by the
      procedure in Section 4.2.

      The syntax of the MT-Priority header field is specified in
      Section 7.

-----
Section 5.
  A message priority is a decimal integer in the range from -9 to 9
  (inclusive).  SMTP servers compliant with this specification are not
  required to support all 19 distinct priority levels (i.e. to treat
  each priority value as a separate priority), but they MUST implement
  at least the following 6 distinct priority levels: -4, -2, 0, 2, 4,
  9.  I.e. an implementation that only supports the 6 priority levels
  will internally treat all syntactically valid priority values below
  and including -4 as priority -4, priorities -3 and -2 as priority -2,
  priorities -1 and 0 as priority 0, etc., with all priorities starting
  from 5 are treated as priority 9.  An SMTP server MAY support more
  than 6 different priority levels.  Decision about which levels to
  support in addition to the 6 mentioned above is a local matter.

There's a lot of stuff after the "I.e.", much of which can be changed
to just say that a syntatically valid level that isn't supported gets
raised to the next higher supported number.  Say that, and it all
looks clearer and easier.

-----
Editorial:
OLD
  Note: 19 possible priority levels are defined by this specification
  for extensibility, for example if a particular implementation or
  deployment environment needs to provide fine grainer control over
  message transfer priorities, for example a server implementation may
  need to have an extra high priority level to the 6 levels defined
  above.

NEW
  Note: 19 possible priority levels are defined by this specification
  for extensibility. For example, a particular implementation or
  deployment environment might need to provide finer-grained control
  over message transfer priorities.  In such a case, a server
  implementation might need an extra priority level beyond the 6 levels
  defined above.

-----
Editorial:
OLD
Such actions usually need user confirmation.
NEW
Such actions usually require user interaction.

-----
Section 5.1
  As a default policy, emails with higher priority waiting to be sent
  by a client SHOULD NOT initiate transactions for emails with lower
  priorites.  If two or more emails with the same priority are ready to
  be sent at the same time, the MTA should use its regular algorithm
  (the algorithm used in absence of this SMTP extension) for deciding
  how to send them out.

I have no idea what the first sentence means.  For the second
sentence, I would say it like this: "Within a priority level, the MTA
uses its normal ordering for the messages."

-----
Section 5.2
Editorial:
OLD
  An important constraint (usually associated with higher priority
  levels) is, that messages with that priority have to reach its
  destination within a defined period of time.  In some cases, higher
  priorities mean shorter maximum allowed time of delivery.
NEW
  An important constraint (usually associated with higher priority
  levels) is that messages with high priority have some delivery
  time constraints.  In some cases, higher priorities mean a shorter
  maximum time allowed for delivery.

And I would add to the second paragraph, "But note that use of the
DELIVERBY extension alone does not guarantee any priority processing."

-----
Section 6
I would switch sections 6 and 7, to avoid the forward reference in the
current section 6.

-----
Section 8. Example
I'd like to see an example that includes multiple hops, and that
includes transit across an MTA that doesn't support this.  Perhaps a
life-cycle example: MUA -> MSA -> MTA1 -> MTA2 -> MTA3 -> MDA, where
MTA2 does not support the priority extension.  Maybe:
MSA is mail.alertservice.example
MTA1 is outbound.alertservice.example
MTA2 is relay.backbone.example (doesn't support)
MTA3 is mx1.isp.example
MDA is mailbox5.isp.example

The one simple example doesn't convey much that's useful about how the
various bits work, and especially how the parameter tunneling works.
(You'll also need to provide message headers in the DATA section in
order to show that.)  I think it makes for a bulky Examples section,
but I think it's important.

I think I would do this as separate subsections:
8. Example
8.1 Message Submission
8.2 Relay to Internet Edge MTA
8.3 Relay through Internet Backbone
8.4 Relay to ISP's Edge MTA
8.5 Delivery to ISP User's Mailbox

-----
Section 10
I think the SMTP parameters should match the header field, and all be
MT-PRIORITY.  I'm not going to fight about it, though.

-----
Section 12.1
I am concerned that we're somewhat overloading DKIM here, by asking an
MTA to DKIM-sign a message *solely* to protect the value of one
specific header field.  That's a bit of a stretch, and causes some
level of problem in some cases.  Consider the example above, and
suppose that MSA DKIM-signs the message, with no MT-Priority header
field.  Now MTA1 has to add MT-Priority in order to relay to MTA2, and
it DKIM-signs it again... but perhaps only covering the "from" and
"mt-priority" fields.  None of that is a *huge* deal, but it just
strikes me as an odd use of DKIM, which goes beyond the semantics we
put on it.

----------------------------------------------------------------

Barry, document shepherd
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]