On Tuesday, December 11, 2018 at 21:08:16 +0100, Mihai Lazarescu wrote:
On Tue, Dec 11, 2018 at 12:29 AM Derek Martin <inva...@pizzashack.org> wrote: > > On Wed, Dec 05, 2018 at 05:31:28PM +1100, Erik Christiansen wrote: > > Thread comment: It's OK to be unaware of the usefulness of RFC features, > > but it does seem odd to pretend that they're not useful just because > > it's only others who need them. > > I'm not entirely sure what you mean by this, but for the sake of > clarity about RFC features, here's what RFC 2822 says on the matter > (3.6.3, paragraph 6): > > When a message is a reply to another message, the mailboxes of the > authors of the original message (the mailboxes in the "From:" > field) or mailboxes specified in the "Reply-To:" field (if it > exists) MAY appear in the "To:" field of the reply since these > would normally be the primary recipients of the reply. If a reply > is sent to a message that has destination fields, it is often > desirable to send a copy of the reply to all of the recipients of > the message, in addition to the author. When such a reply is > formed, addresses in the "To:" and "Cc:" fields of the original > message MAY appear in the "Cc:" field of the reply, since these are > normally secondary recipients of the reply. > > It recomments Mutt's current behavior I disagree on "recommends". Actually "may", as modal verb, is used to express *possibility* or used to ask or give *permission* (or is used to make a *suggestion* or suggest a *possibility* in a polite way): https://dictionary.cambridge.org/us/dictionary/english/may Either way, in the RFC it expresses an option, an acceptable alternate behavior to the (implicit, because it's obvious) behavior, which is to preserve the distinction between Cc: and To:. Distinction which, BTW, the same RFC states beyond doubt (see the relevant quote in my previous message in thread).
Seems like I'm talking to myself, :-) but I just learned that RFC 2119 (thanks Francesco for the pointer) https://www.ietf.org/rfc/rfc2119.txt explains "Key words for use in RFCs to Indicate Requirement Levels". Specifically, RFC 2119 says the following about "MAY":
«5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.»
So mutt implements as default and mandatory a "truly optional" alternate behavior allowed by RFC 2822. And for sure the said behavior is not the "recommended" one, as implied in this thread.
Mihai
