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