ietf
[Top] [All Lists]

Next steps in IETF list email archiving

2017-07-19 02:43:49
Several years ago, we identified a set of issues with the way
we were archiving email messages and new functionality that a
searching and browsing solution should contain. The initial
requirements for improvements were captured in RFC 6778, and a
subsequent round of requirements were captured in RFC 7842.

One of the key issues was (and is) related to management of
the archives.  Currently if a message has to be removed
(rare, but not as rare as we would like due to spam hitting
some lists), the secretariat has to touch many places. One
of those is Mhonarc. Touching one message there involves
changing many files (any other message that contains a
navigation link to this one, and the index files that speak
about the message).

As we built the new systems, we've targeted having one source
of truth for the archives. For instance, as we added IMAP
access to the archives (RFC 7017), we ensured that it was
served from the same bits used by mailarchive.ietf.org.  It
has been our expectation from the beginning that
mailarchive.org would replace the Mhonarc archives (see
section 2.7 of RFC 6778).

We believe we are getting close to the point where we can
make that replacement. The rate of bug reports and feature
requests for mailarchive.ietf.org is slow. (As we do for
the datatracker, we plan to continuously improve the
mailarchive interface. We know already of some things that
need to be improved when viewing on phone-sized displays.)

If you use the mhonarc archives heavily, and have not yet
explored mailarchive.ietf.org, we encourage you to do so now,
and report any difficulties you find. We recognize that the
experience is different, but many of the RFC 7842 driven
improvements focused on minimizing the transition pain.

We have successfully tested the code that will redirect all
existing Mhonarc URLs into the mailarchive using the
testlist.

We are not going to make this transition immediately, but
we do plan to make it more in the near future than the far
future. Please help us identify any additional things we can
do to minimize the disruption to your current workflow.

RjS


<Prev in Thread] Current Thread [Next in Thread>