On Tue 11 Feb 2020 at 07:36:49 (-0800), pe...@easthope.ca wrote: > > * From: Andrei POPESCU > * Date: Mon, 10 Feb 2020 21:43:11 +0200 > > Without In-Reply-To a mail reader has no way to which message the reply > > belongs, so it's more important than References. > > Please look at the Web view of your reply. (If your mailer linkifies > this URL, click on it. Otherwise open your browser and copy-paste > this URL.) https://lists.debian.org/debian-user/2020/02/msg00375.html > > In-reply-to and References identifiers are identical. > Both are E1j1Dus-00018Y-T8@dalton.invalid. Correct? > > A Web page isn't email but the Web presentation is consistent with > https://tools.ietf.org/html/rfc5322#section-3.6.4 , Identification Fields. [*] > Here is an excerpt. > > The "In-Reply-To:" field will contain the contents of the > > "Message-ID:" field of the message to which this one is a reply (the > > parent message"). ... > > > > The "References:" field will contain the contents of the parent's > > "References:" field (if any) followed by the contents of the parent's > > "Message-ID:" field (if any). > > The RFC also mentions the unusual case of a reply to multiple parents. > > If there is more than one parent message, then the "In-Reply-To:" > > field will contain the contents of all of the parents' "Message-ID:" > > fields. > But the paragraph for References neglects that case. ("parents'" vs. > "parent's") >8~( In debian lists, I've never noticed an instance of > multiple identifiers for the In-reply-to field. If you find one, > please post a link. (For my taste, one parent per reply is enough. > Multiple replies for multiple parents.) So, provided a reply is to > only one parent, the last identifier of References is identical to the > identifier of In-Reply-To.
Er, there was at least one posted here within the last week: https://lists.debian.org/debian-user/2020/02/msg00189.html That's just one that happened to still be in my inbox. > OK, I'll rise to the bait. Will send a variant of this reply with the > In-Reply-To field omitted from the header. If the list software > parses References cleverly, it will thread both cases the same. =8~) > If the software requires In-Reply-To, the thread will be broken in the > variant. >8~( > > Regards, ... P. > > [*] Except that the mailing list has "In-reply-to" whereas the RFC > sticks to "In-Reply-To". Not too harmful. Case-sensitivity is a harmless myth that's always being perpetuated, it seems. RFC 5322 §1.2.2. Syntactic Notation This specification uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation for the formal definitions of the syntax of messages. Characters will be specified either by a decimal value (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by a case-insensitive literal value enclosed in quotation marks (e.g., "A" for either uppercase or lowercase A). § 3.6.4. Identification fields in-reply-to = "In-Reply-To:" 1*msg-id CRLF RFC 5322 § 2.3. NOTE: ABNF strings are case insensitive and the character set for these strings is US-ASCII. Hence: rulename = "abc" and: rulename = "aBc" will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and "ABC". To specify a rule that is case sensitive, specify the characters individually. For example: rulename = %d97 %d98 %d99 or rulename = %d97.98.99 will match only the string that comprises only the lowercase characters, abc. Cheers, David.
