Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool
Making the IETF email archive search tool faster and easier to use.
Sparks, R., "Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool", RFC 7842, DOI 10.17487/RFC7842, April 2016, <https://www.rfc-editor.org/info/rfc7842>.
@misc{rfc7842,
series = {Request for Comments},
number = 7842,
howpublished = {RFC 7842},
publisher = {RFC Editor},
doi = {10.17487/RFC7842},
url = {https://www.rfc-editor.org/info/rfc7842},
author = {R. Sparks},
title = {{Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool}},
pagetotal = 7,
year = 2016,
month = apr,
} RFC text
Contents
Internet Engineering Task Force (IETF) R. Sparks
Request for Comments: 7842 Oracle
Category: Informational April 2016
ISSN: 2070-1721
Requirements for Improvements to the IETF Email List Archiving,
Web-Based Browsing, and Search Tool
Abstract
The web-based IETF email archive search tool based on the
requirements captured in RFC 6778 was deployed in January 2014. This
memo captures the requirements for a set of improvements that have
been identified during its initial years of community use.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7842.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. List Search and Archive Tool Improvement Requirements . . . . 2
2.1. Viewing by Thread . . . . . . . . . . . . . . . . . . . . 2
2.2. Navigation from the Message List View . . . . . . . . . . 3
2.3. Navigation from a Single Message . . . . . . . . . . . . 3
2.4. Message List UI . . . . . . . . . . . . . . . . . . . . . 4
2.5. Improve Support for Mobile Devices . . . . . . . . . . . 5
2.6. Improve Use of Display Space . . . . . . . . . . . . . . 5
2.7. Use without JavaScript . . . . . . . . . . . . . . . . . 5
2.8. Administration . . . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Normative References . . . . . . . . . . . . . . . . . . 6
4.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The IETF email archive search tool, as specified in [RFC6778]) and
available at [mailarch], has been in use for nearly two years.
During that time, there have been repeated requests for several
improvements. This memo captures the requirements for a concerted
development effort to provide those improvements.
2. List Search and Archive Tool Improvement Requirements
2.1. Viewing by Thread
Currently, when the "Group by Thread" button is selected, the
resulting list of messages is flat. It is very hard to tell where a
thread starts and stops. This flat view interacts badly with sorting
(triggered by clicking on the column headers), leading to results
that are confusing and sometimes incorrect.
This effort will:
o Modify the message list display, when grouped by thread, to show
each thread hierarchically.
o Modify the sort performed by the clicking on the column headers to
sort the overall list first by the parameters in the first message
in the thread, and then sort within the thread (ensuring the
thread grouping doesn't change based on these sorts). When
viewing threads sorted this way, the hierarchy will be flattened,
but the thread boundaries will remain visibly distinct.
2.2. Navigation from the Message List View
This effort will add navigation to the message list view, whether
viewing flat search results or viewing by thread, making it simple
to:
o Navigate to the previous/next message by date in the set of listed
messages.
o Navigate to the previous/next message in a thread, to the first
message in a thread, and to the previous/next thread displayed.
o Navigate to any References or Replies (displayed as Follow-Ups in
MHonArc) for the currently selected message. These are derived
from the References header field in the displayed message, and the
In-Reply-To header field or the last value in the References
header field of all other messages in the archive).
The UI will make it possible to hide these navigation elements.
2.3. Navigation from a Single Message
Currently, when viewing a single message, the only option for
navigating to related messages is to return to the message list view
(either by date or by thread). This is implemented with a new search
based only on the details present in the message itself. No
information about any search that led to the message is retained.
This effort will:
o Add navigation to the single message view, enabling transition to
previous/next in list and previous/next in thread.
o Add navigation enabling transition to previous/next in search, if
the message page being displayed was arrived at by navigating from
the message list view of a search result.
o Add navigation to any References or Replies (displayed as Follow-
Ups in MHonArc). These are derived from the References header
field in the displayed message, and the In-Reply-To header field
or the last value in the References header field of all other
messages in the archive.
o Make it possible to hide these navigation elements.
2.4. Message List UI
It is not sufficiently obvious that the message list panel can be
resized. The current handle is not visually distinct enough to
signal the capability to the user, leaving many users believing they
are restricted to the very short default list, even when viewing on
large monitors.
Additionally, there is a flaw in the code that fetches additional
messages when scrolling to the bottom of what's currently displayed.
If the message window is large enough that the default number of
results does not fill it, no scrollbar appears, and scrolling to the
bottom does not fetch additional results.
The filter by list and filter by from sections to the left of the
message list have no values in many circumstances, but it is not
obvious why they are missing. One notable condition is when the
search result is very large -- computing the values to put in these
filters becomes prohibitively expensive. Without foreknowledge of
the decisions captured in the code, the behavior seems arbitrary and
unintuitive.
The current view truncates fields, leaving trailing ellipses, when it
doesn't need to. This leaves space underutilized on large displays
and may make selection (particularly of long email addresses in the
filters) much more difficult than it should be. On small displays,
the column of filters dominates the display, leaving only a small
amount of space for the actual message content.
The current view requires the user to select each message in the
message list to get the URI to that message. This makes it difficult
to open several messages in different windows, or to build a list of
URIs for use in a message or other applications. It is also not
obvious that double-clicking a row in the list will open the message
in a separate window.
This effort will:
o Make the ability to resize the panels on the message list display
easier to find.
o Account for the size of the message list panel when choosing how
many messages to fetch, filling the panel whenever there are
enough results to do so.
o Provide a message explaining any condition leading to filter
values not being populated (such as "Refine search to enable
'From' filtering").
o Allow subjects to fill the column on large displays. Show fully
expanded list and email addresses in the pop-ups for the filters.
o Provide a link on each row of the list to the URL for that row's
message.
o Add an export type that produces a file containing a list of URIs
to each message in the list.
o Add a hint to the UI that double-clicking on a row in the list
will open a single-message view of the associated message in a
separate view.
2.5. Improve Support for Mobile Devices
The current view becomes difficult to use on small displays,
particularly phone displays in portrait mode. This effort will:
o Add a responsive interface, presenting a useful interface on both
small and large displays.
2.6. Improve Use of Display Space
The current view underutilizes the available display space. This
effort will:
o Make the message content the primary point of each view.
o Reduce the unused space on the display.
o Remove the filter column responsively when the display width is
small.
2.7. Use without JavaScript
The current web-based archive search tool requires JavaScript to
function. This effort will extend the tool to allow users that have
disabled JavaScript in their browser to retrieve and navigate through
search results using the message list and single message views.
This effort will not attempt to preserve all of the functionality
provided with JavaScript enabled. In particular, when running with
JavaScript disabled, these features will not be available:
o Resizing of the message list panels.
o Dynamically filtering by time, list, or from. (The filter column
will not appear).
2.8. Administration
This project will:
o Add a link from the message view to the admin page for the message
when logged in as an administrator.
o Add correction of the appropriate thread indices to the handling
of administrative imports of messages.
o Implement a redirection handler mapping legacy archive URLs to the
appropriate mailarch page.
o Make the underlying template consistent across all views presented
by the tool. In particular, ensure that the correct logo as
designated by the IETF Administrative Oversight Committee (IAOC)
appears consistently on all views.
3. Security Considerations
The requirements for improvement to the mailarch tool captured in
this document do not introduce any exceptional security
considerations. They add additional navigation points, and the
implementers should consider the impact of rapid navigation using
these new mechanisms (see the security considerations of [RFC6778]).
4. References
4.1. Normative References
[RFC6778] Sparks, R., "Requirements for Archiving IETF Email Lists
and for Providing Web-Based Browsing and Searching",
RFC 6778, DOI 10.17487/RFC6778, October 2012,
<http://www.rfc-editor.org/info/rfc6778>.
4.2. Informative References
[mailarch]
IETF, "Mail Archive", <https://mailarchive.ietf.org>.
Acknowledgments
The following people have provided particularly useful input for this
document: Lou Berger, Chris Bowers, Brian Carpenter, Russ Housley,
Pete Resnick, and Dale Worley.
Author's Address
Robert Sparks
Oracle
7460 Warren Parkway
Suite 300
Frisco, Texas 75034
United States
Email: rjsparks@nostrum.com
AI ELI5
On this page
§1Improving the Email Archive Tool
The IETF conducts most of its technical work via email mailing lists. For decades, archives of these lists have been public, but searching and browsing them was hard until RFC 6778 specified requirements for a modern web-based archive tool. That tool was deployed in January 2014 and has been used by the community ever since.
This RFC, published in April 2016, documents requirements for improvements identified during the tool's first two years of operation. The requirements come from community feedback and represent a concerted development effort to make the archive easier to navigate, more responsive to modern devices, and more accessible to users with different browsers or accessibility needs.
The IETF has decades of email archives. A modern search tool was built two years ago. Now, based on how people actually use it, the community has a list of improvements to make.
§2Thread Viewing and Navigation
When viewing messages grouped by thread, the current tool shows a flat list, making it hard to see where threads start and stop. The requirement is to show threads hierarchically, with clear visual boundaries between them. When sorting by clicking column headers, the sort should apply to the threads first (by the first message in each thread), then sort within threads, keeping threads visually grouped.
Navigation is another major gap. Users should be able to move between messages by date, jump to the previous or next message in a thread, go to the thread's first message, or navigate to replies and references. Currently, the only way to find related messages is to return to the message list and search again. The improvements would add navigation for references (the messages a given message replies to) and follow-ups (messages that reply to the given message), based on the References and In-Reply-To email header fields.
Right now, a long conversation looks like a flat list with no tree structure. The improvement would show who replied to whom. Navigation should let you jump backward and forward through messages, see the conversation thread, or follow a chain of related emails.
§3Display and Usability
The message list panel can be resized to show more or fewer messages at once, but the control for resizing is not obvious. The requirement is to make this capability more discoverable. There is also a bug: if the display is large enough that all results fit without scrolling, the tool does not fetch additional messages. The improvement would account for the actual panel size when deciding how many messages to load.
The current view has a filter column on the left for filtering by mailing list and sender. This column often appears empty, but it is not clear why. The improvement should explain why filters are unavailable (for example, "refine search to enable 'From' filtering"). Additionally, the view truncates long fields (subjects, email addresses) with ellipses even when space is available. On large displays, these fields should be allowed to expand fully. On small displays, the filter column should collapse or be hidden.
Currently, to get the URI (web address) of a message, users must click on each message in the list individually. The improvements would add a direct link to each message's URL on every row, and provide an export option to download a file containing URIs for all messages in the search results.
The search results panel should show more detail about messages, like full subject lines and email addresses, without requiring the user to click each one. Resizing the panel should be obvious. There should be a button to grab URLs for all search results at once.
§4Mobile and Accessibility Support
The current archive tool becomes difficult to use on phones and tablets, particularly in portrait mode on smartphones. The requirement is to add a responsive interface that adapts to both large desktop displays and small mobile screens. The filter column, which takes up space on small screens, should be collapsible or hidden.
The tool currently requires JavaScript to function. Modern browsers nearly all support JavaScript, but some users disable it for security or privacy reasons, and some organizations restrict it. The improvement should allow users with JavaScript disabled to search the archive and navigate search results using the message list and single-message views. Not all features (like resizing panels or live filtering) would work without JavaScript, but core search and browsing would be available.
When a user opens a message, there should be hints that double-clicking a row in the list opens the message in a separate window, and a clear way to hide navigation elements if desired.
The tool should work on phones and tablets, not just big computer screens. It should also work even if JavaScript is turned off, so people who disable JavaScript for security can still search the archives.
§5Administration and Security
For administrators of the archive tool, the requirements include a link from the message view to the administration page when logged in. Administrative imports of messages sometimes need to correct thread indices; the requirement is to automate this correction. Additionally, legacy URLs pointing to older archive formats should be handled with redirects so old links do not break.
Finally, the template used to display messages should be made consistent across all views (message lists, single messages, thread views) to ensure a unified visual identity, particularly that the IETF logo appears consistently. This is a meta-requirement for maintainability.
Security considerations are minimal. The improvements add navigation features which could be used for rapid navigation attacks; implementers should be aware of potential denial-of-service issues if the tool is flooded with rapid requests, as noted in RFC 6778.
Administrators should be able to manage the tool easily, old links to the archive should still work, and the IETF branding should be consistent everywhere. Rapid automated navigation could be abused, so that needs to be watched.