Remco Rijnders <re...@webconquest.com> wrote:
> On Sat, Jan 09, 2021 at 10:54:28PM +0000, Eric wrote in
> <20210109225428.GA27462@dcvr>:
> > This is a bad change for public mail archives which use
> > https://$SOMETHING_SOMETHING/$MSGID for robustness across
> > different public mail archives and hosts.
>
> > Having the date information in the Message-ID (and thus archive
> > URL) is an important reference for quickly identifying the
> > message date without having to open the URL itself.
> > This saves readers time and bandwidth.
>
> In my opinion the Message-ID should be just that, an ID which is so unique
> that
> clashes are very very unlikely to occur by accident and that the ID can't be
> predicted.
>
> While I agree that there might be some utility in easily identifying the
> timestamp from the Message-ID, I would also suggest the Date header is a lot
> more useful for this. Whenever I browse mailing list archives online, I
> usually
> am presented with a year and month selection first, and then see a threaded
> view
> of the messages during that period. Given how many of the other (and dare I
> say
> more widely used) email clients produce Message-ID's without a timestamp
> incorporated in them, I'd think trying to use Message-ID's in the way you
> (propose to) use them is not going to be very useful.
I'm talking about links directly to a message not going through
a particular web UI, not some web archive overview with an
unstable UI.
Of course I care about mutt the most since it's the MUA I use.
I also made a similar change to git-send-email back in 2016:
https://public-inbox.org/git/20160406200714.ga19...@dcvr.yhbt.net/
https://lore.kernel.org/git/20160406200714.ga19...@dcvr.yhbt.net/
Without opening the above URLs, you can immediately tell it's
from April 6, 2016. URLs to direct messages are frequently used
for citations and I'm glad git and Linux kernel hackers started
using URLs with Message-IDs in them.
Also, "/" in the new Message-IDs need to be encoded as "%2F"
for URLs, that adds extra cognitive overhead for reversibility
> If this is desired, I think the proper place to implement this would be by
> incorporating it into how the messages are stored in the public mail archive,
> instead of doing it by (just) the Message-ID. To use your format, something in
> the form of https://$SOMETHING_SOMETHING/YYYYmmddHHMMSS_$MSGID might work
> better and work for all possible Message ID formats.
That is not happening given the amount of prior art and existing
links which don't have that. It's also not reversible, since
an MUA could conceivably prefix "YYYYmmddHHMMSS_" in the msgid.
Yes, long URLs are a problem, and the new scheme is shorter.
The old msgids were a good trade-off between the amount of
useful information in the URL and length and still fits on
terminals for most users of giant fonts.
> > I agree adding some randomness after YYYYmmddHHMMSS is
> > necessary, and PID was a bad choice originally; but
> > YYYYmmddHHMMSS is a good prefix.
>
> The timestamp still is in there, just a little more efficiently encoded. I
> don't
> feel particulary strong on this, other than that I do feel the current
> approach
> addresses most of the concerns I had with the old format. In my view, it is
> elegant in that it packs both a timestamp and sufficient randomness in a
> limited
> amount of characters. I'm sorry that you feel this new approach is less
> useful or
> memorable.
Trying to make sense of the new timestamp requires reading the
mutt source code, the old one was easily recognizable to users
who don't know C. I was not a programmer when I started using
mutt decades ago.
The old timestamp was also useful for quickly finding
contemporary messages via substring prefix searches in the
absense of other header information (SQL LIKE 202101% or
Xapian 202101*). Allowing cases where a wildcard search is
possible for _some_ messages is better than none; especially
when I'm only looking at my own sent messages folder.
