A User Agent Configuration Mechanism for Multimedia Mail Format Information
RFC 1343
Document | Type |
RFC - Informational
(June 1992; No errata)
Was draft-ietf-borenstein-configmech (individual)
|
|
---|---|---|---|
Author | Nathaniel Borenstein | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf ps htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1343 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group N. Borenstein, Bellcore Request for Comments: 1343 June 1992 A User Agent Configuration Mechanism For Multimedia Mail Format Information Status of This Memo This is an informational memo for the Internet community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. Distribution of this memo is unlimited. Abstract This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. The mechanism is explicitly designed to work with mail systems based Internet mail as defined by RFC's 821, 822, 934, 1049, 1113, and the Multipurpose Internet Mail Extensions, known as MIME. However, with some extensions it could probably be made to work for X.400-based mail systems as well. The format and mechanism are proposed in a manner that is generally operating-system independent. However, certain implementation details will inevitably reflect operating system differences, some of which will have to be handled in a uniform manner for each operating system. This memo makes such situations explicit, and, in an appendix, suggests a standard behavior under the UNIX operating system. Introduction The electronic mail world is in the midst of a transition from single-part text-only mail to multi-part, multi-media mail. In support of this transition, various extensions to RFC 821 and RFC 822 have been proposed and/or adopted, notably including MIME [RFC-1341]. Various parties have demonstrated extremely high-functionality multimedia mail, but the problem of mail interchange between different user agents has been severe. In general, only text messages have been shared between user agents that were not explicitly designed to work together. This limitation is not compatible with a smooth transition to a multi-media mail world. One approach to this transition is to modify diverse sets of mail reading user agents so that, when they need to display mail of an unfamiliar (non-text) type, they consult an external file for information on how to display that file. That file might say, for example, that if the content-type Borenstein [Page 1] RFC 1343 Multimedia Mail Configuration June 1992 of a message is "foo" it can be displayed to the user via the "displayfoo" program. This approach means that, with a one-time modification, a wide variety of mail reading programs can be given the ability to display a wide variety of types of message. Moreover, extending the set of media types supported at a site becomes a simple matter of installing a binary and adding a single line to a configuration file. Crucial to this scheme, however, is that all of the user agents agree on a common representation and source for the configuration file. This memo proposes such a common representation. Location of Configuration Information Each user agent must clearly obtain the configuration information from a common location, if the same information is to be used to configure all user agents. However, individual users should be able to override or augment a site's configuration. The configuration information should therefore be obtained from a designated set of locations. The overall configuration will be obtained through the virtual concatenation of several individual configuration files known as mailcap files. The configuration information will be obtained from the FIRST matching entry in a mailcap file, where "matching" depends on both a matching content- type specification, an entry containing sufficient information for the purposes of the application doing the searching, and the success of any test in the "test=" field, if present. The precise location of the mailcap files is operating-Show full document text