Subject: Re: [EAI] smtpext and Received headers

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 16 Oct 2007 09:57:35 +0800

----- Original Message ----- 
From: "Tony Hansen" <[email-masked]>
To: "EAI WG" <[email-masked]>
Sent: Tuesday, October 16, 2007 5:57 AM
Subject: [EAI] smtpext and Received headers

> 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,

if section 2.7.3 is simplified, you mean that 2821bis will also be extended to define the fields below ?
             uReturn-path-line = "Return-Path:" FWS uReverse-path 
             uTime-stamp-line = "Received:" FWS uStamp 
              uStamp 
            
if so,  does it mean that 2821bis will allow UTF-8 character in the Received headers?

> 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
>

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 15 Oct 2007 22:11:48 -0400

--On Tuesday, 16 October, 2007 09:57 +0800 YAO Jiankang
<[email-masked]> wrote:

>...
>> 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,
> 
> if section 2.7.3 is simplified, you mean that 2821bis will
> also be extended to define the fields below ?

No, of course not.  What would happen is that 

<Time-stamp-line> and <Stamp> would remain unchanged, but
<Opt-info> would turn into

   Opt-info       = [Via] [With] [ID] [For]
                  [Additional-Registered-Clauses] 

Then one could define uFor in smtpext as one of those
<Additional-Registered-Clauses>, presumably with a prohibition
on For appearing if uFor does.

It looks as if we need to do the Additional-registered-clauses
bit for 2821bis anyway, so a different version of Tony's
question is whether it can be used to considerably simplify the
syntax --and number of apparent changes -- in smtpext.

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.  But we have come to the conclusion
that consensus on the mailing list favors eliminating multiple
addresses in "for" as a mistake in 2821.  That change will
appear in draft-klensin-2821bis-05.txt, when it appears, as well.

best,
      john