-----Original Message-----
From: Alexey Melnikov [mailto:alexey(_dot_)melnikov(_at_)isode(_dot_)com]
Sent: Monday, March 05, 2012 4:00 AM
To: Murray S. Kucherawy
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: Last Call: <draft-melnikov-smtp-priority-07.txt> (Simple
Mail Transfer Protocol extension for Message Transfer Priorities) to
Proposed Standard
- There's a bunch of TBDs that still need to be resolved before this
document moves forward (X.7.TBD3 as an enhanced status code, for
example)
No, these are assigned by IANA before publication. RFC Editor will fix
these.
OK, I've just never seen that approach taken before.
- Section 4.3 says "For example, once an MTA accepts a message, the
MTA MUST NOT change a (syntactically valid) priority value if the MTA
doesn't support it." There seems to be a chicken-and-egg going on
here: If the MTA doesn't support the extension, how can it know not to
change the priority outbound?
I meant "supports the extension, but doesn't support a particular value
as distinct priority level". Suggestions on how to make this clear
would be appreciated.
Suggest:
For example, once an MTA accepts a message, the MTA MUST not change a
(syntactically valid) priority value if that value is not supported by the
MTA's implementation of this extension.
- There are lots of SHOULDs in here that might benefit from example
situations in which one might deviate from the normative statement
containing the SHOULD.
I will review. I had some discussion with SM about some of these and
argued that not all of them should be explained. But I agree that some
of them need explanation.
There are some that are in more need of this than others, and I know lately
that I've been thanked by ADs during IESG evaluation for providing this kind of
text, so it can only help where it's possible to provide it.
- Section 5 and Section 5.1 use "not required", "should", and "may"
where RFC2119 is cited earlier. Should they be in all-caps, or should
other language be selected?
Lowercased versions are not used in normative sense. Maybe a note
suggested by Barry would help with this.
Sure, and I sympathize with your reply that it triggers an ID nit. I wonder if
the IESG could agree on some text like what Barry suggested and add it to the
ID nit checker as a valid exception. Maybe 2119 should also be updated
accordingly.
- Section 11: Why use "PRI" and not "priority"? The existing set of
Received clause names are lowercase words, so it seems strange to
deviate.
I don't mind to switching to "PRIORITY". But section 4.4 of RFC 5321
uses uppercase variants (and yes, I know they are case insensitive).
I don't think I've ever seen them in the wild, which is why it caught my
attention.
- Appendix D: "This appendix and its subsections are informative." I
think that (a) any appendix is informative, because normative text
doesn't belong in an appendix; and (b) the normative stuff uses
RFC2119 language and this doesn't. Thus, I think this sentence
should be removed. (I know I've lost this argument before, but I'll make
another stand here anyway.)
I think other people already commented on this :-)
Those people are also no longer on my Christmas list. :-)
Thanks,
-MSK
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf