Re: [yam] RFC 5321 (was: [Editorial Errata Reported] RFC5321 (1820)

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

--On Saturday, 01 August, 2009 12:46 +0200 Alessandro Vesely
<[e-mail]> wrote:

>...
> Frank Ellermann noted the added phrase, and commented about it
> on April 26, 2007
> 
>   That's a point where you could mention that this used to be
> no
>   key difference under RFC 821, because "in any case, the SMTP"
>   added "its own identifier to the reverse path".  There might
> be
>   better places to explain that RFC 1123 broke the original
> SMTP
>   design in its quest to get rid of the source routes.
> 
> That was the concern of the discussion, rather about concepts
> than wording. In facts, Frank used to note discrepant usages
> of terms (e.g. "return path" vs "reverse path", in the same
> message) but missed also this spurious "backward-pointing
> address". (Currently, there are exactly three occurrences of
> the word "backward" in RFC 5321.) I found no other thread
> mentioning that phrase. John replied
> 
>   Send text, but my inclination is to not change this further,
>   especially to reflect the long-dead "copy own address into
>   reverse-path stuff".
> 
> That's it, almost. Frank had dropped that point in his further
> reply. I jumped on that list months later, after Frank's
> suggestion. I independently noted that phrase and had tried to
> leverage on its inconsistency for introducing a conceptual
> change which had been rejected.

Alessandro,

It is precisely the interconnection between this tiny change and
"the 1123 decision was a mistake" (something that DRUMS declined
to open and that no one has gotten traction for opening since)
and the terminology about rerouting email at various levels that
makes me unwilling to treat changes in this area as anything but
substantive and needing WG review.  That would be the case even
if I had reviewed the text in question (which I have not) and
agreed with you.

For those who haven't been following this closely, the 1123
issues was the change that turned Return-path in RCPT from
   <@relay3,@relay2,@relay1:local-part@domain>
to
   <local-part@domain>
regardless of the path taken.  My guess is that some of us would
argue that the change was absolutely correct, others would argue
that it is much too late to reconsider whether it was the right
decision at the time or not, and still others would argue that,
in this world of hostile or unwanted messages with faked
headers, the decision should be revisited and changed.  I've
fairly sure that split would make it very hard to get enough
consensus to make a change but I, at least, would not oppose
revisiting it if we could do so in a highly-focused way.

But I'm simply not going to make _any_ change in this area
unless the WG has discussed it and the Chairs have told me what
to do.

One of my tasks for the last several days is to assemble a
template for the revision of 5321.  That template is basically
the starting point for the notification/request to IESG (for
convenience, I just posted the most recent version into the WG
Wiki (http://trac.tools.ietf.org/wg/yam/trac/wiki)

I will include, in some form, a statement to the effect that we
will review terminology changes made between RFCs 821 and 2821
and between 2821 and 5321 where appropriate to determine whether
the WG is still happy with them and that some small changes are
possible on that basis.  Assuming the WG and IESG agree with
that characterization, that should eliminate the procedural
issue, permit us to concentrate on the substance and, as SM
suggests, hold a discussion in the context of the forthcoming
draft.

   john