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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf