On Sat, 2011-11-19, Hector wrote:
Murray S. Kucherawy wrote:
-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Bill
McQuillan
Sent: Saturday, November 19, 2011 11:50 AM
To: SMTP Discussion
Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt
Since the motivation for the "state" sub-field is to help figure out
why gaps in the Received: date-time stamp sequence occured, I think
that knowing for sure whether the named "state" is responsible for the
gap BEFORE the current Received: date-time stamp or AFTER that date-
time stamp is crucial.
I'm guessing my earlier suggestion was inadequate. So how's this:
3. New Trace Clause
This memo creates a new trace field clause, called "state", which can
be used to indicate the nature of a delay imposed on relaying of a
message toward its recipient(s). It is followed by a single keyword
that provides that detail. An MTA or other handling agent that
determines a message is about to enter a state other than normal
queueing of messages for delivery SHOULD generate a trace field
including one of these clauses. That is, the presence of this clause
on a trace field is an indication of the entry of the message into
that state; a later trace field added would indicate its departure
from that state.
-1
That has to be a MAY - not a SHOULD. There is no requirement to
honor, nor technical requirement to follow this whatsoever with a
SHOULD mandate. There is no interoperability issue to required it,
there is no *pain* to justify it and the *cost* is high in code
change. Same thing can be done with other headers as it already is
where required.
While I would *encourage* an MTA to add this sub-field I have to
agree with Hector that it does not qualify for SHOULD. Other than
that, the paragraph satisfies my concerns about the meaning of the
sub-field.
--
Bill McQuillan <McQuilWP(_at_)pobox(_dot_)com>