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

From: Alessandro Vesely <[email-masked]>
Date: Sat, 01 Aug 2009 12:46:37 +0200

SM wrote:
> Hi Alessandro,
> At 01:56 31-07-2009, Alessandro Vesely wrote:
>> searching for "3.9.2" on mail-archive brings only up previous 
>> discussions between you and me on the same subject. You rejected all 
>> of them on various reason, e.g. because the last call had already been 
>> issued, or because of the nature of the forwarding model as expressed 
>> in http://www.mail-archive.com/[email-masked]/msg00468.html. I 
>> never found the discussion where that paragraph has been introduced, I 
>> guess it was not public.

I hadn't searched well enough...

> There were some comments (most likely off-list) on that section prior to 
> the message at the above URL.

The above URL is dated Sat, 16 Feb 2008 07:17:43 -0800. Much later 
than the phrase containing the typo, which I quote again:

                                                    Note that
  the key difference between handling aliases (Section 3.9.1) and
  forwarding (this subsection) is the change to the backward-pointing
  address in this case.

NOTE: This phrase appears _twice_ in RFC 5321. Its second instance is 
much further down in section 4.4, around lines 3282-3284 of the 
numbered draft. Please concede that at least this second occurrence 
has to be removed completely...

That phrase can be found in the differences from -02 to -03, in 
http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-klensin-rfc2821bis-03.txt#diff0057 
Version -02 is of April 17, 2007, -03 is of April 25, 2007, hence any 
message discussing that issue should be archived in 
http://www.imc.org/ietf-smtp/mail-archive/mail5.html. In facts, there 
is a message entitled "RFC2821bis-02 Issue 26: Source routes, 
especially reverse-paths" by John C Klensin, 04/22/2007. That was 
actually concerned with "Appendix C. Source Routes". The text quoted 
above presumably belongs to other "editorial and related changes to 
improve clarity and consistency", in that version's changes.

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.

P.S.: This is the first time I spell Frank's name on a public list 
message since September last year. So I also add the ietf-smtp list in 
CC; please change the subject appropriately if replying about this 
last paragraph. I haven't been able to gather any news about Frank, 
and I'm afraid to understand that the common saying "no news is good 
news" doesn't apply in this case.

---

From: SM <[email-masked]>
Date: Sat, 01 Aug 2009 15:12:02 -0700

Hi Alessandro,
At 03:46 01-08-2009, Alessandro Vesely wrote:
>NOTE: This phrase appears _twice_ in RFC 5321. Its second instance 
>is much further down in section 4.4, around lines 3282-3284 of the 

In my personal opinion, it is better to wait for the editor of RFC 
5321 to post an I-D before commenting on the phrase you mentioned in 
your Errata.  We can then discuss the issue within the Working Group 
as it has been chartered to work on the document.

It might be a good idea to read the YAM Charter, if you have not done 
so, as it discusses about document changes.  Section 4.4 has some 
text about gateways. Given the complexity of the matter, I'll need 
some time to look into it.

>  design in its quest to get rid of the source routes.

I recall that.  He raised Issue 26.  There was a short discussion about it.

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

If he dropped that point in his reply, he must have had good reasons 
for doing so.

As it has been a long week, I may have read your message 
incorrectly.  The above covers much more than the Errata you reported.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 02 Aug 2009 11:38:15 +0200

Hi SM!
SM wrote:
>> the phrase containing the typo, which I quote again:
>>
>>                                                    Note that
> In my personal opinion, it is better to wait for the editor of RFC 5321 
> to post an I-D before commenting on the phrase you mentioned in your 
> Errata.  We can then discuss the issue within the Working Group as it 
> has been chartered to work on the document.
>
> It might be a good idea to read the YAM Charter

I'd agree on waiting for an I-D, but the Charter's description 
mentions a "list of proposed changes" a couple of steps _before_ that. 
I have no idea how to reach that list, except by posting here.

> Section 4.4 has some text 
> about gateways. Given the complexity of the matter, I'll need some time 
> to look into it.

Not really, you can tell it's a typo at a glance.

> If he dropped that point in his reply, he must have had good reasons for 
> doing so.

When a concept results from compromises and historical restraints, it 
is difficult to quietly consider its wording without also revisiting 
long chains of related conceptual issues. Dropping is a useful 
shortcut in such cases. That's also how typos --Freudian slips-- come 
about.

Even if more than two years have gone by, I don't think the WG would 
be willing to revise section 3.9 any deeper than correcting typos.

> As it has been a long week, I may have read your message incorrectly.  
> The above covers much more than the Errata you reported.

Technically, I only added the second occurrence of the phrase, which I 
hadn't been aware of when I reported the Errata. I only exhumed the 
context to recall that the use of the term "forwarding" to refer to 
subsection 3.9.2 had probably never been discussed, nor meant.

---

From: SM <[email-masked]>
Date: Sun, 02 Aug 2009 15:59:07 -0700

Hi Alessandro,
At 02:38 02-08-2009, Alessandro Vesely wrote:
>mentions a "list of proposed changes" a couple of steps _before_ 
>that. I have no idea how to reach that list, except by posting here.

Here's a personal comment about the Charter.  It is about advancing 
email-related RFCs that are currently at Draft Standard to Full 
Standard.  There are fifteen documents being worked on.  RFC2821bis, 
for example, required three years of work.  If the documents are 
targeted as three sets, it might take nine years to reach that 
goal.  The view during the discussions leading to the formation of 
the WG was that it could be done in less time if the WG can quickly 
reach consensus about further work on a document.  If that cannot be 
done, the document gets dropped.  Some of these documents have 
dependencies on other documents.  That's why there is an order in 
processing them and some batch processing.  There are also some steps 
for optimal processing.

One of the steps in the "procedure" is to formulate a list of 
proposed changes (stated in general terms, rather than specific 
wording).  If you believe that the list is the editor's or reviser's 
flavor of what the specification should look like, it's far from 
that.  There are some constraints on what can be changed when a 
document moves from Draft Standard to Full Standard.  Some of the 
documents have been published several years ago and there are some 
intricacies in updating them.  The documents require more than the 
acceptance of the Working Group.  They have to go through the normal 
publication process.

Discussions within the IETF are inclusive and not exclusive.  This 
means that everyone has a voice.  The "list of proposed changes" will 
be posted to the mailing list for comments.  We all have the 
opportunity to raise issues and put forward our arguments.  There 
will also be I-Ds posted for the Working Group consideration which 
means that everybody will be able to comment on them.

The Charter mentions the scope.  It's there for practical 
reasons.  RFC 5321 contains 95 pages.  There is the risk of breaking 
stuff when revising it.  If the fix involves making existing 
conforming implementations non-conforming, the Working Group will be 
creating problems instead of solving them.

I hope that the above gives you a better picture.

Regards,
-sm