On Apr 22, 2012, at 03:31 PM, Jeff Breidenbach wrote:

I find List-Id annoying because I like the world to be simple and easy to understand. People who know nothing about RFCs natually consider the posting address to be the canonical name of a mailing list. We should be embracing that.

In theory, I agree, which is why you'll see the posting address used as the primary key into the mailinglist table in the database. You'll almost always see that in the To: header, although some situations might cause mismatches, e.g. acceptable aliases. According to the language in RFC 2369, this also (only!) may show up in the List-Post header for the from-list copy of the message, but you might find the List-Post has nothing useful, e.g. "NO" (with some random goo of trailing comment). List-ID will always be included in the from-list copy.

Instead, RFC2369 introduces this entire alternate namespace with List-Id, competing for attention, with its own weird rules like the domain-control one quoted earlier in its thread. All this confusion, and the main problem it tried to address isn't very important. Is it really such a disaster for a list to be considered different if it hops to a new domain? I don't think so, or there would be a lot more clamoring for editable List-Id in mailman. Archival services certainly don't need it. It smells like design by committee where everyone's pet feature for a rare use case gets added in, without appreciating the benefits of small and simple and less-stuff-is-better.

Regarding hashes, the whole point of a archival hash is to make a shorter, human friendly URL. This is not very to implement; one can take the SHA-1 and truncate it. If we aren't worried about length then Message-Id is a perfectly usable identifier.

Well, Message-ID also fails the "human friendly" part, e.g. from your message:

Message-ID: CAHjiUboZzYAE1dgApzfFNMqv_X+X6xA9E1bOc3F+mQ3qcTeeeQ@mail.gmail.com

My fingers already hurt typing that into my spell-correcting smartphone. :)

FWIW, Base 32 was deliberately chosen because it's case insensitive, and allows for optional mapping of commonly mistaken substitutions (e.g. zero for oh, and one for eye or el). IOW, it's much more forgiving of the human part of the process.

Certainly no need for a triumverate of short hash, long hash, and message-id. Less is better.

Agreed. Is 32 bytes too long? Is 4 bytes too short? What's an acceptable trade-off between collision likelihood and human convenience?

-Barry