-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jul 24, 2007, at 2:03 PM, Jeff Breidenbach wrote:
Regardless of whether we *need* to generate our own unique ID, I'm leaning towards the thought that we're going to *want* to generate our own for usability reasons. In a perfect world, i think we'd have a sequence number so I could visit http://example.com/mailman/ archives/listname/204.html and know that 205.html would be the next message to that list, but any short unique id would do if sequence numbers are too much of a pain.
I agree there's a lot of usability benefits from short URLs, but
perhaps this is the job of the archive server, and not the list server.
Mharc (an archive server) is a great example here. Mharc's canonical message format is pretty human friendly.
Unfortunately, there's no trivial way for the list server to know
that human friendly URL when the message is sent out. Fortunately, Mharc is also happy handles messages by message-id, which the list server does know about.
Had I been the implementer, I'd probably have made mharc do an HTTP
302 redirect from the longer URL to the shorter URL. But that's besides
the point. The point is we have an existing, working, happy archival server,
and it would be really nice if list servers (such as mailman) were compatible.
And by compatible, I mean offering the capability of embedding an archival
URL in the footers of messages.
I agree, I just don't think message-ids are user friendly enough to
be this canonical url. Especially in this context, which is exactly
where urls are thrown in users faces. An archiving service is
exactly the right place for redirecting human readable urls to the
archiver's canonical url (by, I agree, 302).