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
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
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.
この文書は、インターネットメールメッセージの送信者がメッセージのコンテキスト情報を伝えることを可能にするメカニズムを説明しています。この情報を考慮して、受信するユーザエージェント（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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 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.
マルチメディアメッセージングシステムは、UAは、さまざまな方法で提示することができるメッセージを受信します。例えば、従来の電子メールは、受信者が表示され、編集、単純なテキストメッセージを使用しています。一つのUAは、自動的にファックスの画像を印刷することができます。別のUAは、電話の受話器を介して音声メッセージを再生することができます。同様に、受信したデスクトップコンピュータは、ローカルアプリケーションを使用して電子メールを介して転送文書を処理または提示することができます。新興国と今後の展開は、ビデオメッセージやポケベルメッセージなどのユーザー・プレゼンテーションのために、独自の特徴を持っている他の形態の情報を、配信することができます。
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 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 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.
私たちは、メッセージ全体をスキャン避けたいです。また、当社は、マルチパート/混合のために、誰かが新しいプライマリコンテンツの種類を特定するたびに、複数のエイリアスを作成することを避けることを望みます。彼らは、マルチパート/代替として、マルチパート/パラレル、又はマルチパート/暗号化され、たとえば、メッセージを特定するための可能性を除去するようにマルチパート/混合のための複数のエイリアスは望ましくありません。
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が供給できる必要があり、コンテンツの兆候を提供していません。これは、任意のメッセージ処分または配信通知を意味するものではありません。 1は、これらのタスクを実行するために使用する可能性のあるインターネットメール[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.
一つは、十分に形成されたメッセージは、1がメッセージ・コンテキストから期待のメディアタイプを含まない終わるような状況を想像することができます。例えば、音声メッセージを録音しても、メッセージの音声テキスト処理を行い、音声メッセージングシステムを検討してください。メッセージは、その後、特定の長さにわたって非クリティカル身体部分を除去し、ファイアウォールなど、コンテンツのゲートウェイを通過します。受信するユーザエージェントは、テキストのみの部分とオーディオなしを持っている音声メッセージコンテキストにメッセージが表示されます。メッセージは音声はありませんが、それは音声メッセージコンテキストにまだあります。
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.
メッセージコンテキストフィールドの構文は、次のように[4]でABNFを用いて説明しました。メッセージコンテキストヘッダフィールド名とメッセージコンテキストクラスの値は大文字と小文字を区別しないことに注意してください。
"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.
メッセージコンテキストクラスは、メッセージの内容を示しています。これは、IANA登録された値です。次のようにメッセージコンテキスト・クラスの現在の値です。
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 Considerations部の指示以下の値をIANAに登録しなければなりません。
The voice-message class states the message is a voice mail message.
音声メッセージクラスは、メッセージがボイスメールメッセージで述べています。
The fax-message class states the message is a facsimile mail 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.
テキスト・メッセージクラスは、メッセージは、従来のインターネットメールメッセージで述べています。このようなメッセージは、おそらく豊かでまたは添付ファイルなしで、書式設定、テキストで構成されています。
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.
メッセージが全くメッセージコンテキスト参照フィールドを持っていない場合、メッセージは、「なし」の値を有する場合、受信ユーザエージェントはそれと同じように同じに扱わなければなりません。
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は、「インターネットメッセージコンテキストタイプ」と呼ばれるコンテキストタイプのリポジトリを作成しました。 [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
==============================
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のコンテンツはFAXメールメッセージであるメッセージを示します。一次コンテンツが画像データです。コンテキストは通常、ファクシミリ電話から録音されたメッセージです。
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インターネットメッセージを示します。
None Indicates an unknown message context. This RFC
いずれも、未知のメッセージコンテキストを示していません。この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.
次のテンプレート、パイプ記号で、「|」、命令または他の有用な材料を先行します。あなたが定義しているクラス名に「<クラス名>」置き換えてください。
Message-Context class name: <classname>
メッセージContextクラス名：<クラス名>
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
メッセージクラスの概要：| |短い（もはや4行以上）の記述または要約を含みません例：| 「パームトップデバイスは、320x160ピクセルのディスプレイを持っているので、我々はできます...」| 「カラーファクスは白黒に比べてとても異なっている...」人とEメールアドレス詳細のために連絡します：|名前と電子メール
To: iana@iana.org Subject: Registration of New RFC 2822 Header
To：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
人とEメールアドレスは、詳細のために連絡する：エリックバーガー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).
一つは、未知の当事者の多数（一方との間に、電子メールの配布リストを介して、両当事者（一対一）、既知の当事者（1対数）又は少数の間の通信のためにEメールを使用することができ-to-多く）。
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).
現在、ポケベルメッセージの最も一般的な用途は、ちょうど2つの政党（1対1）の間にあります。
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は、純粋なページャ交換サービスのような起源から大幅に進化してきました。例えば、モバイル発信サービスで、人々は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.
ユーザーは、多くの場合、かなり長い交流の一環としてよりも、孤立してポケベルメッセージを送信します。彼らのために1つの用途は、電話の呼び出しなど、いくつかのより便利でコンテンツが豊富な方法で通信するプロンプトや招待状などです。
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).
ほとんどのファクシミリは、ちょうど2つの政党（1対1）の間にあります。しかし、ファクシミリサービスのかなりの部分は、複数の当事者（一対多）の間に放送されます。
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).
ボイスメッセージは、通常は二者（1対1）との間で送信されます。
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.
他の場合には、マルチメディアメッセージは、上述したシナリオの2つ以上の間で収束を表します。例えば、添付図面又はトーキングヘッドビデオメッセージと音声メッセージがマルチメディアメッセージです。
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]ブラドナーの、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[3]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[4] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[4]クロッカー、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.、ドルナー、S.とK.ムーア、 "インターネット・メッセージでプレゼンテーション情報を伝える：コンテンツ-Dispositionヘッダーフィールド"、RFC 2183、1997年8月。
[7] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME Sub-type Registration", RFC 2423, September 1998.
[7]ボードルイ、G.とG.パーソンズ、 "VPIMボイスメッセージMIMEサブタイプ登録"、RFC 2423、1998年9月。
[8] Burger, E., "Critical Content of Internet Mail", RFC 3459, January 2003.
[8]バーガー、E.、 "インターネットメールの重要なコンテンツ"、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]パルメ、J.、Hopmann、A.及びN. Shelness、RFC 2557、1999マーチ "は、HTML（MHTML）として集約文書のMIMEカプセル化"。
[10] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[10]レビンソン、E.、 "MIMEマルチパート/関連コンテンツ・タイプ"、RFC 2387、1998年8月。
Many of the ideas here arose originally from a discussion with 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.
最後のラウンドでは、我々はカレブクラウゼンとDaveアロンソンからいくつかのかなり良いアドバイスを得ました。
Antti Vaha-Sipila pointed out advances in SMS, while Stuart McRae helped distil the essence of the pager service vis a vis SMS.
スチュアート・マクレーがヴィザヴィSMSポケットベルサービスの本質を蒸留助けながら、アンティVaha-Sipilaは、SMSの進歩を指摘しました。
We offer an extra special thanks to Greg Vaudreuil for pulling RFC 2557 out of his hat.
私たちは、彼の帽子のうち、RFC 2557を引っ張るためグレッグボードルイに余分な特別な感謝を提供します。
Eric Burger SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA
エリックバーガーSnowShoreネットワークス株式会社285ビレリカRdを。チェルムズフォード、MA 01824-4120 USA
Phone: +1 978 367 8403 EMail: e.burger@ieee.org
電話：+1 978 367 8403 Eメール：e.burger@ieee.org
Emily Candell Comverse Network Systems 200 Quannapowitt Pkwy. Wakefield, MA 01880 USA
エミリーCandellコンバースネットワークシステム200 Quannapowittパークウェイ。ウェイクフィールド、MA 01880 USA
Phone: +1 781 213 2324 EMail: emily.candell@comverse.com
電話：+1 781 213 2324 Eメール：emily.candell@comverse.com
Graham Klyne Nine by Nine United Kingdom
ナインイギリスグラハムKlyneナイン
EMail: GK-IETF@ninebynine.org
メールアドレス：GK-IETF@ninebynine.org
Charles Eliot Microsoft Corporation One Microsoft Way Redmond WA 98052 USA
チャールズ・エリオットマイクロソフト社1つのマイクロソフト道、レドモンドWA 98052 USA
Phone: +1 425 706 9760 EMail: charle@Microsoft.com
電話：+1 425 706 9760 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。