[Mailman-Developers] From the creation of a ThreadID

[Stephen J. Turnbull]

On Tue, Apr 10, 2012 at 12:28 AM, Barry Warsaw <barry at list.org> wrote:
> On Apr 09, 2012, at 07:10 AM, Richard Wackerbarth wrote:
>
>>I support the concept of Stable URI.
>
> Should we attempt to push the stable URI concept as an RFC?  Does anybody
> (Murray perhaps) have the interest and time to do that?  I think the RFC would
> be pretty simple.

I don't think we have sufficient agreement on how to implement yet.

> Having an RFC would also be nice for getting rid of the X- prefix.

AIUI, the X- prefix is now considered a bad idea for public protocols
in any case.  I don't think we need an RFC for it until we're pretty
sure we have it right.

> In any event, we can declare the algorithm on our current wiki page to be
> version 1.0 of our stable URI definition.  Archiver search algorithms can
> expose this version number in their URLs if they're so inclined.

IMHO, our stable URIs should work on any of the servers we might
connect to to retrieve the message.  In terms of best current
practice, Gmane has offered stable URLs for about a decade now:

    http://msgid.gmane.org/20120409152339.16496.75486@foo.example.org

To put it on the wire to Gmane, just URL-encode the message-id and be
done with it.  IMO, the ideal would be just like netnews:

    list-archive://mailman-developers.python.org/20120409152339.16496.75486@foo.example.org

The List-ID is not entirely redundant due to cross-posting.

In this scheme, it's up to the MUA to decide which archive(s) to query
for this, just as with netnews looking for a newsgroup.  I really
don't see why the stable URI would want to be anything else.

So the scheme on the wiki seems overengineered to me, with the
possible exception of the "industrial-strength message IDs are too
long for the footer" problem.  But

http://mail.example.com/1.0/7GC2V6BEDVME27VQ34W7AXMFPA3H2YWW

is really too long for a footer too; what we want are tinyurls.  So I
think that footer URLs should be considered a different problem from
the stable URI problem.