On 1/9/2012 10:50 PM, Murray S. Kucherawy wrote:
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).
Mumble. Although I can see the merit in choosing MAY, I suggest you revert to
This is a point of continuing confusion. Does the normative language in an
extension spec mean "relative to the overall service" or "relative to /this/
And then there is the usual debate about degree of importance that guides
If we think use of the STATE clause is nice but not all that important,
then the normative word should be MAY. If we think this can have significant
benefit and especially when widely adopted, the word should be SHOULD.
We could argue that email has done well enough without it for many years, so
this should be MAY. We could also argue that obscure delays are a significant
problem and that the current scale of Internet mail and challenges in diagnosing
problems means that it's important to guide potential implementers about the
importance of implementing this.
I prefer SHOULD.
We need better insight into mail transit.
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.
The choice of word affects possible later use. STATE makes is reasonable to
consider other uses. DELAY or HOLD constrain the used. QUEUED strikes me as
synonymous with STATE, actually.
Those aren't queueing states though; they're metadata about the message.
I think I don't understand what this means.
The choice of the word STATE does imply that there is a grand state machine that
describes handling of the message and that this annotation records the timing of
a transition through it. The implication is correct.
While the motivation for this annotation is to account for unusual delays, I do
not see why the semantics of the clause label needs to be limited to that more
constrained semantic. Using the more general label does not make the software
for the clause more complex; but it does make it easier to consider extended
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.
Use of the clause requires a new Received header field. The condition the
'none' value seems intended for is for typical header fields as are generated
today. Either these should get meaningful labels or the existing label 'other'