Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/rfc-ed-all/pdfrfc/rfc7842.txt.pdf
Дата изменения: Thu Apr 7 03:13:56 2016
Дата индексирования: Sun Apr 10 16:50:32 2016
Кодировка:
Internet Engineering Task Force (IETF) Request for Comments: 7842 Category: Informational ISSN: 2070-1721

R. Sparks Oracle April 2016

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. 2. Introduction . . . . . . . . . . . . . . List Search and Archive Tool Improvement 2.1. Viewing by Thread . . . . . . . . . . 2.2. Navigation from the Message List View 2.3. Navigation from a Single Message . . 2.4. Message List UI . . . . . . . . . . . 2.5. Improve Support for Mobile Devices . 2.6. Improve Use of Display Space . . . . 2.7. Use without JavaScript . . . . . . . 2.8. Administration . . . . . . . . . . . 3. Security Considerations . . . . . . . . . 4. References . . . . . . . . . . . . . . . 4.1. Normative References . . . . . . . . 4.2. Informative References . . . . . . . Acknowledgments . . . . . . . . . . . . . . . Author's Address . . . . . . . . . . . . . . 1. Introduction The IETF email archive search tool, as specified in available at [mailarch], has been in use for nearly During that time, there have been repeated requests improvements. This memo captures the requirements development effort to provide those improvements. 2. 2.1. [RFC6778]) and two years. for several for a concerted ...... Requirements ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... ...... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 2 3 3 4 5 5 5 6 6 6 6 6 6 7

List Search and Archive Tool Improvement Requirements 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. 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.

o

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. Navigate to the previous/next message in a thread, to the first message in a thread, and to the previous/next thread displayed. 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).

o

o

The UI will make it possible to hide these navigation elements. 2.3. Navigation from a Single Message when viewing a single message, the only option for to related messages is to return to the message list view date or by thread). This is implemented with a new search on the details present in the message itself. No about any search that led to the message is retained.

Currently, navigating (either by based only information

This effort will: o Add navigation to the single message view, enabling transition to previous/next in list and previous/next in thread. 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. Add navigation to any References or Ups in MHonArc). These are derived field in the displayed message, and or the last value in the References messages in the archive. Replies (displayed as Followfrom the References header the In-Reply-To header field header field of all other

o

o

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 obvious that the message list panel can be handle is not visually distinct enough to to the user, leaving many users believing they very short default list, even when viewing on

It is not sufficiently resized. The current signal the capability are restricted to the large monitors.

Additionally, there is a flaw in the code that messages when scrolling to the bottom of what's If the message window is large enough that the results does not fill it, no scrollbar appears, bottom does not fetch additional results. The filter by list and filter message list have no values in obvious why they are missing. search result is very large -filters becomes prohibitively the decisions captured in the unintuitive.

fetches additional currently displayed. default number of and scrolling to the

by from sections to the left of the many circumstances, but it is not One notable condition is when the computing the values to put in these expensive. Without foreknowledge of code, the behavior seems arbitrary and

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 message list to get the URI to that message. This makes it to open several messages in different windows, or to build a URIs for use in a message or other applications. It is also obvious that double-clicking a row in the list will open the in a separate window. This effort will: o 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. Provide a message explaining any condition leading to filter values not being populated (such as "Refine search to enable 'From' filtering"). the difficult list of not message

o

o

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. 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 on a row in the list will open a single-message view of the associated message in a separate view. Improve Support for Mobile Devices

o

o

o

2.5.

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. Improve Use of Display Space This

2.6.

The current view underutilizes the available display space. effort will: o o o Make the message content the primary point of each view. Reduce the unused space on the display.

Remove the filter column responsively when the display width is small. Use without JavaScript

2.7.

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 o Resizing of the message list panels. Dynamically filtering by time, list, or from. will not appear). (The filter column

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. Add correction of the appropriate thread indices to the handling of administrative imports of messages. Implement a redirection handler mapping legacy archive URLs to the appropriate mailarch page. 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. 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. 4.1. References Normative References Sparks, R., "Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching", RFC 6778, DOI 10.17487/RFC6778, October 2012, .

o

o

o

3.

[RFC6778]

4.2.

Informative References

[mailarch] IETF, "Mail Archive", . 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]