RFC3458 日本語訳
3458 Message Context for Internet Mail. E. Burger, E. Candell, C.Eliot, G. Klyne. January 2003. (Format: TXT=34181 bytes) (Updated by RFC3938) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループE.バーガー要求をネットワークでつないでください: 3458SnowShoreはカテゴリをネットワークでつなぎます: 2003年1月9日までに標準化過程E.Candell Comverse C.エリオットマイクロソフト社G.Klyne Nine
Message Context for Internet Mail
インターネットメールのためのメッセージの文脈
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
このメモは新しいRFC2822メッセージヘッダー、「メッセージの文脈」について説明します。 このヘッダーはメッセージの文脈とプレゼンテーションの特性の情報を提供します。
A receiving user agent (UA) may use this information as a hint to optimally present the message.
受信ユーザエージェント(UA)は、メッセージを最適に提示するのにヒントとしてこの情報を使用するかもしれません。
Burger, et al. Standards Track [Page 1] RFC 3458 Message Context for Internet Mail January 2003
バーガー、他 規格はメール2003年1月にインターネットのためのRFC3458メッセージの文脈を追跡します[1ページ]。
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. 序論…2 2. このドキュメントで中古のコンベンション…3 3. 動機…3 4. 機能条件書…5 5. メッセージの文脈を決定します…6 6. メッセージの文脈参照分野…7 6.1. メッセージの文脈構文…7 6.2メッセージ文脈のクラスSyntax…7 6.2 .1声メッセージ…8 6.2 .2ファックスメッセージ…8 6.2 .3ポケットベルメッセージ…8 6.2 .4マルチメディアメッセージ…8 6.2 .5テキストメッセージ…8 6.2 .6 なにも…8 7. セキュリティ問題…9 8. IANA問題…9 8.1. メッセージcontent type登録証明書…9 8.2. 登録テンプレート…10 8.3. メッセージの文脈登録…11 9. 付録: いくつかのメッセージングシナリオ…12 9.1. インターネットメール…12 9.2. ポケットベルサービス…12 9.3. 電送します。13 9.4. ボイスメール…14 9.5. マルチメディアメッセージ…14 10. 参照…15 10.1 標準の参照…15 10.2 有益な参照…15 11. 承認…15 12. 作者のアドレス…16 13. 完全な著作権宣言文…17
1. Introduction
1. 序論
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".
このドキュメントは「メッセージの文脈」と呼ばれるRFC2822ヘッダーを指定します。
Burger, et al. Standards Track [Page 2] RFC 3458 Message Context for Internet Mail January 2003
バーガー、他 規格はメール2003年1月にインターネットのためのRFC3458メッセージの文脈を追跡します[2ページ]。
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]で説明されたContent気質MIME実体の使用と同様です。 満足している気質は、どう与えられた身体の部分を表示するかために受信Userエージェント(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が提示するメッセージをフィルターにかけます。
2. Conventions used in this document
2. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[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.
形式注意: メモ(これにおけるそのようなもの)は読者が不可欠のものは何も逃さないでスキップするかもしれないという追加不要不急な情報を提供します。 これらの不要不急な注意のプライマリ目的は、このドキュメントの原理に関して情報を伝達するか、または適切な歴史的であるか進化論の関係のこのドキュメントを置くことです。 conformant実装を構成する唯一の目的がことである読者はそのような情報をスキップするかもしれません。 しかしながら、それは私たちがなぜデザイン選択を確実にしたかを理解したがっている人の役に立つかもしれません。
3. Motivation
3. 動機
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が方法のバラエティーで提示するかもしれないメッセージを受け取ります。 例えば、伝統的なメールは受取人が表示するという簡単なテキスト・メッセージと編集を使用します。 1UAが自動的にファックスイメージを印刷するかもしれません。 別のUAは電話受話器を通して音声メールをプレーするかもしれません。 同様に受信デスクトップコンピュータ
Burger, et al. Standards Track [Page 3] RFC 3458 Message Context for Internet Mail January 2003
バーガー、他 規格はメール2003年1月にインターネットのためのRFC3458メッセージの文脈を追跡します[3ページ]。
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 自動前方に、与えられたメッセージは別のメッセージング環境(例えば、モバイル短いメッセージサービスへの1ページ)にタイプします。
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です。完全に、マルチメディア(すべての部品が等しい意味を運ぶと予想される)は通信しますか?
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音楽付属をもってありますか? 可能にされた非声のメール受信機の利益のために初期のテキストヘッダーと共にたまたま生成されたのは、音声メールですか?
Burger, et al. Standards Track [Page 4] RFC 3458 Message Context for Internet Mail January 2003
バーガー、他 規格はメール2003年1月にインターネットのためのRFC3458メッセージの文脈を追跡します[4ページ]。
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メッセージと伝統的なメールテキストを区別するのと気にかけると、どうなるでしょうか? ともに同じメディアタイプ、テキストですが、それらには、異なったユーザ文脈があります。
4. Functional Requirements
4. 機能条件書
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.
以下に注意してください。 ユーザエージェントがメッセージを転送するとき、私たちは明確にユーザエージェントの振舞いを指定しません。 明確に、ユーザエージェントは意識していた状態で文脈を通信させていて、重要なメッセージの文脈を提供するべきです。 簡単なケースのために何をしたらよいかは明白です。 ユーザが単に転送するメッセージはたぶん文脈を変わりがなく保つでしょう。 しかしながら、それは、いかなる他のシナリオのためのユーザエージェントの振舞いも指定するためにこのドキュメントの範囲を超えています。
Burger, et al. Standards Track [Page 5] RFC 3458 Message Context for Internet Mail January 2003
バーガー、他 規格はメール2003年1月にインターネットのためのRFC3458メッセージの文脈を追跡します[5ページ]。
5. Determining the Message Context
5. メッセージの文脈を決定します。
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.
私たちは、複合/*MIME「副-タイプ」(コンテントタイプ)を登録することによってメッセージの文脈を示すと考えました。 例えば、VPIM Work Groupはメッセージが主としてそうであることを示すために複合の、または、メッセージを声に出しているボイスメール[7]を登録しました。 しかしながら、声が通信させる複合/は構文が複合か混ぜられるのと同じです。 唯一の違いは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.
全体のメッセージをスキャンするのを避けたいと思います。 さらに、だれかが新しいプライマリcontent typeを特定するときはいつも、混ぜられた複合/のために複数の別名を作成しなければならないのを避けたいと思います。 複合/が混入して、例えば暗号化された複合か代替の複合の、または、平行なメッセージを指定するか、複合/のために可能性を取り除くので、複数の別名は望ましくはありません。
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".
メッセージの文脈が全体のメッセージの属性であるので、新しい最高レベルを定義するのは論理的です。(RFC2822[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]のCritical Contentを定義するために、関連する取り組みがあります。
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.
メッセージ文脈はインディケータにすぎません。 それは私たちがメッセージのプレゼンテーションに、重要な情報を伝えないつもりです。 人はおかしい状況、メッセージが「音声メール」をマークしましたが、オーディオ身体の部分のないそのようなものを想像できます。 この場合、メッセージの内容が文脈に合っていないという事実は、メッセージを受電方式がエラー・レポートを作るはずであることを意味するか、提供するか、または必ず処理します。
Burger, et al. Standards Track [Page 6] RFC 3458 Message Context for Internet Mail January 2003
バーガー、他 規格はメール2003年1月にインターネットのためのRFC3458メッセージの文脈を追跡します[6ページ]。
6. Message-Context Reference Field
6. メッセージの文脈参照分野
The Message-Context reference field is a top-level header inserted by the sending UA to indicate the context of the message.
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.
受信ユーザエージェントはメッセージの適切なプレゼンテーションを防ぐ方法で示されたメッセージ文脈価値に依存してはいけません。 値が不正確であるか、またはメッセージ内容に合っていないなら、受信ユーザエージェントはどんなMessage-文脈値も存在していないならそうするのと少なくとも同じくらい意味深長にメッセージ内容を表示するのがまだできなければなりません。
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が決定するメッセージの文脈を異なって、使用できると言う、いつ、ことによるとどこにメッセージを表示しますか? しかしながら、メッセージの文脈は実際のレンダリングかプレゼンテーションに影響するべきではありません。 例えば、メッセージが音声メール文脈にあるなら、ファックス端末にそれを送ろうとしないでください。 逆に、マルチメディア声に提供される音声メール文脈のメッセージのケースがプリンタで端末であると考えてください。 しかしながら、このメッセージには、ファックス内容があるだけです。 この状況で、「声のメッセージ」文脈は、端末が適切にメッセージを伝えるのを止めるべきではありません。
6.1. Message-Context Syntax
6.1. メッセージの文脈構文
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.
Message-文脈分野の構文であり、ABNFを使用することで説明されて、[4]は以下の通りです。 Message-文脈ヘッダーフィールド名とメッセージ文脈階級値が大文字と小文字を区別していないことに注意してください。
"Message-Context" ":" message-context-class CRLF
「「メッセージの文脈」」:、」 メッセージ文脈のクラスCRLF
6.2. message-context-class Syntax
6.2. メッセージ文脈のクラスSyntax
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が値を示したということです。 メッセージ文脈クラスのための現行価値は以下の通りです。
Burger, et al. Standards Track [Page 7] RFC 3458 Message Context for Internet Mail January 2003
バーガー、他 規格はメール2003年1月にインターネットのためのRFC3458メッセージの文脈を追跡します[7ページ]。
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部の方向に従って、値は、Message-文脈がIANAであるに違いないので、値を示しました。
6.2.1. voice-message
6.2.1. 音声メール
The voice-message class states the message is a voice mail message.
音声メールのクラスは、メッセージがボイスメールメッセージであると述べます。
6.2.2. fax-message
6.2.2. ファックス通信
The fax-message class states the message is a facsimile mail message.
ファックス通信のクラスは、メッセージがファクシミリメール・メッセージであると述べます。
6.2.3. pager-message
6.2.3. ポケットベルのメッセージ
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.
ポケットベルのメッセージのクラスは、メッセージが1ページであると述べます、テキスト、数値ポケットベルのメッセージまたは伝統的な短いテキストメッセージサービス(SMS)メッセージのように。
6.2.4. multimedia-message
6.2.4. マルチメディアメッセージ
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として同じように複合である、または関連していた状態で面相を分けます。 しかしながら、意味論は全く異なっています。
6.2.5. text-message
6.2.5. テキストメッセージ
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.
テキストメッセージのクラスは、メッセージが伝統的なインターネットメール・メッセージであると述べます。 そのようなメッセージは付属のあるなしにかかわらずことによると豊かにフォーマットされたテキストから成ります。
6.2.6. none
6.2.6. なし
The none class states there is no context information for this message.
クラスがそこに述べないなにもこのメッセージのための文脈情報ではありません。
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.
メッセージにMessage-文脈参照分野が全くないなら、受信ユーザエージェントはメッセージに「なにも」値があるなら扱うように同じようにそれを扱わなければなりません。
Burger, et al. Standards Track [Page 8] RFC 3458 Message Context for Internet Mail January 2003
バーガー、他 規格はメール2003年1月にインターネットのためのRFC3458メッセージの文脈を追跡します[8ページ]。
7. Security Considerations
7. セキュリティ問題
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!
このヘッダーのための意志はメッセージの文脈だけのインディケータであることです。 人は、だれかが「アプリケーション」Message-文脈を作成すると想像できます。 不十分にたくらみがあるユーザエージェントは盲目的にMessage-文脈に基づく郵送されたプログラムを実行できました。 それをしないでください!
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.
人は、実際の身体の部分のプロフィールに合わないMessage-文脈を持っているメッセージで受信機を爆撃することによって、サービス不能攻撃を思い描くことができます。 これは受信機がMessage-文脈がヒント専用であると考える理由です。
8. IANA Considerations
8. IANA問題
Section 8.3 is a registration for a new top-level RFC 2822 [3] message header, "Message-Context".
セクション8.3は新しいトップレベルRFC2822[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 Considerations部にテンプレートを置いてください。 あなたはあなたのドキュメントのどんな相互運用性と安全保障問題についても説明しなければなりません。
8.1. Message Content Type Registrations
8.1. メッセージcontent type登録証明書
Internet Message Content Types ==============================
インターネットメッセージcontent type==============================
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.
値の記述参照----- ----------- --------- This RFCが予備選挙を満足させる音声メールIndicates aメッセージはボイスメールメッセージです。 プライマリ内容はオーディオデータです。 通常、文脈は声の通話から記録されたメッセージです。
Burger, et al. Standards Track [Page 9] RFC 3458 Message Context for Internet Mail January 2003
バーガー、他 規格はメール2003年1月にインターネットのためのRFC3458メッセージの文脈を追跡します[9ページ]。
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.
プライマリThis RFC内容がファックスであるメッセージがメッセージを郵送するというファックス通信Indicates。 プライマリ内容はイメージデータです。 通常、文脈はファクシミリ通話から記録されたメッセージです。
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.
This RFCが予備選挙を満足させるポケットベルのメッセージIndicates aメッセージは1ページです。 プライマリ内容はテキストデータです。 文脈は通常、限られた長さの急報です。
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.
This RFCが予備選挙を満足させるマルチメディアメッセージIndicates aメッセージはマルチメディアメッセージです。 プライマリ内容はマルチメディア、たぶんMHTMLです。 文脈は、しばしばスパムかニュースレターです。
text-message Indicates a classic, text-based, This RFC
Internet message.
テキストメッセージのIndicatesのa古典的で、テキストベースのThis RFCインターネットメッセージ。
None Indicates an unknown message context. This RFC
Indicatesのいずれ、も未知のメッセージの文脈でない。 このRFC
8.2. Registration Template
8.2. 登録テンプレート
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
メッセージのクラスの概要: | ショートを含めてください、(もう、4つの系列) 記述か概要| 例: | 「パームトップデバイスには320×160画素のディスプレイが私たちが持つことができるようにあります」… | 同じくらい「カラーファックスは黒くして、それを空白にするのと同じくらい異なります」… 詳細のために連絡する人とEメールアドレス: | 名前とメール
Burger, et al. Standards Track [Page 10] RFC 3458 Message Context for Internet Mail January 2003
バーガー、他 規格はメール2003年1月にインターネットのためのRFC3458メッセージの文脈を追跡します[10ページ]。
8.3. Message-Context Registration
8.3. メッセージの文脈登録
To: iana@iana.org Subject: Registration of New RFC 2822 Header
To: iana@iana.org Subject: 新しいRFC2822ヘッダーの登録
RFC 2822 Header Name: Message-Context
RFC2822ヘッダー名: メッセージの文脈
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.
このパラメタのための許容量: Primary Context Class登録証明書のための新しい登録を作成してください。 初期の値のためのこのドキュメントのセクション8.1を見てください。
RFC 2822 Section 3.6 Repeat Value: Field Min Number Max Number Notes Message-Context 0 1
RFC2822部3.6は値を繰り返します: Numberマックスが付番する分野分はメッセージの文脈0 1に注意します。
Person & email address to contact for further information: Eric Burger e.burger@ieee.org
詳細のために連絡する人とEメールアドレス: エリックBurger e.burger@ieee.org
Burger, et al. Standards Track [Page 11] RFC 3458 Message Context for Internet Mail January 2003
バーガー、他 規格はメール2003年1月にインターネットのためのRFC3458メッセージの文脈を追跡します[11ページ]。
9. APPENDIX: Some messaging scenarios
9. 付録: いくつかのメッセージングシナリオ
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.
これらのシナリオは、包括的でなくてまた固定されていません。 例えば、通常テキストベースであることのメールは、彼らが音声メールを伝えることができないことを意味しません。 このまさしくその無常は、何らかの明白なメッセージの文脈ヒントを提供する願わしさにアンダーラインを引くのに役立ちます。
9.1. Internet e-mail
9.1. インターネット電子メール
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.
通常、1つの用途が不急のメッセージのためにメールされます。(受取人は、彼女に都合のよい時にメッセージを検索して、処理するでしょう)。
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つが2回のパーティー(1〜1)、少ない数の知られているパーティー(わずかへの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つは受取人がそれでメッセージのすべてか一部を別のパーティーに送ることができる方法です、追加コメントのあるなしにかかわらず。 メールが前のいくつかのメッセージからの内容の切れ端を含むのは、全く一般的です。 メールに答えるとき、同様の特徴は適用されます。
9.2. Pager service
9.2. ポケットベルサービス
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.
1つは通知と警戒を伝えるポケットベルのメッセージを使用します。 これらの通知はだいたい、限られたサイズに関する文字情報です。 典型的な限界は160のキャラクタです。 人々は比較的緊急のメッセージにページを使用します。(送付者は、受信機に短い期間まで見て、ことによると反応してメッセージが欲しいです)。 ポケットベルのメッセージは彼らの注意を必要としながら何かにユーザの注意を喚起する方法としてしばしば使用されます。 例えば、缶がそこで加入者に通知するのに1ページ使用するシステムは彼女の注意を必要とするボイスメールメッセージです。
Burger, et al. Standards Track [Page 12] RFC 3458 Message Context for Internet Mail January 2003
バーガー、他 規格はメール2003年1月にインターネットのためのRFC3458メッセージの文脈を追跡します[12ページ]。
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回のパーティー(一対一)の間には、ポケットベルのメッセージの最も一般の使用があります。
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は使用のために移動電話で発展して、1メッセージあたり1つの関連トランスミッション料金を持っている施設です。 ここの焦点が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つの使用があります、通話のように。
9.3. Facsimile
9.3. ファクシミリ
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)の間で放送されます。
Burger, et al. Standards Track [Page 13] RFC 3458 Message Context for Internet Mail January 2003
バーガー、他 規格はメール2003年1月にインターネットのためのRFC3458メッセージの文脈を追跡します[13ページ]。
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.
ほとんどのファクシミリ交換が、より長い交換の一部としてというよりむしろ孤立中です。 ファクシミリデータはコンピュータでさらなる処理に通常適していません。
9.4. Voice mail
9.4. ボイスメール
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.
一般に、ボイスメールデータはコンピュータでさらなる処理に適していません。
9.5. Multimedia message
9.5. マルチメディアメッセージ
We define a multimedia message as a message containing more than one basic media type (text, image, audio, video, model, application).
私たちは1つ以上の基本的なメディアタイプを含むメッセージとマルチメディアメッセージを定義します(テキスト、イメージ、オーディオ、ビデオがモデル化されます、アプリケーション)。
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.
特性は送付者の意図をもっていくらか変わるでしょう。 これは順番にユーザエージェントに影響するかもしれませんか、またはアプリケーションが以前はよくメッセージを伝えていました。
Burger, et al. Standards Track [Page 14] RFC 3458 Message Context for Internet Mail January 2003
バーガー、他 規格はメール2003年1月にインターネットのためのRFC3458メッセージの文脈を追跡します[14ページ]。
10. References
10. 参照
10.1 Normative References
10.1 標準の参照
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[3] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[4] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[4] クロッカーとD.とP.Overell、Eds、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
10.2 Informative References
10.2 有益な参照
[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.ムーア、「中でプレゼンテーション情報を伝えて、インターネットは通信します」。 「満足している気質ヘッダーフィールド」、RFC2183、1997年8月。
[7] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME Sub-type
Registration", RFC 2423, September 1998.
[7] ボードルイとG.とG.パーソンズ、「VPIM音声メールMIMEサブタイプ登録」、RFC2423、1998年9月。
[8] Burger, E., "Critical Content of Internet Mail", RFC 3459,
January 2003.
[8] バーガー、E.、「インターネットメールの批判的な内容」、RFC3459、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.シェル、「HTMLなどのAggregate Documents(MHTML)のMIME Encapsulation」RFC2557(1999年3月)。
[10] Levinson, E., "The MIME Multipart/Related Content-type", RFC
2387, August 1998.
[10] レヴィンソン、1998年8月、E.、「MIMEの複合の、または、関連の文書内容」RFC2387。
11. Acknowledgments
11. 承認
Many of the ideas here arose originally from a discussion with Jutta Degener.
ここの考えの多くが元々、ユッタ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.
最後のラウンドでは、私たちはむしろ利益がケーレブClausenとデーヴ・アロンソンからアドバイスするいくつかを得ました。
Burger, et al. Standards Track [Page 15] RFC 3458 Message Context for Internet Mail January 2003
バーガー、他 規格はメール2003年1月にインターネットのためのRFC3458メッセージの文脈を追跡します[15ページ]。
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を進みます、スチュアート・マクレーが、SMSと向かいあってポケットベルサービスの本質を蒸留するのを助けましたが。
We offer an extra special thanks to Greg Vaudreuil for pulling RFC 2557 out of his hat.
私たちは彼の帽子にRFC2557から手を引くためのグレッグ・ボードルイおかげで特別なエキストラを提供します。
12. Authors' Addresses
12. 作者のアドレス
Eric Burger SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA
エリックバーガーSnowShoreはInc.285ビルリカ通りをネットワークでつなぎます。 チェルムズフォード、MA01824-4120米国
Phone: +1 978 367 8403 EMail: e.burger@ieee.org
以下に電話をしてください。 +1 8403年の978 367メール: e.burger@ieee.org
Emily Candell Comverse Network Systems 200 Quannapowitt Pkwy. Wakefield, MA 01880 USA
エミリーCandell Comverseはシステム200Quannapowitt Pkwyをネットワークでつなぎます。 ウェークフィールド、MA01880米国
Phone: +1 781 213 2324 EMail: emily.candell@comverse.com
以下に電話をしてください。 +1 2324年の781 213メール: emily.candell@comverse.com
Graham Klyne Nine by Nine United Kingdom
グラハムKlyne9時9分前イギリス
EMail: GK-IETF@ninebynine.org
メール: GK-IETF@ninebynine.org
Charles Eliot Microsoft Corporation One Microsoft Way Redmond WA 98052 USA
チャールズエリオットマイクロソフト社1マイクロソフトWayレッドモンドワシントン98052米国
Phone: +1 425 706 9760 EMail: charle@Microsoft.com
以下に電話をしてください。 +1 9760年の425 706メール: charle@Microsoft.com
Burger, et al. Standards Track [Page 16] RFC 3458 Message Context for Internet Mail January 2003
バーガー、他 規格はメール2003年1月にインターネットのためのRFC3458メッセージの文脈を追跡します[16ページ]。
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Burger, et al. Standards Track [Page 17]
バーガー、他 標準化過程[17ページ]
一覧
スポンサーリンク
