-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jul 24, 2007, at 2:56 AM, Stephen J. Turnbull wrote:
I simply think we should be prepared for applications where relying on the sender to supply a UUID is not acceptable; we need to be able to provide one ourselves. Creating UUIDs is a solved problem, after all. So we just specify a header to put it in, and subscribers will be able to use it, per definition of a canonical URL.
Then we say that an archive SHOULD provide access to the resource via Message-ID if available, and define how to construct that URL from the List-Archive and Message-ID headers.
I think there's two approaches we could argue for. One is for the
mailing list manager to craft a UUID out of whole cloth and stick
that in a header. Then any downstream archiver would be obliged to
use that header value as the canonical address of the message, with
an alternative path to the message via the Message-ID (possibly
returning a list of matching messages when there are collisions).
The second approach, and the one that I favor, is to use the Message-
ID (and the Date) header on the original message as the UUID,
properly handling corner cases like duplicate headers or missing
header. This UUID servers as the basis for the address to the
message resource just like above.
I like the second approach better because in the case where you start
with an off-list copy of the message, you have a decent enough chance
of getting to the archived message, or at least to a resource
containing a link to the message. The first alternative would
require access to the list copy.
Imagine if every archiver supported my proposal, knowing just the
Message-ID and Date header, you could get to that message from almost
anywhere, just by using the UUID as a relative URL rooted at say
http://www.mail-archive.com, http://groups.google.com, http:// mail.python.org/pipermail, or whatever. That would be pretty neat.