Subject: [EAI] smtpext and Received headers

From: Tony Hansen <[email-masked]>
Date: Mon, 15 Oct 2007 17:57:49 -0400

John Klensin and I have been discussing a point in 2821-bis, in
particular regarding the extensibility / non-extensibility of Received:
headers.

Consider these points:

 *) Smtpext, as currently defined, is building a replacement syntax for
    the Received: header in section 2.7.3.
 *) As time marches on, smtpext and smtp-bis/ter/etc would need to stay
    in sync.
 *) There have been extensions to the Received: syntax published in the
    past (e.g., rfc 1428), but it was never codified into the 2821
    syntax.
 *) Smtpext could be expressed more cleanly if it were defined in terms
    of an extension to the Received: syntax instead of replacing the
    Received :syntax.
 *) There has been discussion on the SMTP mailing list about codifying
    the extensibility of the Received: header.

Our thinking is that section 2.7.3 of eai-smtpext could be simplified
drastically if Received: were defined in 2821bis as being properly
extensible, and uFor were written in terms of
[Additional-registered-clauses]. I, for one, think the latter would be
preferable to having multiple sort-of-simpatico definitions for Received:.

I know that the smtpext draft is already past WGLC, but John also
happens to be in the queue for working on the doc. So if the group
decides this change is worth doing now before IETF-wide last call, it
could get taken care of quickly.

	Tony Hansen
	[email-masked]

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 16 Oct 2007 07:29:27 +0200

Tony Hansen wrote:

> if Received: were defined in 2821bis as being properly extensible,
> and uFor were written in terms of [Additional-registered-clauses].
> I, for one, think the latter would be preferable to having multiple
> sort-of-simpatico definitions for Received:.

Makes sense.  But as John wrote later:

| Before someone asks, none of this works if "For" can have more
| than one address because, if it does, the semicolon is needed to
| terminate the address list.

The cleanest solution could be a separate RFC explaining this, with
the usual rules for the (existing) IANA registry.  2821bis could
then say that the Received clauses are now defined in RFC xxxx, and
EAI could be the first "client" of RFC xxxx registering its "uFor".

For obvious reasons the registry has to allow experimental clauses.
Does that make sense ?

 Frank