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]

 



On 01/03/2012 20:49, Barry Leiba wrote:
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?
Agreed.
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.
I don't mind changing that, but ID-nits gives a warning when the text about keywords is changed and *everybody* likes to complain about that. Please talk to IESG about whether using a variant of the standard text is acceptable.
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.
Agreed.
-----
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.
Thanks, I've used your text.
-----
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.
Ok, I will try to use your suggestion.
-----
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.
Changed, thanks.
-----
Editorial:
OLD
Such actions usually need user confirmation.
NEW
Such actions usually require user interaction.
Ok.
-----
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.
Removed as per reply to Pete.
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."
Ok.
-----
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.
Ok.
And I would add to the second paragraph, "But note that use of the
DELIVERBY extension alone does not guarantee any priority processing."
Added.

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

 [snip]

Thank you,
Alexey

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