INTERNET DRAFT


	 Maintaining Presentation Guidelines on MIME Messages

			    Dan Pritchett
			    SunSoft, Inc.
		      Dan.Pritchett@Eng.Sun.COM

	     File: draft-pritchett-mime-guidelines-00.txt
			   Expires 10/01/94

Status of this Memo

     This document is an Internet-Draft.  Internet-Drafts are working
     documents of the Internet Engineering Task Force (IETF), its
     areas, and its working groups.  Note that other groups may also
     distribute working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-
     Drafts as reference material or to cite them other than as
     ``work in progress.''

     To learn the current status of any Internet-Draft, please check
     the ``1id-abstracts.txt'' listing contained in the Internet-
     Drafts Shadow Directories on ds.internic.net (US East Coast),
     nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
     munnari.oz.au (Pacific Rim).

Abstract

     The introduction of MIME brings the standards required to
     construct robust mail user agents. These agents will quite often
     have presentation semantics. In many cases, the way to present a
     multipart message is clear based on the message, but there are
     times when this is not true. This document proposes a mechanism for
     dealing with those cases.

1.0 Introduction

MIME introduces the capabilities required to support multipart
messages. Multipart messages allow user agents to place multiple items
within the body of an RFC822 message. MIME leaves open in many cases
however how these parts should be presented to the user
(multipart/alternate is a noted exception).

In most cases, the user agent can determine how to present a message
to the user with information provided by MIME.  An example would be a
MIME message of type multipart/mixed where the first part is a brief
description of a document, and the second part is the document in
postscript. A user agent could easily choose to display the first part
to the user directly, and present the second part in a more compact
form (e.g. an icon in the GUI, or a summary for a tty user agent). The
second part could then be viewed by an external viewer, or saved to a
separate file.

This example becomes more difficult however if the user, through the
use of a GUI user agent simply attaches a plain text document. A
receiving user agent might choose to display the contents to the user
as a single message body. But the sender intended the text to be a
document that would be viewed independently, or perhaps saved for
additional editing. The sender's intent was not adequately
captured in the message.

1.1 Presentation Guidelines

The range of user agents that can be constructed for viewing MIME
messages is quite large. They can range from trivial tty based agents
to complex GUI applications with full embedded presentation. Messages
must be freely interchanged between these agents. This means that any
presentation information associated with the message is a guideline or
hint, and not a strict presentation policy for the message.

This RFC proposes an optional header to represent these guidelines.
User agents must not, however assume the header is present, and should
choose reasonable presentation policies when the header is not
present. User agents should also consider that the recipient of the
message may not use the header and should avoid decreasing the
usefulness of the message should the presentation guidelines be
ignored.

2.0 The Content-Layout Header

Presentation guidelines will be represented by the Content-Layout
header. The primary function of the header is to suggest whether the
contents of a part should be displayed expanded, or in a summary
format (e.g iconic in a GUI agent).

The syntax of the Content-Layout header is:

    Content_Layout      :=      "Content-Layout: " Layout CRLF
    Layout              :=      "expanded" | "summary"

2.0.1 The expanded value

If a part is marked as Content-Layout, "expanded", the user agent
should attempt to display the contents of the part to the user. The
agent may decide this can not be done or does not make sense (e.g. a
postscript part on a tty viewer).

User agents should not assume that expanded will only apply to the
first part. The expanded and summary values can appear in any order
and combination in a multipart message.

2.0.2 The summary value

If a part is marked as Content-Layout, "summary", the user agent
should not display the contents to the user, but should choose a
summary format for the information. Typical choices would be a single
line of text, or an icon.

User agents should refrain from displaying summary parts as expanded,
unless doing so has no impact on the user's ability to treat the part as
a object. The rationale is that if the user intended to send the part
as an object that can be manipulated as a whole, it would be
inappropriate for a user agent to eliminate, or complicate this
manipulation for the recipient.

2.1 Content-Layout examples

The following examples illustrate the common
usage of Content-Layout.

The first example illustrates the simple case identified earlier. The
message has two parts, the first is shown expanded, the second is an
attached document that is to be shown iconic.

   From dlp@zule Sun Feb 27 00:10:12 PST 1994
   To: dlp@zule
   Subject: Two parts
   Mime-Version: 1.0
   Content-Type: multipart/mixed;boundary=--test

   --test
   Content-Type: text/plain
   Content-Layout: expanded

   Here is a document.

   --test
   Content-Type: application/postscript
   Content-Layout: summary

   <....>
   --test--

The next example addresses the case of a single part, but the user's
intent was the part be displayed as a document (e.g. iconic).

   From dlp@zule Sun Feb 27 00:10:12 PST 1994
   To: dlp@zule
   Subject: Two parts
   Mime-Version: 1.0
   Content-Type: text/plain
   Content-Layout: summary

   <...The text document...>


3.0 Summary

The Content-Layout header allows user agents to specify how a MIME
message can be displayed to maintain as much of the original
presentation intent as possible. The use of Content-Layout is optional
for both senders and receivers.

