+1 Dave.
My Take:
1) This should be a MAY implement
2) It can only be a SHOULD with a presumption of other ideas already
existing.
Its like I MAY build a house, and if I do, I SHOULD do certain things
expected in building a house.
This should not say I SHOULD build a house.
Dave CROCKER wrote:
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 SHOULD.
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/ specification?
And then there is the usual debate about degree of importance that
guides must/may/should.
My take:
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 use, later.
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' should suffice.
d/
--
Sincerely
Hector Santos
http://www.santronics.com
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net