RFC 7842

RFC 7842: Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool 💌

Okay bestie, the header facts first 🎀. This is RFC 7842, written by R. Sparks at Oracle in April 2016. It's Informational, which means it's published for information and isn't a Standards Track spec. The ISSN is 2070-1721. It doesn't say it obsoletes or updates any other RFCs, so it's a solo little doc 🦋.

Abstract ✨

The web-based IETF email archive search tool, built on the requirements in RFC 6778, got deployed in January 2014. This memo lists the requirements for a bunch of improvements people found during its first years of community use 💅.

Status of This Memo 📝

This document is not an Internet Standards Track specification. It's 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.

Info about the current status of this doc, any errata, and how to give feedback can be found 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, since 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 around for nearly two years. In that time, people have repeatedly asked for several improvements. This memo lists the requirements for a focused dev push to deliver them 🚀.

2. List Search and Archive Tool Improvement Requirements 💖

2.1. Viewing by Thread 🧵

Okay so, when you hit the "Group by Thread" button, the messages come back as one flat list. It's so hard to tell where a thread starts and stops 😭. And this flat view clashes with sorting (the kind you trigger by clicking the column headers), so the results get confusing and sometimes just wrong 💀.

This effort will:

• Change the message list display, when grouped by thread, to show each thread hierarchically.
• Change the sort you get from clicking the column headers so it sorts the whole list first by the parameters of the first message in each thread, then sorts within the thread. This keeps the thread grouping from shifting around with these sorts. When threads are sorted this way, the hierarchy gets flattened, but the thread boundaries stay visibly distinct ✨.

2.2. Navigation from the Message List View 🧭

This effort will add navigation to the message list view, whether you're looking at flat search results or viewing by thread, so it's simple to:

• Jump to the previous/next message by date in the set of listed messages.
• Jump to the previous/next message in a thread, to the first message in a thread, and to the previous/next thread displayed.
• Jump to any References or Replies (shown as Follow-Ups in MHonArc) for the currently selected message. These are derived from the References header field in the displayed message, and from 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 let you hide these navigation elements 🙈.

2.3. Navigation from a Single Message 📩

Right now, when you're viewing a single message, the only way to get to related messages is to go back to the message list view (either by date or by thread). That runs a new search based only on the details in the message itself. Nothing about the search that led you to the message is kept 😤.

This effort will:

• Add navigation to the single message view, so you can move to previous/next in the list and previous/next in the thread.
• Add navigation for previous/next in the search, if the message page was reached by navigating from the message list view of a search result.
• Add navigation to any References or Replies (shown as Follow-Ups in MHonArc). These are derived from the References header field in the displayed message, and from the In-Reply-To header field or the last value in the References header field of all other messages in the archive.
• Make it possible to hide these navigation elements.

2.4. Message List UI 🎨

It's not obvious enough that the message list panel can be resized 😩. The current handle isn't visually distinct enough to tell people they can, so tons of users think they're stuck with the super short default list, even on big monitors.

There's also a bug in the code that fetches more messages when you scroll to the bottom of what's showing. If the message window is big enough that the default number of results doesn't fill it, no scrollbar appears, and scrolling to the bottom doesn't fetch anything more 💀.

The filter by list and filter by from sections to the left of the message list have no values in lots of situations, and it's not clear why. One notable case is when the search result is very large, because computing the filter values gets prohibitively expensive. Without knowing the decisions baked into the code, the behavior seems random and unintuitive 🤷‍♀️.

The current view truncates fields and leaves trailing ellipses even when there's room. That wastes space on large displays and can make selection (especially of long email addresses in the filters) way harder than it should be. On small displays, the filter column hogs the screen and leaves only a sliver of space for the actual message content 😭.

Right now, you have to select each message in the list to get its URI. That makes it hard to open several messages in different windows, or to build a list of URIs for a message or other apps. It's also not obvious that double-clicking a row opens the message in a separate window 👀.

This effort will:

• Make the ability to resize the panels on the message list display easier to find.
• 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.
• Show a message explaining any condition that leaves filter values unpopulated (such as "Refine search to enable 'From' filtering").
• Let subjects fill the column on large displays. Show fully expanded list and email addresses in the pop-ups for the filters.
• Provide a link on each row of the list to the URL for that row's message.
• Add an export type that produces a file containing a list of URIs to each message in the list.
• Add a hint to the UI that double-clicking 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 gets hard to use on small displays, especially phones in portrait mode. This effort will:

• Add a responsive interface that's useful on both small and large displays 💅.

2.6. Improve Use of Display Space 🖥️

The current view doesn't make great use of the available display space. This effort will:

• Make the message content the main point of each view.
• Reduce the unused space on the display.
• Remove the filter column responsively when the display width is small.

2.7. Use without JavaScript 🙅‍♀️

The current web-based archive search tool needs JavaScript to function. This effort will extend the tool so users who have disabled JavaScript in their browser can still retrieve and navigate through search results using the message list and single message views 🫶.

This effort will not try to keep every feature that JavaScript enables. In particular, with JavaScript disabled, these features won't be available:

• Resizing of the message list panels.
• Dynamically filtering by time, list, or from. (The filter column won't appear.)

2.8. Administration 🛠️

This project will:

• Add a link from the message view to the admin page for that message when you're logged in as an administrator.
• Add correction of the appropriate thread indices to the handling of administrative imports of messages.
• Implement a redirection handler that maps legacy archive URLs to the appropriate mailarch page.
• Make the underlying template consistent across all views the tool presents. In particular, make sure the correct logo, as designated by the IETF Administrative Oversight Committee (IAOC), shows up consistently on all views 👑.

3. Security Considerations 🔥

The requirements for improving the mailarch tool captured in this document do not introduce any exceptional security considerations. They add additional navigation points, and implementers should consider the impact of rapid navigation using these new mechanisms (see the security considerations of [RFC6778]).

⚠️ Plot twist, but a calm one: the new navigation points are the only thing to watch here, so implementers should think about what happens when people navigate rapidly through them. Check the security considerations of [RFC6778] too.

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 ✨

okay bestie, this part is the thank-you section 🫶 The author wants to shout out these legends for giving input that was particularly useful 💖: Lou Berger, Chris Bowers, Brian Carpenter, Russ Housley, Pete Resnick, and Dale Worley 👑 literally iconic, no notes.

Author's Address 🦋

and last but not least, here's where you can find the author 💅 Robert Sparks, at Oracle, 7460 Warren Parkway, Suite 300, Frisco, Texas 75034, United States. The email is rjsparks@nostrum.com 💌

Robert Sparks
Oracle
7460 Warren Parkway
Suite 300
Frisco, Texas  75034
United States

Email: rjsparks@nostrum.com

that's the whole doc, babe 🌈✨ you made it through!! 🎀