In that case, suggest changing the OPTIONAL to something like
"RECOMMENDED if the message has been held."
But RECOMMENDED is the same as SHOULD, to which you originally objected.
Quoting Abraham Lincoln*, when a judge pointed out that he was arguing
the opposite position from one in a case earlier in the day, "Your honor,
this morning I was wrong."
It seems reasonable to use MUSTard that assumes that the reader is going
to implement this spec, in which case it's SHOULD and RECOMMENDED. Or not,
in which case it's MAY and OPTIONAL. It wasn't clear to me that you're
only expected to add the clause when you queue the message for longer
than normal, but that should be easy enough to fix.
Other nits: if this is really about deliberate delays, I'd suggest
using a term like "queued" or "delay" or "hold" rather than "state".
I can think of states that might be interesting but don't involve a
delay, e.g. characterized as spam, or downcoded from 8 bits to 6 bits.
Those aren't queueing states though; they're metadata about the message.
If I saw "state downcode", I'd conclude that the time gap implied by the
delta between adjacent Received fields indicated the amount of time that
host spent downcoding the message.
Well, yeah, but there are a lot of kind of states other than queueing
states. That's why I'd suggest a keyword that tells you this is about
queues or delays or something.
R's,
John
* - an American politician of the Victorian era, a contemporary of MacDonald