bug#64454: 30.0.50; In-Reply-To header obsolete content

bug#64454: 30.0.50; In-Reply-To header obsolete content

[Andrew Cohen]

When replying to an email, gnus constructs an In-Reply-To: header that
contains the message-id of the originating email followed by a phrase of
the form:

(User's  message of "Wed, 17 Nov 2021 22:16:04 -0800")

While allowed, the addition of this parenthetical phrase has been made
obsolete as of RFC5322. I suggest removing it, or wrapping it in a
defcustom 'message-strict-rfc5322. Any preferences?

-- 
Andrew Cohen

bug#64454: 30.0.50; In-Reply-To header obsolete content

[Robert Pluim]

>>>>> On Tue, 04 Jul 2023 14:11:35 +0800, Andrew Cohen <acohen@ust.hk> said:

    Andrew> When replying to an email, gnus constructs an In-Reply-To: header that
    Andrew> contains the message-id of the originating email followed by a phrase of
    Andrew> the form:

    Andrew> (User's  message of "Wed, 17 Nov 2021 22:16:04 -0800")

    Andrew> While allowed, the addition of this parenthetical phrase has been made
    Andrew> obsolete as of RFC5322. I suggest removing it, or wrapping it in a
    Andrew> defcustom 'message-strict-rfc5322. Any preferences?

Iʼd remove it, document its removal, but have a defcustom to get it
back.

Robert
-- 

bug#64454: 30.0.50; In-Reply-To header obsolete content

[Eli Zaretskii]

> From: Andrew Cohen <acohen@ust.hk>
> Date: Tue, 04 Jul 2023 14:11:35 +0800
> 
> 
> When replying to an email, gnus constructs an In-Reply-To: header that
> contains the message-id of the originating email followed by a phrase of
> the form:
> 
> (User's  message of "Wed, 17 Nov 2021 22:16:04 -0800")
> 
> While allowed, the addition of this parenthetical phrase has been made
> obsolete as of RFC5322. I suggest removing it, or wrapping it in a
> defcustom 'message-strict-rfc5322. Any preferences?

If you decide to remove it, please make that conditional on a
defcustom, so that interested users will have a way to get back old
behavior, when they need that.

Thanks.

bug#64454: 30.0.50; In-Reply-To header obsolete content

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Tue, 04 Jul 2023 14:11:35 +0800, Andrew Cohen <acohen@ust.hk> said:
>
>     Andrew> When replying to an email, gnus constructs an In-Reply-To: header that
>     Andrew> contains the message-id of the originating email followed by a phrase of
>     Andrew> the form:
>
>     Andrew> (User's  message of "Wed, 17 Nov 2021 22:16:04 -0800")
>
>     Andrew> While allowed, the addition of this parenthetical phrase has been made
>     Andrew> obsolete as of RFC5322. I suggest removing it, or wrapping it in a
>     Andrew> defcustom 'message-strict-rfc5322. Any preferences?
>
> Iʼd remove it, document its removal, but have a defcustom to get it
> back.
>
> Robert

Could it still be relevant when interacting with clients that confirm to
that rfc?

bug#64454: 30.0.50; In-Reply-To header obsolete content

[Robert Pluim]

>>>>> On Sun, 17 Sep 2023 02:51:00 +0300, Björn Bidar <bjorn.bidar@thaodan.de> said:

    Björn> Robert Pluim <rpluim@gmail.com> writes:
    >>>>>>> On Tue, 04 Jul 2023 14:11:35 +0800, Andrew Cohen <acohen@ust.hk> said:
    >> 
    Andrew> When replying to an email, gnus constructs an In-Reply-To: header that
    Andrew> contains the message-id of the originating email followed by a phrase of
    Andrew> the form:
    >> 
    Andrew> (User's  message of "Wed, 17 Nov 2021 22:16:04 -0800")
    >> 
    Andrew> While allowed, the addition of this parenthetical phrase has been made
    Andrew> obsolete as of RFC5322. I suggest removing it, or wrapping it in a
    Andrew> defcustom 'message-strict-rfc5322. Any preferences?
    >> 
    >> Iʼd remove it, document its removal, but have a defcustom to get it
    >> back.
    >> 
    >> Robert

    Björn> Could it still be relevant when interacting with clients that confirm to
    Björn> that rfc?

I donʼt see how: that RFC makes that phrasing obsolete, so there will
no doubt be a client that at some point interprets the header
strictly, in which you donʼt want to be outputting the old format, so
we should output the new one by default.

Robert
--