Re: Next steps in IETF list email archiving

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> We already have a perfectly good mail encoding, the one defined in
>> RFC 5322 and its predecessors.  (Recall that MIME is entirely hidden
>> inside the 5322 message structure.)  I suppose you could come up
>> with a convention for filenames, [...]

MH nailed down that standard decades ago.  One message per file, in a suitable directory hierarchy. E.g.

  ietf/<listname>/<year>/<nn>

This avoids the ambiguity of mbox message separator escapes (the '>From' problem), but creates a lot of overhead for things like rsync.

But for a public archive interface, why aren't/can't we use anonymous IMAP, with a folder structure as above?  This hides the underlying storage format.  It provides search capabilities to naïve clients, and it's easy to write mirroring tools.  It's trivial to make mirroring decisions based on UIDVALIDITY and UIDNEXT; the mirroring tool is essentially an offline IMAP client.

> Are there any RFCs specifying how mirrors can point to each others so
> folks retrieving the information can load-balance/failover etc.. That ws
> pretty much the level i was suggesting, and its certainly an orthogonal
> problem.

For the IMAP case, the fanout happens behind the scenes, with the list exploder feeding the IMAP archive servers by Submission is almost every case.  This doesn't guarantee complete synchronization between all the public IMAP servers, but they will be close enough in daily operation to be useful.  Certainly this is no different from load balancing across public anonymous FTP servers.

If people want local mirrors, there are already tools out there for remote-syncing IMAP accounts that could be easily adapted to the task.  But I'm sure lots of people would cook up dedicated tools in short order.

--lyndon




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]