diff options
Diffstat (limited to 'public/index.atom')
| -rw-r--r-- | public/index.atom | 78 |
1 files changed, 77 insertions, 1 deletions
diff --git a/public/index.atom b/public/index.atom index 6423bca..dd10c2c 100644 --- a/public/index.atom +++ b/public/index.atom @@ -5,12 +5,88 @@ <link rel="self" type="application/atom+xml" href="./index.atom"/> <link rel="alternate" type="text/html" href="./"/> <link rel="alternate" type="text/markdown" href="./index.md"/> - <updated>2023-07-10T00:00:00+00:00</updated> + <updated>2024-06-08T00:00:00+00:00</updated> <author><name>Luke T. Shumaker</name><uri>https://lukeshu.com/</uri><email>lukeshu@lukeshu.com</email></author> <id>https://lukeshu.com/blog/</id> <entry xmlns="http://www.w3.org/2005/Atom"> + <link rel="alternate" type="text/html" href="./message-threading.html"/> + <link rel="alternate" type="text/markdown" href="./message-threading.md"/> + <id>https://lukeshu.com/blog/message-threading.html</id> + <updated>2024-06-08T00:00:00+00:00</updated> + <published>2024-06-08T00:00:00+00:00</published> + <title>Notes on email message threading</title> + <content type="html"><h1 id="notes-on-email-message-threading">Notes on email message +threading</h1> +<blockquote> +<p>I sent an email to Jamie Zawinski with feedback on his venerable +email threading algorithm. Perhaps my commentary will be a useful +reference to others implementing email threading.</p> +<p>You can see my implementation of his algorithm at <a +href="https://git.lukeshu.com/www/tree/cmd/generate/mailstuff/thread_alg.go" +class="uri">https://git.lukeshu.com/www/tree/cmd/generate/mailstuff/thread_alg.go</a> +(and a use of it at <a +href="https://git.lukeshu.com/www/tree/cmd/generate/mailstuff/thread.go" +class="uri">https://git.lukeshu.com/www/tree/cmd/generate/mailstuff/thread.go</a>).</p> +</blockquote> +<div style="font-family: monospace"> +<p>To: <a href="https://www.jwz.org/">Jamie Zawinski</a> <a +href="https://www.jwz.org/about.html">&lt;jwz@jwz.org&gt;</a><br/> +Subject: message threading<br/> Date: Sat, 08 Jun 2024 22:34:41 -0600 +Message-ID: &lt;87tti2ybry.wl-lukeshu@lukeshu.com&gt;</p> +</div> +<p>Hi,</p> +<p>I'm implementing message threading, and have been referencing both +your document <a +href="https://www.jwz.org/doc/threading.html">&lt;https://www.jwz.org/doc/threading.html&gt;</a>; +and <a href="https://datatracker.ietf.org/doc/html/rfc5256">RFC +5256</a>. I'm not sure whether you're interested in updating a document +that's more than 25 years old, but if you are: I hope you find the +following feedback valuable.</p> +<p>You write that the algorithm in RFC 5256 is merely a <q>restating</q> +of your algorithm, but I noticed 3 (minor) differences:</p> +<ol type="1"> +<li><p>In your step 1.C, the RFC says to check whether this would create +a loop, and if it would to skip creating the link; your version only +says to perform this check in step 1.B.</p></li> +<li><p>The RFC says to sort the messages by date between your steps 4 +and 5; that is: when grouping by subject, containers in the root set +should be processed in date-order (you do not specify an order), and +that if container in the root set is empty then the subject should be +taken from the earliest-date child (you say to use an arbitrary +child).</p></li> +<li><p>The RFC precisely states how to trim a subject down to a "base +subject," rather than simply saying <q>Strip ``Re:'', ``RE:'', +``RE[5]:'', ``Re: Re[4]: Re:'' and so on.</q></p></li> +</ol> +<p>Additionally, there are two minor points on which I found their +version to be clearer:</p> +<ol type="1"> +<li><p>The RFC specifies how to handle messages without a Message-Id or +with a duplicate Message-Id (on <a +href="https://datatracker.ietf.org/doc/html/rfc5256#page-9">page 9</a>), +as well as how to normalize a Message-Id (by referring to <a +href="https://datatracker.ietf.org/doc/html/rfc2822">RFC 2822</a>). This +is perhaps out-of-scope of your algorithm document, but I feel that it +would be worth mentioning in your background or definitions +section.</p></li> +<li><p>In your step 1.B, I did not understand what <q>If they are +already linked, don't change the existing links</q> meant until I read +the RFC, which words it as <q>If a message already has a parent, don't +change the existing link.</q> It was unclear to me what <q>they</q> was +referring to in your version.</p></li> +</ol> +<div style="font-family: monospace"> +<p>-- <br/> Happy hacking,<br/> ~ Luke T. Shumaker<br/></p> +</div> +</content> + <author><name>Luke T. Shumaker</name><uri>https://lukeshu.com/</uri><email>lukeshu@lukeshu.com</email></author> + <rights type="html"><p>The content of this page is Copyright © 2024 <a href="mailto:lukeshu@lukeshu.com">Luke T. Shumaker</a>.</p> +<p>This page is licensed under the <a href="https://creativecommons.org/licenses/by-sa/4.0/">CC BY-SA 4.0</a> license.</p></rights> + </entry> + + <entry xmlns="http://www.w3.org/2005/Atom"> <link rel="alternate" type="text/html" href="./btrfs-rec.html"/> <link rel="alternate" type="text/markdown" href="./btrfs-rec.md"/> <id>https://lukeshu.com/blog/btrfs-rec.html</id> |