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

Ned Freed <> Sun, 15 January 2012 16:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2605821F8474 for <>; Sun, 15 Jan 2012 08:16:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5Q7rO2i8+wUt for <>; Sun, 15 Jan 2012 08:16:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 489FA21F845E for <>; Sun, 15 Jan 2012 08:15:57 -0800 (PST)
Received: from by (PMDF V6.1-1 #35243) id <> for; Sun, 15 Jan 2012 08:15:54 -0800 (PST)
Received: from by (PMDF V6.1-1 #35243) id <>; Sun, 15 Jan 2012 08:15:51 -0800 (PST)
Message-id: <>
Date: Sun, 15 Jan 2012 07:53:41 -0800 (PST)
From: Ned Freed <>
In-reply-to: "Your message dated Sat, 14 Jan 2012 16:48:23 -0800" <>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format=flowed
References: <> <F5833273385BB34F99288B3648C4F06F19C6C15859@EXCH-C2.corp.cloudmar> <> <AD693E95D4252DC3E8F3832F@PST.JCK.COM> <>
To: Dave CROCKER <>
Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 15 Jan 2012 16:16:16 -0000

> On 1/13/2012 10:53 AM, John C Klensin wrote:
> > SMTP rather carefully defines "trace information" or "trace
> > headers" and then limits that category to two types of

> What is the import of this observation, relative to the current proposal?

> You appear to be intending it as a constraint, but I don't understand how,
> specifically.

> > In any event, we have discovered repeatedly (and sometimes
> > painfully) that the the Received header field is not well
> > designed for extensibility.

> I don't recall seeing these claims before or documentation that they are valid.
>   Can you provide some citations?

While I am unaware of any standards usage of this particular extensibility
feature, ever since it was defined there has been some ad-hoc use of it. I have
not observed any issues with this usage. To the extent there have been
problems, it's been with obsolete forms that have never worked well and jsut a
general failure to implement basic stuff like date-time parsing propoerly.

> Note that the definition of the Received: header field provides a registry for
> addition of new clauses, so you appear to be saying that extensibility is not
> viable.

If that's indeed the case, then this is a serious problem that trascends the
present discussion. Consider: The claim is that a fairly important feature of a
particalur standard cannot be used because if it is sure to cause
interoperability problems. If so, then this pretty clearly fails to meet the
criteria for standards advancment: Stuff like this is supposed to be removed,
redone, or at least severerly restricted before advancing past proposed. At an
absolute minimum the registry would need to be closed to new entries.

> >        It depends on an ordered,
> > context-dependent, reserved keyword model (something I don't

> If you are saying that the specific placement of the clause is essential, then
> please document this requirement -- beyond what is in the RFC5321 spec and the
> proposed clause spec -- both in terms of what you believe is acceptable and
> different from the current specification and also the basis for this.


> >       we should have a serious discussion about how far
> > we want to go in extending "Received:" and when it is time to
> > add one or more additional Trace header fields, possibly with a
> > typology of functions that each serves (beyond "inserted by a
> > transit MTA or something else") and

I have found additional header fields to be be more problematic than extending
Received:. For one thing, agents tend to assume that Received: is the only
field deserving such treatement and many do not even have a list of additional
fields to copy when moving trace information around. (And this operation does
happen in various cases.) And even if such a list is maintained, there's always
the update problem when a new trace field is defined.

For another, while it's fairly safe to rely on headers of the same type
staying in the same order, the same cannot always be said for fields of
different types.

> Please review the latest version, specifically the 'Discussion' section, which
> provides exactly the consideration you are calling for.

>  >      with a syntax that is
> > clearly name-value based, rather than even partially dependent
> > on parser recognition of specific keywords.

> I don't understand the requirement you are proposing, since the "name" of a
> name/value pair is a specific keyword.  Hence, your saying "rather than" appears
> to be contradictory.

> You seem to be meaning something else, but I can't guess what.

> > Let's not turn "Received:" further into a kludge just because it
> > is there.

> How is it already a kludge?

Whether or not it is a kludge is of precisely zero interest to me. It's the
mechanim we have. We have a problem to solve here, and unfortunately all of the
possible solutions have issues. In my judgement out of all the available
options the best is to extend Received:, messy syntax and all. All of the other
options, including but not limited to additional trace fields, replacing
Received: with something else, replacing Received; while retaining generation
of Received; for backwards compatibility, are even worse.

And the worst option is effectively saying that addttional trace information
can never be added again. That would really suck.