On 05/03/2012 18:00, Murray S. Kucherawy wrote:
-----Original Message-----
From: Alexey Melnikov [mailto:alexey.melnikov@xxxxxxxxx]
Sent: Monday, March 05, 2012 4:00 AM
To: Murray S. Kucherawy
Cc:ietf@xxxxxxxx
Subject: Re: Last Call:<draft-melnikov-smtp-priority-07.txt> (Simple
Mail Transfer Protocol extension for Message Transfer Priorities) to
Proposed Standard
- 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.
Ok, changed.
- 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.
Sure. I've asked for explanation while I was on IESG as well.
- 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.
I've changed "PRI" to "PRIORITY" in my copy.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf