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. 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. Certainly no need for a triumverate of short hash, long hash, and message-id. Less is better. On Apr 21, 2012 2:53 AM, "Stephen J. Turnbull" <step...@xemacs.org> wrote: _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
