Subject: [apps-discuss] draft-ietf-appsawg-received-state-03

From: Bill McQuillan <[email-masked]>
Date: Sat, 23 Jun 2012 17:58:32 -0700

In section 3, end of the first paragraph:

                                          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.

This seems to imply that there is some "End of State" trace field 
to be inserted when the processing is complete. I would suggest 
changing "a later trace field" to "any later trace field" or 
perhaps "some later trace field".

-------------------------------------------------------------------

In the next paragraph:

   Appropriate use of this mechanism does not include associating meta-
   data with the message, such as categorizing the message (e.g., the
   notions of "is spam" or "was 8-bit, converted to 7-bit").

seems, in spirit, to be in conflict with the later paragraphs in 
the same section:

   A transfer agent making use of this extension MAY also include header
   field comments to provide additional information.

   The "value" is available for providing additional labels as
   explanation for the state transition.  Examples could include:

   o  convert/unicode2ascii

   o  moderation/not-subscribed

   o  quarantine/spam

At least to me, these "values" and "header field comments" are 
exactly that sort of meta-data. Since the "meta-data" is likely 
to be useful, I suggest removing the earlier paragraph.

-------------------------------------------------------------------

In section 4, third paragraph:

   Rather, an agent that wishes to make a state annotation SHOULD add
   only a single Received header field including such annotation, thus
   indicating (a) the time of completion of its handling of the message
   via the date portion of the field, and (b) the final disposition of
   that message relative to that agent.  For example, an MTA receiving a
   message that performs various checks on the message before
   immediately handing it off to a Mailing List Manager (MLM) would only
   record a "normal" state, assuming it passes those checks.  The MLM
   would then evaluate the message and record its own state once it
   decides what the next step will be for the handling of that message.

This seems to imply that the trace field will be added at the 
*end* of the state to explain the previous delay. I thought that 
the intent was to add the state subfield to the trace field when 
*entering* some possibly lengthy processing step.

-- 
Bill McQuillan <[email-masked]>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 23 Jun 2012 22:36:21 -0700

> perhaps "some later trace field".

The next Received field indicates the exit from that state.  Consider MLM
moderation: release of the message from moderation lands it in an MTA's
outbound queue, which generates a new Received field.

There's a difference between "queued for conversion" and "was converted".
We're explaining the reason a processing delay occurred, not tagging the
message itself in some way.  You could in theory have two opposite
conversions occur (say, through a tunnel of some kind) that cancel each
other out; you'd have to parse all of that to figure out the state of the
content.  Thus, that's not what this is for.

When a handling agent finishes with a message, it's in some kind of state.
That might be queued for next hop ("normal"), or it might be any of the
example hold reasons the document identifies.  That's the point of entry of
that message into that state, even if it is not the beginning of the cycle
of handling of the message by that agent.

-MSK