because the "name" is a URL, it _will_ be different for different
access schemes. I'm expecting that the archiver will have to know
about the access methods that are available.
I think that's a significant practical problem. I have outlined
a means of implementing access to an archive of mailing list
messages via a half dozen URI schemes using off-the-shelf
software packages. Adding an Archived-At field with IMAP, POP,
and perhaps NNTP URIs would certainly require modification --
perhaps extensive -- but is probably feasible [1,2]. Expecting an
IMAP local delivery archiver to possess detailed information
about ftp, http, etc. access methods and configuration is a bit
much; again, probably feasible, but not without a considerable
amount of modification.
when I know how to implement a mail archiver that not only stores the archive
in a file but adds the archived-at fields and forwards the mail to the list
expander in a few lines of script, I have a hard time believing it's so
onerous.
1. A news URI referring to the message identifier would be
trivial; however it would also be nearly useless for remote
access as the news URI scheme has no provision for
specifying host or port. Likewise for the mid URI scheme,
which is indistinguishable (when referring to an entire message)
from the specific variety of news scheme URI mentioned here.
defining a new URI scheme that says "use NNTP to find this message-id
at this host and port" would not be rocket science. and since we already
pretty much know that existing UAs do not support the ability to access
mail archives at URIs, backward compatibility would not be an issue.
though I'm still partial to using FTP and HTTP.
Keith