Re: [yam] Issue #10: RFC 5321 3.9: add tiny subsection

[Ned Freed <[e-mail]>]

> Hi Alessandro,
> At 08:59 06-12-2009, Alessandro Vesely wrote:
> >Yes, it would. However, it implies no protocol changes. In addition,
> >it would be a really tiny subsection.

> It's easier to compare the various iterations of the specification if
> you have, for example:

> RFC 2821 - 3.10 Mailing Lists and Aliases

> RFC 5321 - 3.9.  Mailing Lists and Aliases

> Section 3.4 is titled "Forwarding for Address Correction or
> Updating".  The tiny change you suggested might end up causing confusion.

> >I agree that "Backup MX" is a poor title, and I apologize for having
> >transferred it as-is from my notes to this list. Its most notable
> >defect is that it does not include smart hosts nor other servers
> >along the outgoing path. I'd amend the tentatively proposed titles to be
> >
> >   Forwarding
> >     Relaying   <-- "Backup MX" was here
> >     Aliases
> >     Mailing lists
> >
> >The relationship among these server's activities may now be clearer.

> Quoting Section 3.4:

>    "Forwarding support is most often required to consolidate and simplify
>     addresses within, or relative to, some enterprise and less frequently
>     to establish addresses to link a person's prior address with a
>     current one."

> What does "Forwarding" have to do with mailing lists?  What is the
> relationship between "Forwarding" and Relaying?

> Aliases and mailing lists are about address expansion.  That's also
> the point of Section 3.9.

> >The subsection would be tiny because relaying is already explained
> >in Section 3.6. It should just say that the envelope addresses are
> >left intact. Since envelope addresses are the point of Section 3.9,
> >such a simple observation would make it complete in this respect.

> I am not convinced that the group would be convinced with the tiny
> argument. :-)  Even if it implies no protocol changes, you still have
> to ensure that the text is in line with what is being said in other sections.

What I'm not seeing in any of this is a compelling case that making such a
change will make the document any clearer. The original rationale given
was a sort of symmetry argument: First a section on transfer where the
envelope addresses don't change, then one where the recipient changes, then
one where both the recipient and originator change.

Even if I were to grant that there's a close equivalency between backup MX
handling and alias expansion - which I don't - what was the confusing aspect
of this and how does this change help eliminate that confusion?

				Ned