ietf-smtp
[Top] [All Lists]

Re: FW: I-D Action: draft-kucherawy-received-state-00.txt

2012-01-10 10:17:14



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/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net