-----Original Message-----
From: John Levine [mailto:johnl(_at_)taugh(_dot_)com]
Sent: Monday, January 09, 2012 9:13 PM
To: ietf-smtp(_at_)imc(_dot_)org
Cc: Murray S. Kucherawy
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
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. The
"if the message has been held" is implicit in the idea that this is only used
if some kind of administrative hold has been imposed (rather than caused by a
transport anomaly).
I just changed it to MAY, on the grounds that it will probably be user/admin
pressure that gets the feature added rather than something normative (e.g.,
nobody requires this, but all the cool kids do it).
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.
Also, it might be a good idea to have a state name for no delay, e.g
"queued none", both for the benefit of dorky software that always wants
to put the same set of clauses in its Received: headers, and to provide
an explicit way to say hey, this delay wasn't my idea.
That's not a bad idea. Thanks.
-MSK