Re: [apps-discuss] Adoption of draft-kucherawy-received-state?

[John C Klensin <[e-mail]>]

--On Wednesday, January 18, 2012 15:20 -0800 "Murray S.
Kucherawy" <[e-mail]> wrote:

>> First, my concern was that loading too much disparate
>> information into "Received:", and especially intermixing
>> post-delivery MUA information with in transit MTA information
>> might not be a sufficiently good idea that we should do it
>> automatically and without thinking.   I didn't say "don't do
>> it", especially wrt this specific proposal.  I did suggest
>> that it was worth examining the question.

> I had thought there was objection to doing the received-state
> work by using Additional-Registered-Clauses, when my own MTA
> implementation experience suggests to me that it's actually
> ideal and that a new header field wouldn't be right for this.
> Rather, what I'm seeing now is just an observation that the
> whole "trace field" thing is a little under-defined and we
> need to fix that.  I can buy that if we agree the two topics
> are in fact separate.

First, this is exactly the discussion I wanted to encourage.
There is a huge difference, IMO, between "MTA implementation
experience suggests to me that it's actually ideal and that a
new header field wouldn't be right for this" and "let's push
this into "Received:" because "Received:" is there.  

And, yes, the topics are mostly -- but not entirely-- separate.

> And an interesting observation: When I wrote RFC5451, my goal
> was to call Authentication-Results a trace field specifically
> because preserving the order of addition of Received fields
> with this mixed in is an important hint to figuring out where,
> and perhaps why, message authentication work ran into
> problems.  So I only wanted to piggyback on the "don't reorder
> or change this" rule that had already been laid out rather
> than re-stating it.  However, it also has an end-user purpose,
> which you correctly called post-delivery MUA information.
> That part isn't exactly trace information per se, or maybe it
> is but it's actually MUA-actionable.  So that header field is
> actually a mix of both types of header field, I suppose:
> Agents should all follow trace header field handling rules,
> but it actually contains actionable stuff.  I'm hoping it
> doesn't thus deserve its own hybrid category...

While I share your hope that it does not, the other line that is
being crossed here is between "used primarily for debugging" (a
phrase that, if I recall, appears both in 5321 and 821) in
contexts that imply "mostly  parsed and interpreted by humans"
and "actionable by MUAs" (which implies a lot of parsing and
interpretation by machines).  The tradeoffs may still favor
putting everything in "Received:" header fields, or my favor
splitting it up in some way.  I actually don't have a position
on the subject; I am only asking that we discuss it rather than
dropping into an accidental default.

> One reason I prefer a Received extension for the received
> state work is because moving it into its own header field
> requires repetition of a bunch of information (hostname and
> date, for starters) that's already present in a corresponding
> Received field.  Thus, it seems it would add more clutter than
> it's worth to go that route.

Makes sense.

>> So what I was suggesting, and continue to suggest, is that it
>> may be time to think about whether it is better to keep
>> adding fields to "Received:" or whether one or more
>> additional header fields are in order.
> 
> I think perhaps the amalgamated draft we seem to see forming
> between John's and SM's proposals might do well to talk about
> situations where each approach (Additional-Registered-Clause
> vs. new header field) is more appropriate.

If that happened, my concern and, for this issue, interest would
shift entirely to the discussion of that draft and away from
your specific draft.
 
>> The advantage is that something that wants to find one of
>> these things for processing purposes would know exactly where
>> to look, rather than having to parse "Received:" fields,
>> looking for the relevant information, and trusting that
>> someone hasn't used the same <Additional-Registered-Clauses>
>> for something else (despite the SHOULD NOT) in 5321 Section
>> 4.4).
> 
> So far since the parsing of Received is mostly 1*(key value)
> up until the date part, parsing hasn't been a problem for
> systems I've worked on.  Most systems appropriately ignore
> things they don't understand.  However, naturally, I don't
> claim to speak for anything more than a fraction of the
> Received parsers out there.

Ack.

    john