Network Working Group E. Burger
Request for Comments: 3458 SnowShore Networks
Category: Standards Track E. Candell
Comverse
C. Eliot
Microsoft Corporation
G. Klyne
Nine by Nine
January 2003
Network Working Group E. Burger
Request for Comments: 3458 SnowShore Networks
Category: Standards Track E. Candell
Comverse
C. Eliot
Microsoft Corporation
G. Klyne
Nine by Nine
January 2003
Message Context for Internet Mail
Internet邮件的消息上下文
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This memo describes a new RFC 2822 message header, "Message-Context". This header provides information about the context and presentation characteristics of a message.
本备忘录描述了新的RFC 2822消息头“消息上下文”。此标头提供有关消息的上下文和表示特征的信息。
A receiving user agent (UA) may use this information as a hint to optimally present the message.
接收用户代理（UA）可以使用该信息作为最佳呈现消息的提示。
Table of Contents
目录
1. Introduction....................................................2
2. Conventions used in this document...............................3
3. Motivation......................................................3
4. Functional Requirements.........................................5
5. Determining the Message Context.................................6
6. Message-Context Reference Field.................................7
6.1. Message-Context Syntax......................................7
6.2. message-context-class Syntax................................7
6.2.1. voice-message...........................................8
6.2.2. fax-message.............................................8
6.2.3. pager-message...........................................8
6.2.4. multimedia-message......................................8
6.2.5. text-message............................................8
6.2.6. none....................................................8
7. Security Considerations.........................................9
8. IANA Considerations.............................................9
8.1. Message Content Type Registrations..........................9
8.2. Registration Template......................................10
8.3. Message-Context Registration...............................11
9. APPENDIX: Some messaging scenarios.............................12
9.1. Internet e-mail............................................12
9.2. Pager service..............................................12
9.3. Facsimile..................................................13
9.4. Voice mail.................................................14
9.5. Multimedia message.........................................14
10. References....................................................15
10.1 Normative References.......................................15
10.2 Informative References.....................................15
11. Acknowledgments...............................................15
12. Authors' Addresses............................................16
13. Full Copyright Statement......................................17
1. Introduction....................................................2
2. Conventions used in this document...............................3
3. Motivation......................................................3
4. Functional Requirements.........................................5
5. Determining the Message Context.................................6
6. Message-Context Reference Field.................................7
6.1. Message-Context Syntax......................................7
6.2. message-context-class Syntax................................7
6.2.1. voice-message...........................................8
6.2.2. fax-message.............................................8
6.2.3. pager-message...........................................8
6.2.4. multimedia-message......................................8
6.2.5. text-message............................................8
6.2.6. none....................................................8
7. Security Considerations.........................................9
8. IANA Considerations.............................................9
8.1. Message Content Type Registrations..........................9
8.2. Registration Template......................................10
8.3. Message-Context Registration...............................11
9. APPENDIX: Some messaging scenarios.............................12
9.1. Internet e-mail............................................12
9.2. Pager service..............................................12
9.3. Facsimile..................................................13
9.4. Voice mail.................................................14
9.5. Multimedia message.........................................14
10. References....................................................15
10.1 Normative References.......................................15
10.2 Informative References.....................................15
11. Acknowledgments...............................................15
12. Authors' Addresses............................................16
13. Full Copyright Statement......................................17
This document describes a mechanism to allow senders of an Internet mail message to convey the message's contextual information. Taking account of this information, the receiving user agent (UA) can make decisions that improve message presentation for the user in the context the sender and receiver expects.
本文档描述了一种允许Internet邮件发件人传递邮件上下文信息的机制。考虑到这一信息，接收用户代理（UA）可以做出决策，在发送方和接收方期望的上下文中改进用户的消息表示。
In this document, the "message context" conveys information about the way the user expects to interact with the message. For example, a message may be e-mail, voice mail, fax mail, etc. A smart UA may have specialized behavior based on the context of the message.
在本文档中，“消息上下文”传递有关用户希望与消息交互的方式的信息。例如，消息可能是电子邮件、语音邮件、传真邮件等。智能UA可能具有基于消息上下文的特定行为。
This document specifies a RFC 2822 header called "Message-Context".
本文档指定了一个名为“消息上下文”的RFC 2822标头。
The mechanism is in some ways similar to the use of the Content-Disposition MIME entity described in [6]. Content-Disposition gives clues to the receiving User Agent (UA) for how to display a given body part. Message-Context can give clues to the receiving UA for the presentation of the message. This allows the receiving UA to present the message to the recipient, in a meaningful and helpful way.
该机制在某些方面类似于[6]中描述的内容处置MIME实体的使用。内容配置为接收用户代理（UA）提供如何显示给定身体部位的线索。消息上下文可以为接收UA提供消息表示的线索。这允许接收UA以有意义和有帮助的方式向接收者呈现消息。
Typical uses for this mechanism include:
该机制的典型用途包括：
o Selecting a special viewer for a given message.
o 为给定消息选择特殊查看器。
o Selecting an icon indicating the kind of message in a displayed list of messages.
o 在显示的消息列表中选择指示消息类型的图标。
o Arranging messages in an inbox display.
o 在收件箱显示中排列邮件。
o Filtering messages the UA presents when the user has limited access.
o 过滤用户访问受限时UA显示的消息。
This document refers generically to the sender of a message in the masculine (he/him/his) and the recipient of the message in the feminine (she/her/hers). This convention is purely for convenience and makes no assumption about the gender of a message sender or recipient.
本文件泛指男性信息的发送者（他/他/他的）和女性信息的接收者（她/她/她的）。此约定纯粹是为了方便起见，不对消息发送者或接收者的性别进行假设。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。
FORMATTING NOTE: Notes, such at this one, provide additional nonessential information that the reader may skip without missing anything essential. The primary purpose of these non-essential notes is to convey information about the rationale of this document, or to place this document in the proper historical or evolutionary context. Readers whose sole purpose is to construct a conformant implementation may skip such information. However, it may be of use to those who wish to understand why we made certain design choices.
格式注释：注释（如本注释）提供了额外的非必要信息，读者可以跳过这些信息而不遗漏任何重要信息。这些非必要注释的主要目的是传达有关本文件基本原理的信息，或将本文件置于适当的历史或演变背景中。其唯一目的是构造一致性实现的读者可以跳过此类信息。然而，对于那些希望理解我们为什么做出某些设计选择的人来说，这可能是有用的。
Multimedia messaging systems receive messages that a UA may present in variety of ways. For example, traditional e-mail uses simple text messages that the recipient displays and edits. One UA may automatically print Fax images. Another UA may play voice messages through a telephone handset. Likewise, a receiving desktop computer
多媒体消息传递系统接收UA可能以多种方式呈现的消息。例如，传统电子邮件使用收件人显示和编辑的简单文本消息。一个UA可以自动打印传真图像。另一个UA可以通过电话听筒播放语音消息。同样，接收桌面计算机
may process or present documents transferred over e-mail using a local application. Emerging and future developments may deliver other forms of information that have their own characteristics for user presentation, such as video messages and pager messages.
可以使用本地应用程序处理或呈现通过电子邮件传输的文档。新兴和未来的发展可能会提供其他形式的信息，这些信息具有自己的用户呈现特征，例如视频消息和寻呼机消息。
An often-requested characteristic for multimedia messaging systems is to collect received messages in a "universal inbox", and to offer them to the user as a combined list.
彩信系统的一个经常要求的特征是在“通用收件箱”中收集收到的消息，并将它们作为组合列表提供给用户。
In the context of "unified messaging", different message contexts may have different implied semantics. For example, some users may perceive voicemail to have an implicit assumption of urgency. Thus they may wish to gather them together and process them before other messages. This results in the end-user receiving agent needing to be able to identify voicemail and distinguish it from other messages.
在“统一消息”的上下文中，不同的消息上下文可能具有不同的隐含语义。例如，一些用户可能会认为语音邮件隐含着紧急情况。因此，他们可能希望将它们收集在一起，并在其他消息之前处理它们。这导致最终用户接收代理需要能够识别语音邮件并将其与其他邮件区分开来。
The uses of this kind of presentation characteristic for each message are multi-fold:
对于每条消息，这种表示特性的用途是多方面的：
o Display an indication to the user (e.g., by a suitably evocative icon along with other summary fields),
o 向用户显示指示（例如，通过适当的提示图标以及其他摘要字段），
o Auto-forward a given message type into another messaging environment (e.g., a page to a mobile short message service),
o 自动将给定的消息类型转发到另一个消息环境（例如，移动短消息服务的页面），
o Prioritize and group messages in an inbox display list,
o 在收件箱显示列表中对邮件进行优先级排序和分组，
o Suggest appropriate default handling for presentation,
o 建议对演示文稿进行适当的默认处理，
o Suggest appropriate default handling for reply, forward, etc.
o 建议对回复、转发等进行适当的默认处理。
A problem faced by multimedia messaging systems is that it is not always easy to decide the context of a received message. For example, consider the following scenarios.
多媒体消息系统面临的一个问题是，确定接收到的消息的上下文并不总是容易的。例如，考虑下面的场景。
o A message that contains audio and image data: Is this a fax message that happens to have some voice commentary? Is it a voice message that is accompanied by some supplementary diagrams? Is it a fully multimedia message, in which all parts are expected to carry equal significance?
o 包含音频和图像数据的消息：这是一条带有语音注释的传真消息吗？这是一条带有一些补充图表的语音信息吗？这是一个完全多媒体信息，其中所有部分都具有同等的意义吗？
o A message containing text and audio data: Is this e-mail with an MP3 music attachment? Is it a voice message that happens to have been generated with an initial text header for the benefit of non-voice-enabled e-mail receivers?
o 包含文本和音频数据的消息：此电子邮件是否带有MP3音乐附件？它是一条语音消息，碰巧是为非语音电子邮件接收者的利益而使用初始文本标题生成的吗？
The message context does relate to the message media content. However, it is not the same thing. As shown above, the media type used in a message is not sufficient to indicate the message context. One cannot determine a priori which media types to use in alternative (gateway) messages. Also, what if the user cares about distinguishing traditional e-mail text from SMS messages? They are both the same media type, text, but they have different user contexts.
消息上下文确实与消息媒体内容相关。然而，这不是一回事。如上所示，消息中使用的媒体类型不足以指示消息上下文。无法事先确定在备选（网关）消息中使用哪些媒体类型。此外，如果用户关心如何区分传统电子邮件文本和SMS消息呢？它们都是相同的媒体类型，文本，但它们有不同的用户上下文。
The goals stated above lead to the following functional requirements.
上述目标导致以下功能需求。
For receivers:
收件人：
o Identify a message as belonging to a message class.
o 将消息标识为属于消息类。
o Incorrect or invalid message classification must not result in failure to transfer or inability to present a message.
o 不正确或无效的邮件分类不得导致无法传输或无法呈现邮件。
For senders:
对于发件人：
o Specify message classes by the originating user's choice of authoring tool or simple user interaction.
o 通过原始用户选择创作工具或简单用户交互来指定消息类。
For both:
对于这两种情况：
o Specify a well-defined set of message classes to make interoperability between mail user agents (UAs) possible.
o 指定一组定义良好的消息类，以实现邮件用户代理（UAs）之间的互操作性。
o Message classification information has to be interpretable in reasonable fashion by many different user agent systems.
o 消息分类信息必须由许多不同的用户代理系统以合理的方式进行解释。
o The mechanism should be extensible to allow for the introduction of new kinds of messages.
o 该机制应该是可扩展的，以允许引入新类型的消息。
NOTE: We specifically do not specify user agent behavior when the user agent forwards a message. Clearly, the user agent, being message-context-aware, should provide a meaningful message-context. It is obvious what to do for the easy cases. Messages that the user simply forwards will most likely keep the context unchanged. However, it is beyond the scope of this document to specify the user agent behavior for any other scenario.
注意：当用户代理转发消息时，我们特别不指定用户代理行为。显然，具有消息上下文意识的用户代理应该提供有意义的消息上下文。很明显，对于简单的情况该怎么办。用户简单转发的消息很可能会保持上下文不变。但是，为任何其他场景指定用户代理行为超出了本文档的范围。
One method of indicating the interpretation context of a message is to examine the media types in the message. However, this requires the UA to scan the entire message before it can make this determination. This approach is particularly burdensome for the multi-media mail situation, as voice and especially video mail objects are quite large.
指示消息解释上下文的一种方法是检查消息中的媒体类型。然而，这需要UA扫描整个消息，然后才能进行此确定。这种方法对于多媒体邮件情况来说尤其麻烦，因为语音邮件，尤其是视频邮件对象非常大。
We considered indicating the message context by registering a
multipart/* MIME subtype (Content-Type). For example, the VPIM Work
Group has registered multipart/voice-message to indicate that a
message is primarily voice mail [7]. However, multipart/voice-
message is identical in syntax to multipart/mixed. The only
difference is that VPIM mail transfer agents and user agents
recognize that they can perform special handling of the message based
on it being a voice mail message. Moreover, Content-Type refers to a
given MIME body part, not to the message as a whole.
We considered indicating the message context by registering a
multipart/* MIME subtype (Content-Type). For example, the VPIM Work
Group has registered multipart/voice-message to indicate that a
message is primarily voice mail [7]. However, multipart/voice-
message is identical in syntax to multipart/mixed. The only
difference is that VPIM mail transfer agents and user agents
recognize that they can perform special handling of the message based
on it being a voice mail message. Moreover, Content-Type refers to a
given MIME body part, not to the message as a whole.
We wish to avoid scanning the entire message. In addition, we wish to avoid having to create multiple aliases for multipart/mixed every time someone identifies a new primary content type. Multiple aliases for multipart/mixed are not desirable as they remove the possibility for specifying a message as multipart/alternate, multipart/parallel, or multipart/encrypted, for example.
我们希望避免扫描整个邮件。此外，我们希望避免每次有人标识新的主内容类型时，都必须为multipart/mixed创建多个别名。对于multipart/mixed，不需要使用多个别名，因为它们消除了将消息指定为multipart/alternate、multipart/parallel或multipart/encrypted的可能性。
Since the message context is an attribute of the entire message, it is logical to define a new top-level (RFC 2822 [3]) message attribute. To this end, this document introduces the message attribute "Message-Context".
由于消息上下文是整个消息的属性，因此定义新的顶级（RFC 2822[3]）消息属性是合乎逻辑的。为此，本文引入了消息属性“消息上下文”。
Message-Context only serves to identify the message context. It does not provide any indication of content that the UA must be capable of delivering. It does not imply any message disposition or delivery notification. There is a related effort to define Critical Content of Internet Mail [8] that one might use to perform these tasks.
消息上下文仅用于标识消息上下文。它没有提供UA必须能够交付的任何内容指示。它并不意味着任何消息处理或传递通知。有一个相关的工作来定义Internet邮件[8]的关键内容，人们可以使用它来执行这些任务。
Message-Context is only an indicator. We do not intend for it to convey information that is critical for presentation of the message. One can conceive of goofy situations, such as a message marked "voice-message" but without an audio body part. In this case, the fact that the contents of a message don't match its context does not mean the receiving system should generate an error report or fail to deliver or process the message.
消息上下文只是一个指示符。我们不打算让它传达对信息表达至关重要的信息。人们可以想象愚蠢的情况，例如标记为“语音消息”但没有音频主体部分的消息。在这种情况下，消息的内容与其上下文不匹配并不意味着接收系统应该生成错误报告或无法传递或处理消息。
The Message-Context reference field is a top-level header inserted by the sending UA to indicate the context of the message.
消息上下文引用字段是由发送UA插入的顶级标头，用于指示消息的上下文。
A receiving user agent MUST NOT depend on the indicated message-context value in a way that prevents proper presentation of the message. If the value is incorrect or does not match the message content, the receiving user agent MUST still be capable of displaying the message content at least as meaningfully as it would if no Message-Context value were present.
接收用户代理不能以阻止正确显示消息的方式依赖所指示的消息上下文值。如果该值不正确或与消息内容不匹配，则接收用户代理仍必须能够显示消息内容，至少与不存在消息上下文值时一样有意义。
One can envision situations where a well-formed message ends up not including a media type one would expect from the message-context. For example, consider a voice messaging system that records a voice message and also performs speech-to-text processing on the message. The message then passes through a content gateway, such as a firewall, that removes non-critical body parts over a certain length. The receiving user agent will receive a message in the voice-message context that has only a text part and no audio. Even though the message does not have audio, it is still in the voice message context.
我们可以设想这样的情况：格式良好的消息最终不包括消息上下文中预期的媒体类型。例如，考虑语音消息系统，该语音消息系统记录语音消息，并对消息执行语音到文本处理。然后，该消息将通过一个内容网关（如防火墙），该网关将在一定长度内删除非关键的身体部位。接收用户代理将在语音消息上下文中接收只有文本部分而没有音频的消息。即使消息没有音频，它仍然在语音消息上下文中。
Said differently, the receiving UA can use the message-context to determine whether, when, and possibly where to display a message. However, the message-context should not affect the actual rendering or presentation. For example, if the message is in the voice-message context, then don't try to send it to a fax terminal. Conversely, consider the case of a message in the voice-message context that gets delivered to a multimedia voice terminal with a printer. However, this message only has fax content. In this situation, the "voice-message" context should not stop the terminal from properly rendering the message.
换言之，接收UA可以使用消息上下文来确定是否、何时以及可能在何处显示消息。但是，消息上下文不应影响实际的呈现或表示。例如，如果消息在语音消息上下文中，则不要尝试将其发送到传真终端。相反，考虑语音消息上下文中的消息，该消息通过打印机发送到多媒体语音终端。但是，此邮件仅包含传真内容。在这种情况下，“语音消息”上下文不应阻止终端正确呈现消息。
The syntax of the Message-Context field, described using the ABNF [4] is as follows. Note that the Message-Context header field name and message-context-class values are not case sensitive.
使用ABNF[4]描述的消息上下文字段的语法如下所示。请注意，消息上下文标题字段名称和消息上下文类值不区分大小写。
"Message-Context" ":" message-context-class CRLF
“消息上下文”“：”消息上下文类CRLF
The message-context-class indicates the context of the message. This is an IANA registered value. Current values for message-context-class are as follows.
message context类指示消息的上下文。这是IANA注册值。消息上下文类的当前值如下所示。
message-context-class = ( "voice-message"
/ "fax-message"
/ "pager-message"
/ "multimedia-message"
/ "text-message"
/ "none"
)
message-context-class = ( "voice-message"
/ "fax-message"
/ "pager-message"
/ "multimedia-message"
/ "text-message"
/ "none"
)
Note: The values for Message-Context MUST be IANA registered values following the directions in the IANA Considerations section below.
注意：消息上下文的值必须是IANA注册值，遵循下面IANA注意事项部分中的说明。
The voice-message class states the message is a voice mail message.
voice message类声明消息是语音邮件消息。
The fax-message class states the message is a facsimile mail message.
fax message类声明消息是传真邮件消息。
The pager-message class states the message is a page, such as a text or numeric pager message or a traditional short text message service (SMS) message.
寻呼机消息类声明消息是一个页面，例如文本或数字寻呼机消息或传统的短文本消息服务（SMS）消息。
The multimedia-message class states the message is an aggregate multimedia message, such as a message specified by [9]. This helps identify a message in a multimedia context. For example, a MIME multipart/related [10] data part and resource part looks the same as a multimedia MHTML multipart/related. However, the semantics are quite different.
彩信类声明该消息是聚合彩信，如[9]指定的消息。这有助于在多媒体环境中识别消息。例如，MIME多部分/相关[10]数据部分和资源部分看起来与多媒体MHTML多部分/相关部分相同。然而，语义是完全不同的。
The text-message class states the message is a traditional internet mail message. Such a message consists of text, possibly richly formatted, with or without attachments.
文本消息类声明消息是传统的internet邮件消息。这样的消息由文本组成，可能格式丰富，有或没有附件。
The none class states there is no context information for this message.
none类声明此消息没有上下文信息。
If a message has no Message-Context reference field, a receiving user agent MUST treat it the same as it would if the message has a "none" value.
如果消息没有消息上下文引用字段，则接收用户代理必须将其视为与消息具有“none”值时相同的处理方式。
The intention for this header is to be an indicator of message context only. One can imagine someone creating an "Application" Message-Context. A poorly designed user agent could blindly execute a mailed program based on the Message-Context. Don't do that!
此标头的目的只是作为消息上下文的指示符。可以想象有人创建了一个“应用程序”消息上下文。设计糟糕的用户代理可能会根据消息上下文盲目地执行邮件程序。不要那样做！
One can envision a denial of service attack by bombing a receiver with a message that has a Message-Context that doesn't fit the profile of the actual body parts. This is why the receiver considers the Message-Context to be a hint only.
我们可以设想，通过用一条消息轰炸一个接收者，该消息的消息上下文与实际身体部位的轮廓不符，从而导致拒绝服务攻击。这就是为什么接收者认为消息上下文只是一个提示。
Section 8.3 is a registration for a new top-level RFC 2822 [3] message header, "Message-Context".
第8.3节是注册新的顶级RFC 2822[3]消息头“消息上下文”。
This document creates an extensible set of context types. To promote interoperability and coherent interpretations of different types, a central repository has been established for well-known context types.
本文档创建一组可扩展的上下文类型。为了促进不同类型的互操作性和一致性解释，已经为著名的上下文类型建立了一个中央存储库。
The IANA has created a repository for context types called "Internet Message Context Types". Following the policies outlined in [5], this repository is "Specification Required" by RFC. Section 8.1 describes the initial values for this registry.
IANA已经为称为“Internet消息上下文类型”的上下文类型创建了一个存储库。按照[5]中概述的策略，此存储库是RFC的“规范要求”。第8.1节描述了该注册表的初始值。
To create a new message context type, you MUST publish an RFC to document the type. In the RFC, include a copy of the registration template found in Section 8.2 of this document. Put the template in your IANA Considerations section, filling-in the appropriate fields. You MUST describe any interoperability and security issues in your document.
要创建新的消息上下文类型，必须发布RFC以记录该类型。在RFC中，包括本文件第8.2节中的注册模板副本。将模板放在您的IANA注意事项部分，填写适当的字段。您必须在文档中描述任何互操作性和安全性问题。
Internet Message Content Types
==============================
Internet Message Content Types
==============================
Value Description Reference
----- ----------- ---------
voice-message Indicates a message whose primary This RFC
content is a voice mail message. The
primary content is audio data. The
context is usually a message recorded
from a voice telephone call.
Value Description Reference
----- ----------- ---------
voice-message Indicates a message whose primary This RFC
content is a voice mail message. The
primary content is audio data. The
context is usually a message recorded
from a voice telephone call.
fax-message Indicates a message whose primary This RFC content is a fax mail message. The primary content is image data. The context is usually a message recorded from a facsimile telephone call.
传真消息表示此RFC内容的主要内容是传真邮件的消息。主要内容是图像数据。上下文通常是从传真电话中记录的消息。
pager-message Indicates a message whose primary This RFC content is a page. The primary content is text data. The context is an urgent message usually of a limited length.
寻呼机消息表示此RFC内容的主要内容是页面的消息。主要内容是文本数据。上下文通常是长度有限的紧急消息。
multimedia-message Indicates a message whose primary This RFC content is a multimedia message. The primary content is multimedia, most likely MHTML. The context is often spam or newsletters.
彩信表示此RFC内容的主要内容是彩信的信息。主要内容是多媒体，最有可能是MHTML。上下文通常是垃圾邮件或时事通讯。
text-message Indicates a classic, text-based, This RFC Internet message.
文本消息表示基于文本的经典RFC Internet消息。
None Indicates an unknown message context. This RFC
None表示消息上下文未知。这个RFC
In the following template, a pipe symbol, "|", precedes instructions or other helpful material. Be sure to replace "<classname>" with the class name you are defining.
在以下模板中，管道符号“|”位于说明或其他有用材料之前。确保用您正在定义的类名替换“<classname>”。
Message-Context class name: <classname>
消息上下文类名：<classname>
Summary of the message class:
| Include a short (no longer than 4 lines) description or summary
| Examples:
| "Palmtop devices have a 320x160 pixel display, so we can..."
| "Color fax is so different than black & white that..."
Person & email address to contact for further information:
| Name & e-mail
Summary of the message class:
| Include a short (no longer than 4 lines) description or summary
| Examples:
| "Palmtop devices have a 320x160 pixel display, so we can..."
| "Color fax is so different than black & white that..."
Person & email address to contact for further information:
| Name & e-mail
To: iana@iana.org Subject: Registration of New RFC 2822 Header
致：iana@iana.org主题：注册新的RFC 2822标题
RFC 2822 Header Name: Message-Context
RFC 2822标头名称：消息上下文
Allowable values for this parameter: Please create a new registry for Primary Context Class registrations. See section 8.1 of this document for the initial values.
此参数的允许值：请为主上下文类注册创建新注册表。初始值见本文件第8.1节。
RFC 2822 Section 3.6 Repeat Value: Field Min Number Max Number Notes Message-Context 0 1
RFC 2822第3.6节重复值：字段最小编号最大编号注释消息上下文0 1
Person & email address to contact for further information: Eric Burger e.burger@ieee.org
联系人和电子邮件地址以获取更多信息：Eric Burger e。burger@ieee.org
This section is not a normative part of this document. We include it here as a historical perspective on the issue of multimedia message types.
本节不是本文件的规范性部分。我们在这里把它作为多媒体信息类型问题的历史视角。
These scenarios are neither comprehensive nor fixed. For example, e-mails being typically text-based do not mean that they cannot convey a voice-message. This very mutability serves to underline the desirability of providing some explicit message context hint.
这些场景既不全面也不固定。例如，通常基于文本的电子邮件并不意味着它们不能传递语音信息。这种可变性强调了提供一些明确的消息上下文提示的可取性。
Internet e-mail carries textual information. Sometimes it conveys computer application data of arbitrary size.
因特网电子邮件携带文本信息。有时它传送任意大小的计算机应用程序数据。
Typically, one uses e-mail for non-urgent messages, which the recipient will retrieve and process at a time convenient to her.
通常情况下，用户使用电子邮件发送非紧急消息，收件人将在方便的时候检索和处理这些消息。
The normal device for receiving and processing e-mail messages is some kind of personal computer. Modern personal computers usually come with a reasonably large display and an alphanumeric keyboard. Audio, video, and printing capabilities are not necessarily available.
接收和处理电子邮件的普通设备是某种个人计算机。现代个人电脑通常配有相当大的显示屏和字母数字键盘。音频、视频和打印功能不一定可用。
One can use E-mail for communication between two parties (one-to-one), a small number of known parties (one-to-few) or, via an e-mail distribution list, between larger numbers of unknown parties (one-to-many).
可以使用电子邮件在两方（一对一）、少数已知方（一对少数）之间进行通信，或者通过电子邮件通讯组列表在更多未知方（一对多）之间进行通信。
One of the endearing characteristics of e-mail is the way that it allows the recipient to forward all or part of the message to another party, with or without additional comments. It is quite common for an e-mail to contain snippets of content from several previous messages. Similar features apply when replying to e-mail.
电子邮件的一个令人喜爱的特点是，它允许收件人将邮件的全部或部分转发给另一方，无论是否有其他评论。一封电子邮件包含以前几封邮件的内容片段是很常见的。回复电子邮件时也会使用类似的功能。
One uses a pager message to convey notifications and alerts. For the most part, these notifications are textual information of limited size. The typical limit is 160 characters. People use pages for relatively urgent messages, which the sender wishes the receiver to see and possibly respond to within a short time period. Pager messages are often used as a way of alerting users to something needing their attention. For example, a system can use a page to notify a subscriber there is a voicemail message requiring her attention.
一种是使用寻呼机消息来传递通知和警报。在大多数情况下，这些通知是大小有限的文本信息。典型限制为160个字符。人们使用页面发送相对紧急的消息，发送者希望接收者在短时间内看到这些消息并可能作出响应。寻呼机消息通常被用作提醒用户注意需要注意的事情的一种方式。例如，系统可以使用页面通知订阅者有语音邮件消息需要她的注意。
Example devices for sending and receiving a pager message are a mobile telephone with a small character display or a text pager. Personal computers and personal digital assistants (PDAs) can also participate in pager messaging.
用于发送和接收寻呼机消息的示例设备是具有小字符显示器的移动电话或文本寻呼机。个人计算机和个人数字助理（PDA）也可以参与寻呼机消息传递。
Currently, the most common use of pager messages are between just two parties (one-to-one).
目前，寻呼机消息最常见的使用是在两方之间（一对一）。
One delivery method for pager messages is the short text messaging service (SMS). SMS is a facility that has evolved for use with mobile telephones, and has an associated per-message transmission charge. Note that the focus here is on the notification aspect of SMS. From the beginning, SMS was envisioned to be more than a simple pager service. Operators can use SMS to provision the phone, for example. From the subscriber point of view, SMS has evolved considerably from its origins as a pure pager replacement service. For example, with mobile originate service, people can have two-way text chat sessions using SMS and a mobile phone. In addition, there are SMS-enabled handsets that can display pictures. However, for the purposes of this document, there is still a need to capture the essence of a "highly urgent, short-text, notification or alert" service.
寻呼机消息的一种传递方法是短文本消息服务（SMS）。SMS是一种已发展为可与移动电话一起使用的设施，并具有相关的每条消息传输费用。注意，这里的重点是SMS的通知方面。从一开始，SMS就被设想为不仅仅是一种简单的寻呼机服务。例如，运营商可以使用短信来配置手机。从用户的角度来看，SMS已经从最初的单纯寻呼机替代服务发展到现在。例如，通过移动发起服务，人们可以使用短信和手机进行双向文本聊天。此外，还有支持SMS的手机可以显示图片。然而，就本文件而言，仍然需要抓住“高度紧急、短文本、通知或警报”服务的本质。
Users often send pager messages in isolation, rather than as part of a longer exchange. One use for them is as a prompt or invitation to communicate by some more convenient and content-rich method, such as a telephone call.
用户通常单独发送寻呼机消息，而不是作为较长交换的一部分。它们的一个用途是作为一种提示或邀请，通过一些更方便、内容更丰富的方法进行交流，如电话。
People use facsimile to convey image information of moderate size, typically a small number of pages. Sometimes people use facsimile for larger documents.
人们使用传真来传递中等大小的图像信息，通常是少量的页面。有时人们用传真来处理较大的文件。
Facsimile is a facility that usually uses circuit-switched telephone circuits, with connection-time charges. Message transfer takes place in real-time. Thus, people often use facsimile for urgent communication.
传真是一种设施，通常使用电路交换电话电路，连接时间收费。消息传输实时进行。因此，人们经常使用传真进行紧急通信。
The normal device for sending and receiving a facsimile is a self-contained scanning and printing device connected to a telephone line or a desktop computer.
发送和接收传真的普通设备是连接到电话线或台式计算机的独立扫描和打印设备。
Most facsimiles are between just two parties (one-to-one). However, a significant portion of facsimile service is broadcast between multiple parties (one-to-many).
大多数传真是在两方（一对一）之间进行的。然而，传真服务的很大一部分是在多方（一对多）之间广播的。
Most facsimile exchanges are in isolation, rather than as part of a longer exchange. Facsimile data is typically not suitable for further processing by computer.
大多数传真交换是单独进行的，而不是作为长期交换的一部分。传真数据通常不适合计算机进一步处理。
People use voice mail to convey audio information, almost exclusively human speech.
人们使用语音邮件传递音频信息，几乎完全是人类的语言。
Voice mail is a facility that usually uses circuit-switched telephone circuits, with modest connection-time charges, often used for moderately urgent messages. A common use for them is as a prompt or invitation to communicate by some more convenient method, such as a telephone call. In most, but not all cases, the sender of a voice message does not want to send a message at all. Rather, they wished to engage in a real-time conversation.
语音邮件是一种通常使用电路交换电话电路的设施，具有适度的连接时间费用，通常用于适度紧急的消息。它们的一个常见用途是作为一种提示或邀请，通过一些更方便的方法进行交流，如电话。在大多数情况下，但并非所有情况下，语音消息的发送者根本不想发送消息。相反，他们希望进行实时对话。
The normal device for sending and receiving a voice mail is a telephone handset.
发送和接收语音邮件的普通设备是电话听筒。
Voice messages are usually sent between just two parties (one-to-one).
语音信息通常只在两方之间发送（一对一）。
Voice mail data is not generally suitable for further processing by computer.
语音邮件数据通常不适合计算机进一步处理。
We define a multimedia message as a message containing more than one basic media type (text, image, audio, video, model, application).
我们将彩信定义为包含多种基本媒体类型（文本、图像、音频、视频、模型、应用程序）的消息。
The following are some characteristics of a multimedia message.
以下是彩信的一些特征。
In some cases, a multimedia message is just e-mail with an attachment that a multimedia display application presents. For example, I can send you an MP3 of something I recorded in my garage today.
在某些情况下，彩信只是带有多媒体显示应用程序显示的附件的电子邮件。例如，我可以给你发一个我今天在车库里录制的MP3。
In other cases, a multimedia message represents a convergence between two or more of the scenarios described above. For example, a voice message with an accompanying diagram or a talking head video message is a multimedia message.
在其他情况下，彩信表示上述两个或多个场景之间的融合。例如，带有附图的语音消息或会说话的头部视频消息就是彩信。
The characteristics will vary somewhat with the intent of the sender. This in turn may affect the user agent or application used to render the message.
这些特征会因发送者的意图而有所不同。这反过来可能会影响用于呈现消息的用户代理或应用程序。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[3] Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[4] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[4] Crocker，D.和P.Overell，编辑，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[5] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Alvestrand，H.和T.Narten，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[6] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[6] Troost，R.，Dorner，S.和K.Moore，“在互联网消息中传达呈现信息：内容处置标题字段”，RFC 2183，1997年8月。
[7] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME Sub-type Registration", RFC 2423, September 1998.
[7] Vaudreuil，G.和G.Parsons，“VPIM语音消息MIME子类型注册”，RFC 24231998年9月。
[8] Burger, E., "Critical Content of Internet Mail", RFC 3459, January 2003.
[8] E.Burger，“互联网邮件的关键内容”，RFC 3459，2003年1月。
[9] Palme, J., Hopmann, A. and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999.
[9] Palme，J.，Hopmann，A.和N.Shelness，“聚合文档的MIME封装，如HTML（MHTML）”，RFC2557，1999年3月。
[10] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[10] Levinson，E.，“MIME多部分/相关内容类型”，RFC 2387，1998年8月。
Many of the ideas here arose originally from a discussion with Jutta Degener.
这里的许多想法最初来自于与Jutta Degener的讨论。
We'd also like to thank Keith Moore for helping us tighten-up our explanations.
我们还要感谢基思·摩尔帮助我们加强解释。
In the last round, we got some rather good advise from Caleb Clausen and Dave Aronson.
在最后一轮中，我们从Caleb Clausen和Dave Aronson那里得到了一些相当好的建议。
Antti Vaha-Sipila pointed out advances in SMS, while Stuart McRae helped distil the essence of the pager service vis a vis SMS.
Antti Vaha Sipila指出了SMS的进步，而Stuart McRae帮助提炼了寻呼机服务相对于SMS的本质。
We offer an extra special thanks to Greg Vaudreuil for pulling RFC 2557 out of his hat.
我们特别感谢Greg Vaudreuil从他的帽子里拿出RFC 2557。
Eric Burger SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA
Eric Burger SnowShore Networks，Inc.美国马萨诸塞州切姆斯福德Billerica路285号01824-4120
Phone: +1 978 367 8403
EMail: e.burger@ieee.org
Phone: +1 978 367 8403
EMail: e.burger@ieee.org
Emily Candell Comverse Network Systems 200 Quannapowitt Pkwy. Wakefield, MA 01880 USA
Emily Candell Comverse网络系统200 Quannapowitt Pkwy。美国马萨诸塞州威克菲尔德01880
Phone: +1 781 213 2324
EMail: emily.candell@comverse.com
Phone: +1 781 213 2324
EMail: emily.candell@comverse.com
Graham Klyne Nine by Nine United Kingdom
格雷厄姆·克莱恩九乘九英国
EMail: GK-IETF@ninebynine.org
EMail: GK-IETF@ninebynine.org
Charles Eliot Microsoft Corporation One Microsoft Way Redmond WA 98052 USA
查尔斯·艾略特微软公司美国华盛顿州雷德蒙一路微软98052
Phone: +1 425 706 9760
EMail: charle@Microsoft.com
Phone: +1 425 706 9760
EMail: charle@Microsoft.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。