[要約] RFC 3458は、インターネットメールのメッセージコンテキストに関する情報を提供するものであり、メールの送信者と受信者の間でのメッセージの意図や文脈を明確にすることを目的としています。
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.
Copyright（c）The Internet Society（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メッセージヘッダー「Message-Context」について説明しています。このヘッダーは、メッセージのコンテキストとプレゼンテーションの特性に関する情報を提供します。
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".
このドキュメントは、「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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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がさまざまな方法で提示する可能性のあるメッセージを受信します。たとえば、従来の電子メールでは、受信者が表示して編集する簡単なテキストメッセージを使用します。1つのUAは、FAX画像を自動的に印刷できます。別の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 オーディオデータと画像データを含むメッセージ：これはたまたま音声解説があるファックスメッセージですか？それはいくつかの補足図を伴う音声メッセージですか？それは完全にマルチメディアメッセージであり、すべての部品が平等に重要であると予想されますか？
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.
メッセージの解釈コンテキストを示す1つの方法は、メッセージ内のメディアタイプを調べることです。ただし、これには、この決定を行う前に、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.
MultiPart/* MIMEサブタイプ（コンテンツタイプ）を登録することにより、メッセージコンテキストを示すことを検討しました。たとえば、VPIMワークグループは、メッセージが主にボイスメールであることを示すために、MultiPart/Voice-Messageを登録しています[7]。ただし、MultiPart/Voice-Messageは、MultiPart/Mixedの構文で同一です。唯一の違いは、VPIMメール転送エージェントとユーザーエージェントが、ボイスメールメッセージであることに基づいてメッセージの特別な処理を実行できることを認識していることです。さらに、コンテンツタイプは、メッセージ全体ではなく、特定のmime体の部分を指します。
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」を紹介します。
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.
Message-Contextは、メッセージコンテキストを識別するのにのみ役立ちます。UAが配信できる必要があるというコンテンツの兆候は提供されません。メッセージの処分や配信通知を意味するものではありません。これらのタスクを実行するために使用する可能性のあるインターネットメール[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.
Message-contextはインジケータのみです。メッセージの提示に重要な情報を伝えるつもりはありません。「音声メッセージ」とマークされたメッセージなど、間抜けな状況を想像することができますが、オーディオ本体の部分はありません。この場合、メッセージの内容がそのコンテキストと一致しないという事実は、受信システムがエラーレポートを生成したり、メッセージの配信または処理に失敗することを意味しません。
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はメッセージ - コンテキストを使用して、メッセージを表示するかどうか、いつ、場合によっては表示できます。ただし、メッセージコンテストは実際のレンダリングやプレゼンテーションに影響しないはずです。たとえば、メッセージが音声メッセージのコンテキストにある場合は、ファックス端末に送信しようとしないでください。逆に、プリンターを備えたマルチメディア音声ターミナルに配信される音声メッセージコンテキストのメッセージのケースを検討してください。ただし、このメッセージにはFAXコンテンツのみがあります。この状況では、「音声メッセージ」コンテキストが端末がメッセージを適切にレンダリングするのを止めるべきではありません。
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
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考慮事項セクションの指示に従って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.
Multimedia-Messageクラスでは、メッセージは[9]で指定されたメッセージなどの集約マルチメディアメッセージであると述べています。これにより、マルチメディアコンテキストでメッセージを識別することができます。たとえば、Mime MultiPart/関連[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]メッセージヘッダー「Message-Context」の登録です。
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.
FAXメッセージは、この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.
Multimedia-Messageは、この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.
次のテンプレートでは、パイプシンボル「|」は、命令またはその他の役立つ素材に先行します。「<classname>」を定義しているクラス名に必ず置き換えてください。
Message-Context class name: <classname>
Message-Contextクラス名：<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
To: iana@iana.org Subject: Registration of New RFC 2822 Header
宛先：iana@iana.org件名：新しいRFC 2822ヘッダーの登録
RFC 2822 Header Name: Message-Context
RFC 2822ヘッダー名：Message-Context
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
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).
2つの関係者（1対1）間の通信に電子メールを使用することができます（1対1）、少数の既知のパーティー（1対FEW）、または電子メール配信リストを介して、より多くの不明なパーティー（1つは1つ）間で使用できます。 - マニュ）。
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.
電子メールの魅力的な特性の1つは、追加のコメントの有無にかかわらず、受信者がメッセージのすべてまたは一部を別のパーティに転送できるようにする方法です。電子メールでは、以前のいくつかのメッセージからコンテンツのスニペットを含めることが非常に一般的です。同様の機能が電子メールに返信するときに適用されます。
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.
ポケットベルメッセージの1つの配信方法は、短いテキストメッセージングサービス（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.
Facsimileは、通常、接続時間の料金を備えたサーキット切り替えの電話回路を使用する施設です。メッセージ転送はリアルタイムで行われます。したがって、人々はしばしば緊急のコミュニケーションのためにファクシミリを使用します。
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）の間です。ただし、ファクシミリサービスのかなりの部分が複数の当事者間で放送されます（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).
音声メッセージは通常、2つのパーティー（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] 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。and P. Overell、eds。、「構文仕様のための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 Voice Message 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] Palme、J.、Hopmann、A。、およびN. Shelness、「HTML（MHTML）などの集約文書のMIMEカプセル化」、RFC 2557、1999年3月。
[10] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[10] Levinson、E。、「The Mime MultiPart/関連コンテンツタイプ」、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.
また、説明を強化してくれたKeith Mooreに感謝します。
In the last round, we got some rather good advise from Caleb Clausen and 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.
RFC 2557を帽子から引き出してくれたGreg Vaudreuilに特別な感謝を申し上げます。
Eric Burger SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA
Eric Burger Snowshore Networks、Inc。285 Billerica Rd。Chelmsford、MA 01824-4120 USA
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 Network Systems 200 Quannapowitt Pkwy。ウェイクフィールド、マサチューセッツ州01880 USA
Phone: +1 781 213 2324
EMail: emily.candell@comverse.com
Graham Klyne Nine by Nine United Kingdom
Graham Klyne Nine by Nine英国
EMail: GK-IETF@ninebynine.org
Charles Eliot Microsoft Corporation One Microsoft Way Redmond WA 98052 USA
チャールズ・エリオット・マイクロソフト・コーポレーションワン・マイクロソフト・ウェイ・レドモンドワシントン州98052 USA
Phone: +1 425 706 9760
EMail: charle@Microsoft.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。