summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7842.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7842.txt')
-rw-r--r--doc/rfc/rfc7842.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc7842.txt b/doc/rfc/rfc7842.txt
new file mode 100644
index 0000000..d26262e
--- /dev/null
+++ b/doc/rfc/rfc7842.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+Sparks Informational [Page 1]
+
+RFC 7842 List Archiving and Search Requirements April 2016
+
+
+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.
+
+
+
+Sparks Informational [Page 2]
+
+RFC 7842 List Archiving and Search Requirements April 2016
+
+
+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.
+
+
+
+
+
+
+
+Sparks Informational [Page 3]
+
+RFC 7842 List Archiving and Search Requirements April 2016
+
+
+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").
+
+
+
+Sparks Informational [Page 4]
+
+RFC 7842 List Archiving and Search Requirements April 2016
+
+
+ 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).
+
+
+
+Sparks Informational [Page 5]
+
+RFC 7842 List Archiving and Search Requirements April 2016
+
+
+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.
+
+
+
+
+
+
+Sparks Informational [Page 6]
+
+RFC 7842 List Archiving and Search Requirements April 2016
+
+
+Author's Address
+
+ Robert Sparks
+ Oracle
+ 7460 Warren Parkway
+ Suite 300
+ Frisco, Texas 75034
+ United States
+
+ Email: rjsparks@nostrum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks Informational [Page 7]
+