RFC4356 日本語訳
4356 Mapping Between the Multimedia Messaging Service (MMS) andInternet Mail. R. Gellens. January 2006. (Format: TXT=69427 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Gellens Request for Comments: 4356 Qualcomm Category: Standards Track January 2006
Gellensがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4356年のクアルコムカテゴリ: 標準化過程2006年1月
Mapping Between the Multimedia Messaging Service (MMS)
and Internet Mail
マルチメディアの間で(MMS)とインターネットが郵送するメッセージサービスを写像します。
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols that are similar to, but differ in key ways from, those used in Internet mail.
携帯電話産業はマルチメディア・メッセージング・サービス(MMS)として知られているサービスを定義しました。 このサービスは同様ですが、それがキー溝において異なる形式とプロトコルを使用します、インターネット・メールで使用されるもの。
One important difference between MMS and Internet Mail is that MMS uses headers that start with "X-Mms-" to carry a variety of user agent- and server-related information elements.
MMSとインターネットメールの1つの重要な違いはMMSが「X-Mms」からさまざまなユーザエージェントとサーバ関連の情報要素を運び始めるヘッダーを使用するということです。
This document specifies how to exchange messages between these two services, including mapping information elements as used in MMS X-Mms-* headers as well as delivery and disposition reports, to and from that used in SMTP and Internet message headers.
このドキュメントはこれらの2つのサービスの間でメッセージを交換する方法を指定します、ヘッダーとSMTPで使用されるそれと配送と気質レポートと同様にインターネットメッセージヘッダーからMMS X-Mms-*ヘッダーで使用されるように情報要素を写像するのを含んでいて。
Gellens Standards Track [Page 1] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Scope ......................................................2
1.2. Conventions Used in This Document ..........................3
1.3. Definitions ................................................3
1.4. Abbreviations ..............................................4
1.5. Assumptions ................................................4
2. Mapping Between MMS and Internet Mail ...........................4
2.1. Mapping Specification ......................................5
2.1.1. MMS to Internet Mail ................................5
2.1.2. Internet Mail to MMS ................................5
2.1.3. MMS Information Element Mappings ....................6
2.1.4. Report Generation and Conversion ...................20
2.1.5. Message Delivery ...................................27
3. Security Considerations ........................................27
4. IANA Considerations ............................................27
5. Acknowledgements ...............................................27
6. Normative References ...........................................27
7. Informative References .........................................29
1. 序論…2 1.1. 範囲…2 1.2. このドキュメントで中古のコンベンション…3 1.3. 定義…3 1.4. 略語…4 1.5. 仮定…4 2. MMSとインターネットメールの間で写像します。4 2.1. 仕様を写像します…5 2.1.1. インターネットメールへのMMS…5 2.1.2. MMSへのインターネットメール…5 2.1.3. MMS情報要素マッピング…6 2.1.4. レポート作成と変換…20 2.1.5. メッセージ配送…27 3. セキュリティ問題…27 4. IANA問題…27 5. 承認…27 6. 標準の参照…27 7. 有益な参照…29
1. Introduction
1. 序論
1.1. Scope
1.1. 範囲
This document describes how to exchange messages between Multimedia Messaging Service (MMS) systems (as defined by [3GPP][3GPP2][OMA]) and Internet mail systems (that is, [SMTP] and [Msg-Fmt]). This includes the translation of message formats, message header elements, message delivery reports [DSN-Msg], and message disposition reports [MDN].
このドキュメントはマルチメディア・メッセージング・サービス(MMS)システム([3GPP][3GPP2][OMA]によって定義されるように)とインターネット・メールシステム(すなわち、[SMTP]と[エムエスジー-Fmt])の間でメッセージを交換する方法を説明します。 これはメッセージ・フォーマット、メッセージヘッダー要素、メッセージ配送レポート[DSN-エムエスジー]、およびメッセージ気質レポート[MDN]に関する翻訳を含んでいます。
The MMS architecture [Stage_2] and specifications [Stage_3] refer to interfaces as reference points named MMx. For example, MM1 is the client-server interface, MM4 is the server-server interface, and MM3 is an interface to "external" or non-MMS systems. The specification in this document can be used for message exchange between any system that uses Internet message formats and protocols and an MMS system; from the perspective of the MMS system, reference point MM3 is used.
基準点がMMxを命名したので、アーキテクチャ[ステージ_2]と仕様[ステージ_3]が言及するMMSは連結します。 例えば、MM1はクライアント/サーバインタフェースです、そして、MM4はサーバサーバインタフェースです、そして、MM3は「外部」の、または、非MMSのシステムへのインタフェースです。インターネットメッセージ・フォーマットとプロトコルを使用するどんなシステムとMMSシステムの間の交換処理に本書では仕様は使用できます。 MMSシステムの見解から、参照ポイントMM3は使用されています。
This document includes support for voice messages specified by the Voice Profile for Internet Mail [VPIM]. The VPIM specification allows voice messages to be exchanged between voice mail systems using the Internet mail format [Msg-Fmt] and transported via [SMTP]. Thus, the MMS MM3 interface supports the ability to exchange voice messages between an MMS system and a voice mail system. Note that such use is distinct from voice media being part of a user-composed multimedia message.
このドキュメントはVoice Profileによってインターネットメール[VPIM]に指定された音声メールのサポートを含んでいます。 VPIM仕様はボイスメールシステムの間でインターネットメール書式[エムエスジー-Fmt]を使用することで交換された、[SMTP]を通して輸送されるべき音声メールを許容します。 したがって、MMS MM3インタフェースはMMSシステムとボイスメールシステムの間で音声メールを交換する能力をサポートします。 そのような使用がユーザが落ち着いたマルチメディアメッセージの一部である声のメディアと異なっていることに注意してください。
Gellens Standards Track [Page 2] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[2ページ]。
Note that MM3 can also be used for interworking with "external" (non-MMS) systems other than Internet mail, such as Short Messaging Service (SMS) and access to external mail stores (such as a voice mail system). This specification does not address these other uses or sub-interfaces of MM3; it is only concerned with Internet mail interworking and specifically exchange of messages.
また、インターネット・メール以外の「外部(非MMSの)」のシステムによる織り込むのにMM3を使用できるというショート・メッセージ・サービス(SMS)や外部のメール店(ボイスメールシステムなどの)へのアクセスなどのメモ。 この仕様は、これらがMM3の他の用途かサブインタフェースであると扱いません。 それはメッセージのインターネット・メールの織り込むのと明確に交換に関係があるだけです。
All MM3 Stage 2 [Stage_2] functions are supported except for reply charging and sender address hiding.
回答充電と送付者アドレス隠れることを除いて、すべてのMM3 Stage2[ステージ_2]機能がサポートされます。
1.2. Conventions Used in This Document
1.2. 本書では使用されるコンベンション
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in "Key Words for Use in RFCs to Indicate Requirement Levels" [KEYWORDS].
“MUST"、「必須NOT」がキーワードが、「必要でした」、“SHOULD"、「」 「5月」は「RFCsにおける使用が要件レベルを示すキーワード」[キーワード]で説明されるように本書では解釈されることになっているべきです。
1.3. Definitions
1.3. 定義
--------------------|----------------------------------------------
Body |The portion of an [SMTP] message's Content
|following the Header (that is, following the
|first blank line). The Body may contain
|structured parts and sub-parts, each of which
|may have its own Header and Body. The Body
|contains information intended for the message
|recipient (human or software).
--------------------|----------------------------------------------
Content |The portion of an SMTP message that is
|delivered. The Content consists of a Header
|and a Body.
--------------------|----------------------------------------------
Disposition Report |Feedback information to an originator User
|Agent by a recipient User Agent about
Message Disposition |handling of an original message. This may
Notification |include notification that the message was or
|was not read, was deleted unread, etc.
--------------------|----------------------------------------------
Envelope |The portion of an SMTP message not included in
|the Content, that is, not in the Header or in
|the Body. While some of it may be copied into
|the Content on delivery, envelope information
|exists only while the message is in transit,
|and contains information used by SMTP agents
|(Mail Transfer Agents (MTAs)).
--------------------|----------------------------------------------
Gateway |See [SMTP], Section 2.3.8.
--------------------|----------------------------------------------
--------------------|---------------------------------------------- ボディー|[SMTP]メッセージのContentの一部|Headerに続く、(続いて、それがそうである、|、最初に、空白行) Bodyは含むかもしれません。|それぞれどれの構造化された部品とサブ部品であるか。|それ自身のHeaderとBodyを持っているかもしれません。 ボディー|メッセージのために意図する情報を含んでいます。|受取人(人間かソフトウェア)。 --------------------|---------------------------------------------- 内容|SMTPメッセージの部分|提供にされる。 ContentはHeaderから成ります。|そして、ボディー。 --------------------|---------------------------------------------- 気質レポート|創始者Userへのフィードバック情報|Message Dispositionに関する受取人Userエージェントによるエージェント|オリジナルのメッセージの取り扱い。 これがそうするかもしれない、通知|またはメッセージがそうであったという通知を含めてください。|読まれないで、削除された、読まれていなさ、など --------------------|---------------------------------------------- 封筒|中に含まれていなかったSMTPメッセージの部分|すなわち、HeaderかコネでないのにおけるContent|ボディー。 それのいくつかにコピーされるかもしれませんが|配送、封筒情報のContent|メッセージはトランジット単に中ですが、存在しています。|SMTPエージェントによって使用された情報を含んでいます。|(メール配達エージェント(MTAs)。) --------------------|---------------------------------------------- ゲートウェイ|[SMTP]、セクション2.3.8を見てください。 --------------------|----------------------------------------------
Gellens Standards Track [Page 3] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[3ページ]。
--------------------|----------------------------------------------
Header |The first part of an SMTP message's Content.
|The Header is separated from the Body by a
|blank line. The Header consists of Fields
|(such as "To:"), also known as Header Fields
|or Headers. The message Header contains
|information used by User Agents.
--------------------|----------------------------------------------
Relay/Server |An MMS server. See [Stage_2]. For purposes
|of this document, an MMS Relay/Server acts as
|a gateway when it receives or sends messages
|via Internet mail.
--------------------|----------------------------------------------
User Agent |An MMS or email user agent.
--------------------|----------------------------------------------
--------------------|---------------------------------------------- ヘッダー|SMTPメッセージのContentの最初の部分。 |HeaderはaによってBodyと切り離されます。|空白行。 Headerはフィールズから成ります。|(「To:」などの), また、Headerフィールズとして、知られています。|または、ヘッダー。 Headerが含むメッセージ|Userエージェントによって使用された情報。 --------------------|---------------------------------------------- リレー/サーバ|MMSサーバ[ステージ_2]を見てください。 目的のために|このドキュメント、サーバが機能するMMS Relay/について|それであるときに、ゲートウェイは、メッセージを受け取るか、または送ります。|インターネット・メールで。 --------------------|---------------------------------------------- ユーザエージェント|MMSかメールユーザエージェント。 --------------------|----------------------------------------------
1.4. Abbreviations
1.4. 略語
--------|----------------------------------------------------------
MSA |Message Submission Agent. A server that accepts messages
|from User Agents and processes them, either delivering
|them locally or relaying to an MTA. See [Submission].
--------|----------------------------------------------------------
MTA |Mail Transfer Agent. A server that implements [SMTP].
--------|----------------------------------------------------------
--------|---------------------------------------------------------- MSA|メッセージ服従エージェント。 メッセージを受け入れるサーバ|Userエージェントであって彼らを処理して、配送しています。|それら、局所的である、または、MTAへのリレー。 [服従]を見てください。 --------|---------------------------------------------------------- MTA|証券代行に郵送してください。 [SMTP]を実装するサーバ。 --------|----------------------------------------------------------
1.5. Assumptions
1.5. 仮定
It is assumed that the reader is already familiar with the contents of the 3GPP2 MMS Specification Overview [Overview], MMS Stage 1 (requirements) [Stage_1] and Stage 2 (architecture and abstract messages) [Stage_2], and 3GPP/3GPP2 Stage 3 (protocols) [Stage_3] documents. It is also assumed that the reader is familiar with Internet mail, especially RFC 2821 [SMTP] and RFC 2822 [Msg-Fmt].
読者が既に3GPP2 MMS Specification Overview[概要]とMMS Stage1(要件)[ステージ_1]とStage2(アーキテクチャと抽象的なメッセージ)[ステージ_2]、および3GPP/3GPP2 Stage3(プロトコル)[ステージ_3]ドキュメントのコンテンツに詳しいと思われます。 また、読者がインターネット・メール、特にRFC2821[SMTP]、およびRFC2822[エムエスジー-Fmt]に詳しいと思われます。
2. Mapping Between MMS and Internet Mail
2. MMSとインターネットメールの間のマッピング
This section defines the interworking between MMS Relay/Servers and External Servers using native [SMTP]. That is, information elements are exchanged using standard Internet message [Msg-Fmt] header fields, such as those in [Hdrs], and standard [SMTP] elements.
このセクションは、ネイティブ[SMTP]を使用することでMMS Relay/サーバとExternal Serversの間の織り込むことを定義します。 標準のインターネットメッセージ[エムエスジー-Fmt]ヘッダーフィールドを使用することですなわち、情報要素を交換します、[Hdrs]のそれらや、標準の[SMTP]要素などのように。
SMTP and Internet mail extensions are used for features such as delivery reports, message expiration, and discovery of server support for optional features.
SMTPとインターネット・メール拡張子はオプション機能のサーバサポートの配送レポートや、メッセージ満了や、発見などの特徴に使用されます。
Gellens Standards Track [Page 4] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[4ページ]。
2.1. Mapping Specification
2.1. 仕様を写像します。
2.1.1. MMS to Internet Mail
2.1.1. インターネットメールへのMMS
When sending a message to an Internet mail system, the MMS Relay/Server MUST convert the MM if required, and MUST comply with the requirements of [SMTP].
インターネット・メールシステムにメッセージを送るとき、MMS Relay/サーバは、必要なら、MMを変換しなければならなくて、[SMTP]の要件に従わなければなりません。
The MMS Relay/Server SHOULD use the information elements associated with the MM to define the control information (Internet message header fields and SMTP envelope values) needed for the transfer protocol.
MMS Relay/サーバSHOULDは、転送プロトコルに必要である制御情報(インターネットメッセージヘッダーフィールドとSMTP封筒値)を定義するのにMMに関連している情報要素を使用します。
Section 2.1.3 lists the mappings between X-Mms-* headers and Internet message header fields and SMTP values.
セクション2.1 .3 X-Mms-*ヘッダーと、インターネットメッセージヘッダーフィールドとSMTP値の間のマッピングをリストアップします。
Delivery and read report MMs SHOULD be converted to standard Internet message report format (multipart/report). In addition to converting Internet Message reports, the MMS Relay/Server MUST generate delivery and read report MMs for received messages as appropriate. See Section 2.1.4 for more information.
配送と読書は、MMs SHOULDが標準のインターネットメッセージレポート形式(複合/レポート)に変換されると報告します。 インターネットMessageレポートを変換することに加えて、MMS Relay/サーバは、受信されたメッセージのために適宜配送を生成して、レポートMMsを読まなければなりません。 詳しい情報に関してセクション2.1.4を見てください。
2.1.2. Internet Mail to MMS
2.1.2. MMSへのインターネットメール
When receiving a message from an Internet mail system, the MMS Relay/Server converts incoming messages to the MM format used within the receiving system.
インターネット・メールシステムからメッセージを受け取るとき、MMS Relay/サーバは受電方式の中で使用されたMM形式に入力メッセージを変換します。
The MMS Relay/Server converts control information received from the Internet mail server into appropriate information elements of an MM.
MMS Relay/サーバはインターネット・メールサーバからMMの適切な情報要素に受け取られた制御情報を変換します。
Section 2.1.3 lists the mappings between X-Mms-* headers and Internet message header fields and SMTP values.
セクション2.1 .3 X-Mms-*ヘッダーと、インターネットメッセージヘッダーフィールドとSMTP値の間のマッピングをリストアップします。
Standard Internet message report format (multipart/report) messages MAY be converted to delivery or read report MMs, as appropriate. In addition to converting report MMs, implementations conforming to this document MUST generate standard Internet message delivery and disposition reports for received Internet messages as appropriate. See Section 2.1.4 for more information.
標準のインターネットメッセージレポート形式(複合/レポート)メッセージは、配送に変換されるか、または適宜レポートMMsを読み込むかもしれません。 レポートMMsを変換することに加えて、このドキュメントに従う実装は、標準のインターネットが受信されたインターネットメッセージのためのメッセージ配送と気質レポートであると適宜生成しなければなりません。 詳しい情報に関してセクション2.1.4を見てください。
Gellens Standards Track [Page 5] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[5ページ]。
2.1.3. MMS Information Element Mappings
2.1.3. MMS情報要素マッピング
The mappings between MMS elements and SMTP/Internet message elements ([SMTP] parameters, [Msg-Fmt] headers, and [DSN-Msg] fields) are summarized in table 1 below, and detailed in subsequent sections. The "MMS Headers" are from [OMA-MMS]. Note that only information elements that need to be mapped are listed. [Msg-Fmt] headers not listed here SHOULD be passed unaltered.
MMS要素とSMTP/インターネットメッセージ要素([SMTP]パラメタ、[エムエスジー-Fmt]ヘッダー、および[DSN-エムエスジー]分野)の間のマッピングは、以下のテーブル1にまとめられて、その後のセクションで詳しく述べられます。 「MMSヘッダー」は[OMA-MMS]から来ています。 写像される必要がある情報要素だけが記載されていることに注意してください。 [エムエスジー-Fmt]ヘッダーはここにSHOULDを記載しませんでした。非変更されて、渡されてください。
2.1.3.1. Table 1: Information Element Mappings
2.1.3.1. テーブル1: 情報要素マッピング
=================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|==============
3GPP MMS Version |N/A |N/A |X-Mms-3GPP-MMS
| | | -Version:
_________________|_________________|________________|______________
Message Type |N/A |N/A |X-Mms-Message-
(of PDU) | | | Type:
_________________|_________________|________________|______________
Transaction ID |N/A |N/A |X-Mms-Transact
| | | ion-Id:
_________________|_________________|________________|______________
Message ID |N/A |Message-ID: |Message-ID:
_________________|_________________|________________|______________
Recipient |RCPT TO |To:, Cc:, or |To:, Cc:, Bcc:
address(es) |address(es) |omitted (Bcc) |
_________________|_________________|________________|______________
Sender's address |MAIL FROM |From: |From:
|address if | |
|user-originated; | |
|MUST set MAIL | |
|FROM to null | |
|("<>") for all | |
|automatically- | |
|generated MMs | |
_________________|_________________|________________|______________
Content type |N/A |Content-Type: |Content-type:
| | |
| |For voice mes- |
| |sages compliant |
| |to [VPIM], see |
| |Note 2 |
_________________|_________________|________________|______________
=================|=================|================|============== 情報Elem|[SMTP]要素|[エムエスジー-Fmt] ヘッダー|MMSヘッダー=================|=================|================|============== 3GPP MMSバージョン|なし|なし|X-Mms-3GPP-MMS| | | -バージョン: _________________|_________________|________________|______________ メッセージタイプ|なし|なし|X-Mms-メッセージ、-、(PDUの)| | | 以下をタイプしてください。 _________________|_________________|________________|______________ トランザクションID|なし|なし|X-Mms商取引します。| | | イオンイド: _________________|_________________|________________|______________ メッセージID|なし|Message ID: |Message ID: _________________|_________________|________________|______________ 受取人|RCPT|またはTo:、Cc:。|To:、Cc:、Bcc: アドレス(es)|アドレス(es)|省略されます(Bcc)。| _________________|_________________|________________|______________ 送付者のアドレス|メール|From: |From: |アドレス| | |ユーザによって溯源される。 | | |メールを設定しなければなりません。| | |ヌルへのFROM| | |(「<>」) すべてのために| | |自動的に| | |MMsであると生成されます。| | _________________|_________________|________________|______________ content type|なし|コンテントタイプ: |文書内容: | | | | |声mesのために| | |賢人対応します。| | |[VPIM]において、見てください。| | |注意2| _________________|_________________|________________|______________
Gellens Standards Track [Page 6] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[6ページ]。
=================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|==============
Message class |Class=auto: |MAY set 'Prece |X-Mms-Message-
|MUST set MAIL | dence: bulk' | Class:
|FROM to null |on class=auto |
|("<>"). | |
_________________|_________________|________________|______________
Date and time |N/A |Date: |Date:
of submission | | |
_________________|_________________|________________|______________
Time of expiry |DELIVER-BY |N/A |X-Mms-Expiry:
|[Deliver-By] | |
_________________|_________________|________________|______________
Earliest deliv- |(only for submis-|N/A |X-Mms-Delivery
ery time |sion; not relay) | | -Time:
_________________|_________________|________________|______________
Delivery report |DSN [DSN-SMTP] |N/A |X-Mms-Delivery
request |SHOULD also | | -Report:
|specify recip- | |
|ient address as | |
|ORCPT; SHOULD | |
|also specify | |
|ENVID | |
_________________|_________________|________________|______________
Importance (a/k/a|N/A |Importance: |X-Mms-
"priority") | | | Priority:
| | |
| | |
_________________|_________________|________________|______________
Sender visib- |(not currently |(not currently |X-Mms-Sender-
ility |supported) |supported) | Visibility:
_________________|_________________|________________|______________
Read reply |N/A |Disposition- |X-Mms-Read-
request | | Notification | Reply:
| | -To: [MDN] |
_________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging:
_________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging-
deadline | | | Deadline:
_________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging-
limitation | | | Size:
_________________|_________________|________________|______________
=================|=================|================|============== 情報Elem|[SMTP]要素|[エムエスジー-Fmt] ヘッダー|MMSヘッダー=================|=================|================|============== メッセージのクラス|クラスは自動車と等しいです: |5月のセット'Prece'|X-Mms-メッセージ、-|メールを設定しなければなりません。| dence: '大量'| クラス: |ヌルへのFROM|クラス=自動車に関して| |(「<>」。) | | _________________|_________________|________________|______________ 日時|なし|日付: |日付: 服従について| | | _________________|_________________|________________|______________ 満期の時間|近く、配送します。|なし|X-Mms-満期: |[近く、配送します]| | _________________|_________________|________________|______________ 最も前のdeliv|(ery時間| | Nをsubmisしている/A| X-Mms-配送sion; リレーでないことのためだけの) | | -時間: _________________|_________________|________________|______________ 配送レポート|DSN[DSN-SMTP]|なし|X-Mms-配送要求|SHOULDも| | -以下を報告してください。 |recipを指定してください。| | |アドレスをientします。| | |ORCPT。 should| | |また、指定してください。| | |ENVID| | _________________|_________________|________________|______________ 重要性、(a/k/a| | 重要性: | なし、X-Mms、-、「優先権」)| | | 優先権: | | | | | | _________________|_________________|________________|______________ 送付者visib|(現在でない|、(| 現在のX-Mms-送付者でない、-、|、サポートする、)、|、サポートする、) | 目に見えること: _________________|_________________|________________|______________ 回答を読んでください。|なし|気質|X-Mmsによって読まれた要求| | 通知| 回答: | | -To: [MDN]| _________________|_________________|________________|______________ 回答充電|(現在でない、| (| 現在のX-Mms-回答許可でない|、サポートする、)、|、サポートする、) | 充電します: _________________|_________________|________________|______________ 回答充電|(現在でない、| (| 現在のX-Mms-回答許可でない|、サポートする、)、|、サポートする、) | 充電の締め切り| | | 締め切り: _________________|_________________|________________|______________ 回答充電|(現在でない、| (| 現在のX-Mms-回答許可でない|、サポートする、)、|、サポートする、) | 充電制限| | | サイズ: _________________|_________________|________________|______________
Gellens Standards Track [Page 7] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[7ページ]。
=================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|==============
Reply charging |(not currently |(not currently |X-Mms-Reply-
usage request |supported) |supported) | Charging-
| | | Id:
_________________|_________________|________________|______________
Reply charging |(not currently |(not currently |X-Mms-Reply-
usage reference |supported) |supported) | Charging:
_________________|_________________|________________|______________
Subject |N/A |Subject: |Subject:
_________________|_________________|________________|______________
Previously-sent |N/A |Resent-From: |X-Mms-Previous
by | | | ly-Sent-By:
_________________|_________________|________________|______________
Previously-sent |N/A |Resent-Date: |X-Mms-
date | | | Previously-
| | | Sent-Date-
| | | and-Time:
_________________|_________________|________________|______________
Hop/host trace |N/A |Received: |(Not sup-
| | |ported)
_________________|_________________|________________|______________
Sensitivity |N/A |Sensitivity: see|N/A
| |Note 1 |
_________________|_________________|________________|______________
Content |N/A |<message body> |<message body>
=================|=================|================|==============
=================|=================|================|============== 情報Elem|[SMTP]要素|[エムエスジー-Fmt] ヘッダー|MMSヘッダー=================|=================|================|============== 回答充電|(現在でない|、(| 現在のどんなX-Mms-回答用法もサポートされた状態で|要求しません)|、サポートする、) | 充電| | | イド: _________________|_________________|________________|______________ 回答充電|(現在でない|、(|| 現在のどんなX-Mms-回答用法もサポートされた状態で参照をつけません)|、サポートする、) | 充電します: _________________|_________________|________________|______________ 対象|なし|Subject: |Subject: _________________|_________________|________________|______________ 以前に、発信します。|なし|From:に憤慨します。 |X-Mms前である| | | 発信するly: _________________|_________________|________________|______________ 以前に、発信します。|なし|日付:に憤慨します。 |X-Mms日付| | | 以前に| | | 送られた期日、-| | | -調節してください、: _________________|_________________|________________|______________ ホップ/ホスト跡|なし|受け取られている: |(一口でない|、|、|、移植、) _________________|_________________|________________|______________ 感度|なし|感度: 見てください。|なし| |注意1| _________________|_________________|________________|______________ 内容|なし|<メッセージボディー>。|<メッセージボディー>。=================|=================|================|==============
Note 1: The [VPIM] 'Sensitivity' header element indicates the privacy requested by the message originator (values are "personal" or "private"); per [VPIM], a message recipient MUST NOT forward a message with a 'Sensitivity' header. Since sensitivity is not an MMS feature, any messages that contain a 'Sensitivity:' header SHOULD NOT be sent to an MMS system.
注意1: [VPIM]'感度'ヘッダー要素はメッセージ創始者によって要求されたプライバシーを示します(値は、「個人的である」か「個人的です」)。 [VPIM]に従って、メッセージ受取人は'感度'ヘッダーをもってメッセージを転送してはいけません。 以来、感度はMMSの特徴、'感度: 'ヘッダーSHOULD NOTを含むあらゆるメッセージではありません。MMSシステムに送ります。
Note 2: [VPIM] specifies how conforming messages are identified.
注意2: [VPIM]は従うメッセージがどう特定されるかを指定します。
2.1.3.2. Conversion of Messages from MMS to Internet Format
2.1.3.2. メッセージのMMSからインターネット形式までの変換
3GPP MMS Version
3GPP MMSバージョン
The 'X-Mms-3GPP-MMS-Version:' header, if present, SHOULD be removed.
'X-Mms-3GPP-MMS-バージョン: プレゼント、SHOULDであることでの'ヘッダー、取り除いてください。
Message Type (of PDU)
メッセージタイプ(PDUの)
The 'X-Mms-Message-Type:' header, if present, SHOULD be removed.
'X-Mmsメッセージタイプ: プレゼント、SHOULDであることでの'ヘッダー、取り除いてください。
Gellens Standards Track [Page 8] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[8ページ]。
Transaction ID
トランザクションID
The 'X-Mms-Transaction-Id:' header, if present, SHOULD be removed.
'X-Mmsトランザクションイド: プレゼント、SHOULDであることでの'ヘッダー、取り除いてください。
Message ID
メッセージID
The 'Message-Id:' header MUST be retained. If not present, it MUST be created, with a unique value, per [Msg-Fmt].
'メッセージイド: 'ヘッダーを保有しなければなりません。 プレゼントでないなら、ユニークな値で[エムエスジー-Fmt]単位でそれを作成しなければなりません。
To facilitate the case where an MMS message traverses the Internet prior to returning to an MMS system, implementations might wish to retain the 'X-Mms-Message-Id:' header. Such systems should be aware that headers that begin with "X-" might be removed during transit through Internet MTAs.
MMSメッセージがMMSシステムに戻る前にインターネットを横断するケースを容易にするために、実装は'X-Mmsメッセージイドを保有したがっているかもしれません: 'ヘッダー。 そのようなシステムは「X」と共に始まるヘッダーがトランジットの間インターネットMTAsを通して取り除かれるかもしれないのを意識しているべきです。
Recipient(s) address
受取人アドレス
The address of each recipient MUST be transmitted in the [SMTP] envelope as a RCPT TO value. All disclosed recipients SHOULD also appear in a 'To:' or 'Cc:' header. At least one 'To:', 'Cc:', or 'Bcc:' header MUST be present. If none are present, a 'To:' header SHOULD be created using empty group syntax whose name gives an indication to a human reader, for example, 'To: undisclosed- recipients:;'.
RCPT TO値として[SMTP]封筒でそれぞれの受取人のアドレスを伝えなければなりません。 すべてがまたSHOULDが'To:'か'Cc:'ヘッダーで見える受取人を明らかにしました。 少なくとも1個の'To:'、'Cc:'、または'Bcc:'ヘッダーが出席しているに違いありません。 なにもであるなら、作成された使用空のグループが名前が人間の読者、例えば、'To:'に指示を与える構文であったなら、プレゼント、'To:'はヘッダーSHOULDですか? '明かされていない受取人:'、。
The 'To:' header SHOULD NOT appear more than once. The 'Cc:' header SHOULD NOT appear more than once.
'To:'ヘッダーSHOULD NOTは一度より多く見えます。 'Cc:'ヘッダーSHOULD NOTは一度より多く見えます。
Each recipient address MUST obey the length restrictions per [SMTP].
それぞれの受取人アドレスは[SMTP]あたりの長さの制限に従わなければなりません。
Current Internet Message format requires that only 7-bit US-ASCII characters be present in headers. Non-7-bit characters in an address domain must be encoded with [IDN]. If there are any non-7-bit characters in the local part of an address, the message MUST be rejected. Non-7-bit characters elsewhere in a header MUST be encoded according to [Hdr-Enc].
現在のインターネットMessage形式は、7ビットの米国-ASCII文字だけにヘッダーに出席しているのを必要とします。 [IDN]と共にアドレスドメインの非7に噛み付いているキャラクタをコード化しなければなりません。 何か非7に噛み付いているキャラクタがアドレスの地方の部分にあれば、メッセージを拒絶しなければなりません。 [Hdr-Enc]に従って、ヘッダーのほかの場所の非7に噛み付いているキャラクタをコード化しなければなりません。
All recipient addresses in the [SMTP] envelope must be fully- qualified in accordance with [SMTP]. In particular, messages MUST NOT be sent to an Internet mail system with an unqualified E.164 number (i.e., a number with no domain) instead of a fully-qualified domain name.
[SMTP]に従って、完全に[SMTP]封筒のすべての受取人アドレスに資格がなければなりません。 資格のないE.164番号(すなわち、ドメインのない数)が完全修飾ドメイン名の代わりにある状態で、特に、インターネット・メールシステムにメッセージを送ってはいけません。
All addresses in 'To:', 'Cc:', and 'Bcc:' headers MUST be in the form of fully-qualified domains. Unqualified E.164 numbers MUST NOT be used.
'To:'、'Cc:'、および'Bcc:'ヘッダーのすべてのアドレスが完全に適切なドメインの形にあるに違いありません。 資格のないE.164番号を使用してはいけません。
Gellens Standards Track [Page 9] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[9ページ]。
Sender address
送付者アドレス
The address of the message sender SHOULD appear in the 'From:' header.
送付者SHOULDが'From:'ヘッダーで見えるメッセージのアドレス。
The address of the message sender for all user-generated messages
('X-Mms-Message-Class: Personal') SHOULD be transmitted in the
[SMTP] envelope as the MAIL FROM value.
MAIL FROMが評価するようにすべてのためのメッセージ送付者のアドレスは、伝えられたコネが[SMTP]封筒であったならメッセージ('X-Mmsはクラスを通信させます: 個人的である')がSHOULDであるとユーザと同じくらい生成しました。
The return addresses in the [SMTP] envelope must be fully-qualified in accordance with [SMTP]. In particular, messages MUST NOT be sent to an Internet mail system with an E.164 number instead of a fully- qualified domain name. Note that qualified E.164 numbers, that is, those that contain an E.164 number as the local-part of an address that also includes a domain, are acceptable.
[SMTP]に従って、[SMTP]封筒の返送先は完全に適切でなければなりません。 E.164番号が完全に適切なドメイン名の代わりにある状態で、特に、インターネット・メールシステムにメッセージを送ってはいけません。 適切なE.164番号(すなわち、また、ドメインを含んでいるアドレスの地方の部分としてE.164番号を含むもの)が許容できることに注意してください。
The address(es) in the 'From:' header SHOULD be in the form of fully-qualified domains. Unqualified E.164 numbers SHOULD NOT be used.
'From:'ヘッダーSHOULDのアドレス(es)は完全に適切なドメインの形のそうです。 資格のないE.164はSHOULD NOTに付番します。使用されます。
Because of the risk of mail loops, it is critical that the MAIL FROM
be set to null ("<>") for all automatically-generated MMs (such as
'X-Mms-Message-Class: Auto'). The MAIL FROM value MUST be set to
null for all automatically-generated messages. This includes
reports, "out-of-office" replies, etc.
メール輪のリスクのために、メールFROMがすべてにおけるヌル(「<>」)の自動的に発生しているMMs('X-Mmsメッセージのクラス: 自動車'などの)に用意ができているのは、重要です。 すべての自動的に発生しているメッセージのためにMAIL FROM値をヌルに設定しなければなりません。 これはレポート、「オフィスの外」という回答などを含んでいます。
Current Internet message format requires that only 7-bit US-ASCII characters be present in headers. Non-7-bit characters in an address domain must be encoded with [IDN]. If there are any Non-7-bit characters in the local part of an address, the message MUST be rejected. Non-7-bit characters elsewhere in a header MUST be encoded according to [Hdr-Enc]. Note that it would be possible to define an [SMTP] extension to permit transmission of unencoded 8-bit characters, but in the absence of such an extension [Hdr-Enc] MUST be used.
現在のインターネットメッセージ・フォーマットは、7ビットの米国-ASCII文字だけにヘッダーに出席しているのを必要とします。 [IDN]と共にアドレスドメインの非7に噛み付いているキャラクタをコード化しなければなりません。 何かNon7が噛み付いているキャラクタがアドレスの地方の部分にあれば、メッセージを拒絶しなければなりません。 [Hdr-Enc]に従って、ヘッダーのほかの場所の非7に噛み付いているキャラクタをコード化しなければなりません。 それを暗号化されていない8ビットのキャラクタの遺伝を可能にするために[SMTP]拡大を定義するのにおいて可能でしょうが、そのような拡大[Hdr-Enc]がないとき使用しなければならないことに注意してください。
The sender address MUST obey the length restrictions of [SMTP].
送付者アドレスは[SMTP]の長さの制限に従わなければなりません。
Content type
content type
The 'Content-Type:' header SHOULD be preserved.
'コンテントタイプ: 'ヘッダーSHOULD、保存されてください。
Gellens Standards Track [Page 10] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[10ページ]。
Message class
メッセージのクラス
The 'X-Mms-Message-Class:' header MAY be retained in order to provide information on the source of the message. A 'Precedence: bulk' header MAY be inserted for class=auto or class=advertisement. See 'Sender Address' above. (Class=personal and class=informational do not require special handling.)
'X-Mmsメッセージのクラス: 'ヘッダーは、メッセージの源の情報を提供するために保有されるかもしれません。 '先行:' '大量'のヘッダーはクラス=自動車かクラス=広告のために挿入されるかもしれません。 '送付者Address'が上であることを見てください。 =個人的であって、クラス=情報であることで、属してください。(特別な取り扱いを必要としない、)
Time of Expiry
満期の時間
The 'X-Mms-Expiry:' header, if present, SHOULD be removed.
'X-Mms-満期: プレゼント、SHOULDであることでの'ヘッダー、取り除いてください。
The remaining time until the message is considered expired SHOULD be transmitted in the [SMTP] envelope by using the DELIVER-BY extension with a by-mode of "R", as specified in [Deliver-By].
メッセージが考えられるまで、残っている時間は「R」についてモードでaとのDELIVER-BY拡張子を使用することによって伝えられたコネが[SMTP]封筒であったならSHOULDを吐き出しました、[近く、配送します]で指定されるように。
Note that the [SMTP] DELIVER-BY extension carries time remaining until expiration; each server decrements the value by the amount of time it has possessed the message. The 'X-Mms-Expiry:' header may contain either the absolute time at which the message is considered expired or the relative time until the message is considered expired.
[SMTP]DELIVER-BY拡張子が満了まで残りながら時間を運ぶことに注意してください。 各サーバはそれがメッセージを持っていた時間までに値を減少させます。 'X-Mms-満期: 'ヘッダーはメッセージが満期であると考えられたか、またはメッセージが考えられるまで相対的な時間が期限が切れた絶対時間を含むかもしれません。
Earliest delivery time
最短期間の配達時間
The 'X-Mms-Delivery-Time:' header, if present, SHOULD be removed.
'X-Mms配送時間: プレゼント、SHOULDであることでの'ヘッダー、取り除いてください。
Future delivery is a message submission (e.g., [Submission]), not message relay feature.
今後の配送はメッセージリレー機能ではなく、メッセージ提案(例えば、[服従])です。
Delivery report request
配送レポート要求
Requests for delivery status notifications (DSNs) SHOULD be transmitted in the [SMTP] envelope by using the DSN extension as specified in [DSN-SMTP] to request "success" or "none" notification (depending on the value of the 'X-Mms-Delivery-Report' header). When the NOTIFY extension is used, the unaltered recipient address SHOULD be transmitted as the ORCPT value.
配送状態通知(DSNs)SHOULDのために、[SMTP]封筒で「成功」か「なにも」通知を要求するのに[DSN-SMTP]の指定されるとしてのDSN拡張子を使用することによって伝えられるよう('X-Mms配送レポート'ヘッダーの値によって)要求します。 NOTIFYであるときに、拡大は使用されていて、非変更は受取人アドレスSHOULDです。ORCPT値として、伝えられます。
The 'X-Mms-Delivery-Report:' header, if present, SHOULD be removed.
'X-Mms配送レポート: プレゼント、SHOULDであることでの'ヘッダー、取り除いてください。
Importance
重要性
The message sender's importance value (also called "priority", although this can be confused with class-of-service values) SHOULD be transmitted using an 'Importance:' header.
メッセージ送付者の重要性は伝えられた使用が'の重要性であったならSHOULDを評価します(また、これがサービスのクラス値に混乱できますが、「優先権」と呼ばれます): 'ヘッダー。
Suggested mappings are shown in Table 2:
提案されたマッピングはTable2に示されます:
Gellens Standards Track [Page 11] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[11ページ]。
2.1.3.2.1. Table 2: Importance Mappings (MMS to Internet Message)
2.1.3.2.1. テーブル2: 重要性マッピング(インターネットメッセージへのMMS)
---------------------------|------------------
'X-Mms-Priority: High' |'Importance: High'
---------------------------|------------------
'X-Mms-Priority: Normal' |[omit]
---------------------------|------------------
'X-Mms-Priority: Low' |'Importance: Low'
---------------------------|------------------
---------------------------|------------------ 'X-Mms-優先権:' '高い'|'重要性:' '高い'---------------------------|------------------ 'X-Mms-優先権:' '標準'|[省略します]---------------------------|------------------ 'X-Mms-優先権:' '低い'|'重要性:' '低い'---------------------------|------------------
Normal importance messages should omit the 'Importance:' header.
正常な重要性メッセージは'の重要性を省略するべきです: 'ヘッダー。
The 'X-Mms-Priority:' header, if present, SHOULD be removed.
'X-Mms-優先権: プレゼント、SHOULDであることでの'ヘッダー、取り除いてください。
Sender visibility
送付者目に見えること
Support for sender address hiding is not currently supported.
送付者アドレス隠れることのサポートは現在、支持されません。
A message that contains an 'X-Mms-Sender-Visibility:' header with a value of 'Hide' SHOULD be rejected.
'隠れてください'というSHOULDの値が拒絶されている状態で'X-Mms送付者目に見えること: 'ヘッダーを含むメッセージ。
The 'X-Mms-Sender-Visibility:' header, if present, SHOULD be removed.
'X-Mms送付者目に見えること: プレゼント、SHOULDであることでの'ヘッダー、取り除いてください。
Read reply request
回答要求を読んでください。
A request for a read reply SHOULD be transmitted using a 'Disposition-Notification-To:' header as specified in [MDN].
Aは、読書回答SHOULDのために[MDN]の指定されるとしての'気質通知To:'ヘッダーを使用することで伝えられるよう要求します。
The 'X-Mms-Read-Reply:' header, if present, SHOULD be removed.
'X-Mmsは回答を読む'というプレゼント、SHOULDであることでのヘッダー、取り除いてください。
Reply charging
回答充電
Reply charging permission and acceptance are complex issues requiring both user agent and server support. Misapplied reply charging may cause incorrect billing. Until the security issues have been properly addressed, reply charging SHOULD NOT be honored when using this interface.
許可と承認がユーザエージェントとサーバサポートの両方を必要とする複雑な問題であると宣言して、返答してください。 誤用された回答充電は不正確な支払いを引き起こすかもしれません。 このインタフェースを使用するとき、SHOULD NOTが光栄に思っていると宣言しながら、安全保障問題が適切に記述されるまで、返答してください。
The 'X-Mms-Reply-Charging:', 'X-Mms-Reply-Charging-Deadline:', 'X-
Mms-Reply-Charging-Size:', and 'X-Mms-Reply-Charging-Id:' headers MAY
be removed. Messages containing a reply-charging usage request ('X-
Mms-Reply-Charging-Id:' and 'X-Mms-Reply-Charging: accepted' or 'X-
Mms-Reply-Charging: accepted (text only)' headers) SHOULD be
rejected.
'充電して、X-Mmsは返答します: ''締め切りを請求して、X-Mmsは返答''X Mms回答充電サイズ: ''X-Mms回答充電イド:'ヘッダーを取り除くかもしれません。 回答使用料を含むメッセージは、SHOULDが拒絶されるよう要求します('X Mms回答充電イド: ''充電して、X-Mmsは返答します: 受け入れる'か、'X Mms回答請求: 受け入れられた(テキスト専用)'ヘッダー)。
Gellens Standards Track [Page 12] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[12ページ]。
Subject
対象
The 'Subject:' header MUST be preserved. The current Internet message format requires that only 7-bit US-ASCII characters be present. Other characters MUST be encoded according to [Hdr-Enc]. Note that it is possible for an [SMTP] extension to be defined that would permit transmission of unencoded 8-bit characters, but in the absence of such an extension, [Hdr-Enc] MUST be used.
'Subject:'ヘッダーを保存しなければなりません。 現在のインターネットメッセージ・フォーマットは、7ビットの米国-ASCII文字だけに出席しているのを必要とします。 [Hdr-Enc]に従って、他のキャラクタをコード化しなければなりません。 [SMTP]拡大が定義されるために、それが暗号化されていない8ビットのキャラクタの遺伝を可能にするでしょうが、そのような拡大がないとき[Hdr-Enc]を使用しなければならないのが可能であることに注意してください。
Resending
再送
A message may be resent to one or more new recipients. It may be resent more than once, each time new 'Resent-' headers are added at the top of the existing headers. Thus, if more than one series of 'Resent-' headers are present, the original series is the last; the most recent is the first.
1人以上の新しい受取人にメッセージを再送するかもしれません。 一度以上をそれに再送するかもしれません、'再送された'という新しいヘッダーが既存のヘッダーの先端で加えられる各回。 したがって、1つ以上のシリーズについて'再送した'ヘッダーが出席しているなら、オリジナルのシリーズは最終です。 最新であるのは、1番目です。
Forward counter
フォワードカウンタ
An 'X-Mms-Forward-Counter:' header, if present, SHOULD be removed. The 'Resent-Count:' header is NOT RECOMMENDED. Loop control is usually done by counting 'Received' headers, which are more general than 'Resent-' headers.
'X-Mmsはカウンタを進める'というプレゼント、SHOULDであることでのヘッダー、取り除いてください。 '-再送して、数えてください'というヘッダーはNOT RECOMMENDEDです。 通常、'受け取られていている'ヘッダーを数えることによって、ループ制御をします。(ヘッダーはヘッダーに'再送する'より一般的です)。
Previously-Sent Information
以前に送られた情報
MMS lists the resending history of a message in two headers: 'X- Mms-Previously-Sent-By:' and 'X-Mms-Previously-Sent-Date-and-Time:'. 'X-Mms-Previously-Sent-By:' contains a number followed by one or more addresses. 'X-Mms-Previously-Sent-Date-and-Time:' contains a number followed by a date-time. With both headers, the number "0" is used for the entry that corresponds to the original submission of the message, with higher values being used for each subsequent resending. The final (most recent) resending information is in the 'From:' and 'Date:' headers. There is also an 'X-Mms-Forward-Counter:' that indicates how many times the message has been resent.
MMSは2個のヘッダーのメッセージの再送歴史をリストアップします: '以前に発信したX Mms:'そして、'X-Mmsは以前に、日時を送りました'。 '以前に発信したX-Mms:'数を含んでいます、続いて、1つ以上のアドレスを含みます。 'X-Mmsは以前に、日付と時間を送ったこと'は日付-時間までに続かれる数を含んでいます。 ヘッダー、両方の数、「0インチはメッセージのオリジナルの服従に対応するエントリーに使用されます、より高い値がそれぞれのその後の再送に使用されている状態で」。 最終的な(最新の)再送情報が'From:'と'日付:'ヘッダーにあります。 また、'X-Mmsの前進のカウンタがあります: 'それは、メッセージが何回再送されたかを示します。
Any 'X-Mms-Previously-Sent-By:', 'X-Mms-Previously-Sent-Date-and- Time:', and 'X-Mms-Forward-Counter:' headers, if present, SHOULD be removed. The information contained in them SHOULD be translated into [Msg-Fmt] headers as follows:
-SHOULD、存在しているなら、: ''X-Mmsの前進のカウンタ:'ヘッダーを調節してください。そして、いずれ'X-Mmsは以前に発信した'以前に'X-Mmsによって送られた期日、-、取り除きます。 情報はそれらにSHOULDを含みました。以下の[エムエスジー-Fmt]ヘッダーに翻訳されてください:
The 'X-Mms-Previously-Sent-Date-and-Time:' header whose value starts with "0" SHOULD be used to create a 'Date:' header, converting the date and time from HTTP-date [HTTP] to date-time [Msg-Fmt]. The 'X- Mms-Previously-Sent-By:' header whose value starts with "0" SHOULD be used to create a 'From:' header.
'X-Mmsは以前に、日付と時間を送った'という値が「0インチは'日付:'ヘッダーを創造するのに使用されるべきです、HTTP日付の[HTTP]から日付-時間[エムエスジー-Fmt]まで日時を変換して」開始するヘッダー。 以前に発信した'X Mms: '値が「0インチは'From:を作成するのに使用されるべきである'ヘッダーから始まるヘッダー」。
Gellens Standards Track [Page 13] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[13ページ]。
A 'To:' header SHOULD be created using list syntax with a value of "unrecoverable-recipients" and no mailboxes.
'To:'ヘッダーSHOULD、「復しない受取人」にもかかわらず、メールボックスがない値があるリスト構文を使用することで、作成されてください。
A 'Message-ID:' header SHOULD be created.
'Message ID: 'ヘッダーSHOULD、作成されてください。
Any 'X-Mms-Previously-Sent-Date-and-Time:' headers whose value starts with "1" or a larger value are mapped to 'Resent-Date:' headers. Any 'X-Mms-Previously-Sent-By:' headers whose value starts with "1" or a larger value are mapped to 'Resent-By:' headers.
'いくらか、X-Mmsは以前に、日付と時間を送りました: '値が「1インチか、より大きい値が日付:に憤慨している''ヘッダーに写像されること」から開始するヘッダー。 値が「1インチか、より大きい値が'以下に憤慨してください'ヘッダーに写像されること」から開始するどんな'X-Mmsは以前に、発信した'ヘッダー。
The 'From:', 'To:', 'Date:', and 'Message-ID:' headers are mapped to 'Resent-From:', 'Resent-To:', 'Resent-Date:', and 'Resent-Message- ID:' headers in the top-most block of 'Resent-*' headers.
'From:'、'To:'、'日付:'、および': 'ヘッダーが写像されるメッセージID'、From:に憤慨する、'、'、To:に憤慨する、'、*に憤慨している''日付:に憤慨している': '先端だいたいのヘッダーが妨げるメッセージIDに憤慨する''ヘッダー。
Example:
例:
The MMS message:
MMSメッセージ:
X-Mms-Forward-Counter: 2 X-Mms-Previously-Sent-Date-and-Time: 0, Fri, 01 Apr 2005 06:02:03 GMT X-Mms-Previously-Sent-By: 0, General Failure <mfail@example.mil> X-Mms-Previously-Sent-Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT X-Mms-Previously-Sent-By: 1, Colonel Corn <gcorn@example.mil> Date: Fri, 1 Apr 2005 18:02:03 -0800 From: L. Eva Message <lem@example.org> To: b1ff@mms.example.com Message-ID: <99887766.112233@mail.example.org>
X-Mms-フォワードカウンタ: 2 X-Mmsは以前に、日時を送りました: 0、グリニッジ標準時2005年4月1日金曜日6時2分3秒、以前に発信したX-Mms: 0、一般 Failure <mfail@example.mil 、gt;、X-Mmsは以前に、日時を送りました: 1、グリニッジ標準時2005年4月1日金曜日8時2分3秒、以前に発信したX-Mms: 1、 Corn <gcorn@example.mil 大佐、gt;、日付: 金曜日、2005年4月1日の18:02:03 -0800From: L。 エバ Message <lem@example.org 、gt;、To: b1ff@mms.example.com Message ID: <99887766.112233@mail.example.org>。
is mapped to an Internet mail message:
インターネットメール・メッセージに写像されます:
Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800 Resent-From: L. Eva Message <lem@example.org> Resent-To: b1ff@mms.example.com Resent-Message-ID: <99887766.112233@mail.example.org> Resent-Date: Fri, 1 Apr 2005 08:02:03 +0000 Resent-From: Colonel Corn <gcorn@example.mil> Date: Fri, 1 Apr 2005 06:02:03 +0000 From: General Failure <mfail@example.mil> To: Colonel Corn <gcorn@example.mil> Message-ID: <000.000.000@gateway.example.org>
日付:に憤慨します。 金曜日、2005年4月1日18:02:03 -0800、From:に憤慨します。 L。 エバ Message <lem@example.org 、gt;、To:に憤慨します。 b1ff@mms.example.com 、Message IDに憤慨してください: <99887766.112233@mail.example.org>、日付:に憤慨します。 金曜日、2005年4月1日の08:02:03+0000、From:に憤慨します。 Corn <gcorn@example.mil 大佐、gt;、日付: 金曜日、2005年4月1日の06:02:03+0000From: 一般 Failure <mfail@example.mil 、gt;、To: Corn <gcorn@example.mil 大佐、gt;、Message ID: <000.000.000@gateway.example.org>。
'Received:' Headers
'受け取りました: 'ヘッダー
When a message is gatewayed from MMS to Internet mail, a 'Received:' header MUST be added as per [SMTP]. The "with" clause should specify "MMS".
メッセージがMMSからインターネット・メールまでgatewayedされるとき、[SMTP]に従って'受け取った'というヘッダーを加えなければなりません。 “with"節は「MMS」を指定するべきです。
Gellens Standards Track [Page 14] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[14ページ]。
A message MAY be rejected if the number of 'Received:' headers exceeds a locally-defined maximum, which MUST conform to [SMTP] Section 6.2 and SHOULD be no less than 100.
'受け取った'というヘッダーの数が[SMTP]セクション6.2に従わなければならない局所的に定義された最大を超えているなら、メッセージは拒絶されるかもしれません、そして、SHOULDは100のように拒絶されます。
Privacy
プライバシー
Note that MMS systems do not currently support the 'Privacy' header field as described by [VPIM].
[VPIM]によって説明されるようにMMSシステムが現在'プライバシー'ヘッダーフィールドを支持しないことに注意してください。
Content
内容
The message content appears in the message body. Note that Internet message format requires that line endings be encoded as US-ASCII CR LF octets; thus, charset encodings that do not have this property cannot be used in text/* body parts. (They may be used in other body parts, but only when they are suitably encoded or when binary transmission has been negotiated, e.g., [BINARY].) In particular, MMS allows UTF-16, whereas the Internet message format does not. UTF-16 encoding MUST be translated to UTF-8 or another charset and encoding that is suitable for use in Internet message format/protocols.
メッセージ内容はメッセージ本体に現れます。 インターネットメッセージ・フォーマットが、線結末が米国-ASCII CR LF八重奏としてコード化されるのを必要とすることに注意してください。 したがって、テキスト/*身体部分でこの特性を持っていないcharset encodingsは使用できません。 (それらは他の身体の部分にもかかわらず、いつだけ適当にそれらをコード化するか、そして、または2進のトランスミッションが交渉されたときに時使用されるかもしれません、例えば、[BINARY]。) インターネットメッセージ・フォーマットは許容しませんが、特に、MMSはUTF-16を許容します。 UTF-8か別のcharsetに翻訳しなければならなくて、それをコード化するUTF-16コード化はインターネットメッセージ・フォーマット/プロトコルにおける使用に適しています。
2.1.3.3. Conversion of Messages from Internet to MMS Format
2.1.3.3. メッセージのインターネットからMMS形式までの変換
3GPP MMS Version
3GPP MMSバージョン
An 'X-Mms-3GPP-MMS-Version:' header SHOULD be added.
'X-Mms-3GPP-MMS-バージョン: 'ヘッダーSHOULD、加えられてください。
Message Type (of PDU)
メッセージタイプ(PDUの)
An 'X-Mms-Message-Type:' header SHOULD be used in accordance with the specific MMS interface (e.g., MM1, MM4).
'X-Mmsメッセージタイプ: 'ヘッダーSHOULD、特定のMMSインタフェース(例えば、MM1、MM4)に従って、使用されてください。
Transaction ID
取引ID
An 'X-Mms-Transaction-Id:' header SHOULD be used in accordance with the specific MMS interface (e.g., MM1, MM4).
'X-Mms取引イド: 'ヘッダーSHOULD、特定のMMSインタフェース(例えば、MM1、MM4)に従って、使用されてください。
Message ID
メッセージID
The 'Message-Id:' header MUST be retained. If not present, it MUST be created, with a unique value.
'メッセージイド: 'ヘッダーを保有しなければなりません。 プレゼントでないなら、ユニークな値でそれを作成しなければなりません。
Recipient(s) address
受取人アドレス
'To:' and 'Cc:' headers MUST be retained.
'To:'と'Cc:'ヘッダーを保有しなければなりません。
Gellens Standards Track [Page 15] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[15ページ]。
Each recipient contained in the [SMTP] envelope (RCPT TO values) MUST be considered a recipient of the message. Recipients who appear in address headers but not the [SMTP] envelope MUST be ignored. Recipients who appear in the [SMTP] envelope but do not appear in headers are considered "blind" (Bcc) recipients; such recipients MUST NOT be added to message headers (including address and trace headers) unless there is only one recipient total.
メッセージの受取人であると[SMTP]封筒(RCPT TO値)を含まれた各受取人を考えなければなりません。 [SMTP]封筒ではなく、アドレスヘッダーに現れる受取人を無視しなければなりません。 [SMTP]封筒に現れますが、ヘッダーに現れない受取人は「盲目」の(Bcc)受取人であると考えられます。 1つの受取人合計しかない場合、メッセージヘッダー(アドレスと跡のヘッダーを含んでいる)にそのような受取人を加えてはいけません。
Sender address
送付者アドレス
The 'From:' header MUST be retained.
'From:'ヘッダーを保有しなければなりません。
Content type
満足しているタイプ
The complete 'Content-Type:' header (including any parameters) SHOULD be preserved.
'コンテントタイプ:'ヘッダー(どんなパラメタも含んでいる)SHOULDを完成してください。保存されます。
Message class
メッセージのクラス
An 'X-Mms-Message-Class: personal' header MAY be created for all received messages with a non-null return path (MAIL FROM value in the SMTP envelope). An 'X-Mms-Message-Class: auto' header MAY be created for messages with a null return path.
'X-Mmsメッセージのクラス:' '個人的な'ヘッダーはすべての受信されたメッセージのために非ヌルリターンパス(SMTP封筒のMAIL FROM値)で創造されるかもしれません。 'X-Mmsメッセージのクラス:' '自動である'ヘッダーはメッセージのためにヌルリターンパスで創造されるかもしれません。
Time of Expiry
満期の時間
An 'X-Mms-Expiry:' header SHOULD be created if the message contains a relative time to expiration in the DELIVER-BY extension with a by- mode of "R", as specified in [Deliver-By].
メッセージがaとのDELIVER-BY拡張子に相対的な時間を満了に含むなら、作成されてください。'X-Mms-満期: 'ヘッダーSHOULD、中で指定されるとしての「R」[近く、配送する]のモード。
If the by-mode is "N", a "relayed" DSN MUST be issued per [Deliver-By] and an 'X-Mms-Expiry:' header SHOULD NOT be created.
モード、[近く、配送します]単位で「N」、aが「リレーされる」というDSNを発行しなければならなくて、'X-Mms-満期: 'ヘッダーを創造するべきではありません。
Delivery report request
配送レポート要求
An 'X-Mms-Delivery-Report:' header SHOULD be created for messages that request 'success' or 'none' delivery status notification by use of the DSN extension as specified in [DSN-SMTP]. Requests for 'delay' notifications or non-default actions, such as that only the message headers should be returned, cannot be mapped onto MMS headers and thus SHOULD be ignored.
'X-Mms配送レポート: 'ヘッダーSHOULD、[DSN-SMTP]の指定されるとしてのDSN拡張子の使用で'成功'か'なにも'配送状態通知を要求するメッセージには、作成されてください。 それだけなどの'遅れ'通知か非デフォルト動作のために、ヘッダーは返すべきであり、ヘッダーがMMSに写像されて、その結果、SHOULDは写像できないというメッセージが無視されるよう要求します。
Gellens Standards Track [Page 16] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[16ページ]。
Importance
重要性
The message sender's importance value (also called "priority", although this can be confused with class-of-service values) is expressed with an 'Importance:' header. Historically, some clients used the older and non-standard 'X-Priority:' header for this purpose. As a result, some clients generate both.
メッセージ送付者の重要性値(また、これはサービスのクラス値に混乱できますが、「優先権」と呼ばれる)は'の重要性で言い表されます: 'ヘッダー。 歴史的に、このためにより古くて標準的でない'X-優先権: 'ヘッダーを使用したクライアントもいました。 その結果、両方を発生させるクライアントもいます。
An 'X-Priority:' or 'Importance:' header, if present, SHOULD be replaced with an 'X-Mms-Priority:' header. If both headers are present, 'Importance:' SHOULD be used. Suggested mappings are shown in Table 3:
'X-優先: ''重要性:'プレゼント、SHOULDであることでのヘッダー、'X-Mms-優先に取り替えてください: 'ヘッダー。 : 'ヘッダーは両方であるなら出席していて、'の重要性はSHOULDです。使用されます。 提案されたマッピングはTable3に示されます:
2.1.3.3.1. Table 3: Priority Mappings (Internet Message to MMS)
2.1.3.3.1. テーブル3: 優先権マッピング(MMSへのインターネットメッセージ)
-------------------------------|----------------------
'X-Priority: 1 (highest)' |'X-Mms-Priority: High'
-------------------------------|----------------------
'X-Priority: 2 (high)' |'X-Mms-Priority: High'
-------------------------------|----------------------
'Importance: High' |'X-Mms-Priority: High'
-------------------------------|----------------------
'X-Priority: 3 (normal)' | [omitted]
-------------------------------|----------------------
'Importance: Normal' | [omitted]
-------------------------------|----------------------
'X-Priority: 4 (low)' |'X-Mms-Priority: Low'
-------------------------------|----------------------
'Importance: Low' |'X-Mms-Priority: Low'
-------------------------------|----------------------
'X-Priority: 5 (lowest)' |'X-Mms-Priority: Low'
-------------------------------|----------------------
-------------------------------|---------------------- 'X-優先権:' '1(最も高い)'|'X-Mms-優先権:' '高い'-------------------------------|---------------------- 'X-優先権:' '2(高い)'|'X-Mms-優先権:' '高い'-------------------------------|---------------------- '重要性:' '高い'|'X-Mms-優先権:' '高い'-------------------------------|---------------------- 'X-優先権:' '3(正常な)'| [省略されます]-------------------------------|---------------------- '重要性:' '標準'| [省略されます]-------------------------------|---------------------- 'X-優先権:' '4(低い)'|'X-Mms-優先権:' '低い'-------------------------------|---------------------- '重要性:' '低い'|'X-Mms-優先権:' '低い'-------------------------------|---------------------- 'X-優先権:' '5(最も低い)'|'X-Mms-優先権:' '低い'-------------------------------|----------------------
Normal importance messages SHOULD omit the 'X-Mms-Priority:' header.
正常な重要性メッセージSHOULDは'X-Mms-優先権を省略します: 'ヘッダー。
Sender visibility
送付者目に見えること
Support for sender address hiding is not currently supported.
送付者アドレス隠れることのサポートは現在、支持されません。
Read reply request
回答要求を読んでください。
A request for a read reply contained in a 'Disposition-Notification- To:' header as specified in [MDN] SHOULD be replaced with an 'X-Mms- Read-Reply:' header.
Aは、a'気質通知To:に含まれた読書回答のために'[MDN]SHOULDの指定されるとしてのヘッダーが'X-Mms読書回答に取り替えられるよう要求します: 'ヘッダー。
Subject
対象
The 'Subject:' header MUST be preserved.
'Subject:'ヘッダーを保存しなければなりません。
Gellens Standards Track [Page 17] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[17ページ]。
Resending
再送
Mapping from 'Resent-' and other [Msg-Fmt] headers to 'X-Mms- Previously-Sent-' headers SHOULD be done as follows:
'X-Mms'再送し'て他の[エムエスジー-Fmt]ヘッダーから以前に'ヘッダーを送っているSHOULDまで写像して、以下の通りしてください:
The original 'From:' header is mapped to an 'X-Mms-Previously-Sent- By:' header with a leading "0" value. The value of the top-most 'Resent-From:' header is mapped to the 'From:' header. The value of each subsequent 'Resent-From:' header is mapped to an 'X-Mms- Previously-Sent-By:' header with the next larger leading value.
オリジナルの'From:'ヘッダーは-以前にの'X-Mmsに写像されて、送りました: '主な「0インチの値」があるヘッダーということです。 From:に憤慨している''最も先端ヘッダーの値は'From:'ヘッダーに写像されます。 次の、より大きい主な値があるそれぞれの'From:に憤慨している'ヘッダーは'X-Mmsに以前に発信していた状態で写像されること'のその後のヘッダーの値。
The original 'Date:' header is mapped to an 'X-Mms-Previously-Sent- Date-and-Time:' header with a leading "0" value. Note that the value is also converted from date-time syntax [Msg-Fmt] to HTTP-date syntax [HTTP]. The value of the top-most 'Resent-Date:' header is mapped to the 'Date:' header. The value of each subsequent 'Date:' header is mapped to an 'X-Mms-Previously-Sent-Date-and-Time:' header with the next larger leading value.
オリジナルの'日付:'ヘッダーは主な「0インチの値」で以前に'X-Mmsによって送られた期日と時間: 'ヘッダーに写像されます。 また、値が日付-時間構文[エムエスジー-Fmt]からHTTP日付の構文[HTTP]まで変換されることに注意してください。 日付:に憤慨している''最も先端ヘッダーの値は'日付:'ヘッダーに写像されます。 それぞれのその後の'日付:'ヘッダーの値は次の、より大きい主な値で'X-Mmsは以前に、日付と時間を送った'というヘッダーに写像されます。
If one or more 'Resent-Message-ID:' headers are present, the top-most one SHOULD be mapped to 'Message-ID:'; otherwise, the 'Message-ID:' header should be retained.
'1以上であるなら、Message IDに憤慨してください: 'ヘッダーは出席していて、最も先端は1SHOULDです。'Message IDに写像されてください:、'、。 さもなければ、'Message ID: 'ヘッダーは保有されるべきです。
An 'X-Mms-Forward-Counter:' header SHOULD be created when 'Resent-' headers have been mapped to 'X-Mms-Previously-Sent-' headers. Its value SHOULD be the number of 'Resent-' blocks that existed prior to mapping.
'X-Mmsの前進のカウンタ: 'ヘッダーSHOULD、'再送され'て、ヘッダーが'X-Mmsが以前に'ヘッダーを発信させるのに写像されたときには、作成されてください。 それ、'再送した'数がマッピングの前に存在したブロックであったならSHOULDを評価してください。
Example:
例:
The original message:
オリジナルのメッセージ:
Date: Fri, 1 Apr 2005 14:02:03 -0800 From: General Failure <mfail@example.mil> To: Colonel Corn <gcorn@example.mil> Message-ID: <msg123@mail.example.mil>
日付: 金曜日、2005年4月1日の14:02:03 -0800From: 一般 Failure <mfail@example.mil 、gt;、To: Corn <gcorn@example.mil 大佐、gt;、Message ID: <msg123@mail.example.mil>。
Is resent by Colonel Corn to L. Eva Message:
Corn大佐によってL.エバMessageに再送されます:
Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800 Resent-From: Colonel Corn <gcorn@example.mil> Resent-To: L. Eva Message <lem@example.org> Resent-Message-ID: <msg234@mail.example.mil> Date: Fri, 1 Apr 2005 14:02:03 -0800 From: General Failure <mfail@example.mil> To: Colonel Corn <gcorn@example.mil> Message-ID: <msg123@mail.example.mil>
日付:に憤慨します。 金曜日、2005年4月1日16:02:03 -0800、From:に憤慨します。 Corn <gcorn@example.mil 大佐、gt;、To:に憤慨します。 L。 エバ Message <lem@example.org 、gt;、Message IDに憤慨してください: <msg234@mail.example.mil>日付: 金曜日、2005年4月1日の14:02:03 -0800From: 一般 Failure <mfail@example.mil 、gt;、To: Corn <gcorn@example.mil 大佐、gt;、Message ID: <msg123@mail.example.mil>。
Gellens Standards Track [Page 18] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[18ページ]。
L. Eva then resends to her MMS device:
そして、L.エバは彼女のMMS装置に以下を再送します。
Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800 Resent-From: L. Eva Message <lem@example.org> Resent-To: b1ff@mms.example.com Resent-Message-ID: <99887766.112233@mail.example.org> Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800 Resent-From: Colonel Corn <gcorn@example.mil> Resent-To: L. Eva Message <lem@example.org> Resent-Message-ID: <msg234@mail.example.mil> Date: Fri, 1 Apr 2005 14:02:03 -0800 From: General Failure <mfail@example.mil> To: Colonel Corn <gcorn@example.mil> Message-ID: <msg123@mail.example.mil>
日付:に憤慨します。 金曜日、2005年4月1日18:02:03 -0800、From:に憤慨します。 L。 エバ Message <lem@example.org 、gt;、To:に憤慨します。 b1ff@mms.example.com 、Message IDに憤慨してください: <99887766.112233@mail.example.org>、日付:に憤慨します。 金曜日、2005年4月1日16:02:03 -0800、From:に憤慨します。 Corn <gcorn@example.mil 大佐、gt;、To:に憤慨します。 L。 エバ Message <lem@example.org 、gt;、Message IDに憤慨してください: <msg234@mail.example.mil>日付: 金曜日、2005年4月1日の14:02:03 -0800From: 一般 Failure <mfail@example.mil 、gt;、To: Corn <gcorn@example.mil 大佐、gt;、Message ID: <msg123@mail.example.mil>。
This would be mapped to an MMS message as:
これは以下としてMMSメッセージに写像されるでしょう。
X-Mms-Forward-Counter: 2 X-Mms-Previously-Sent-Date-and-Time: 0, Fri, 01 Apr 2005 06:02:03 GMT X-Mms-Previously-Sent-By: 0, General Failure <mfail@example.mil> X-Mms-Previously-Sent-Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT X-Mms-Previously-Sent-By: 1, Colonel Corn <gcorn@example.mil> Date: Fri, 1 Apr 2005 18:02:03 -0800 From: L. Eva Message <lem@example.org> To: b1ff@mms.example.com Message-ID: <99887766.112233@mail.example.org>
X-Mms-フォワードカウンタ: 2 X-Mmsは以前に、日時を送りました: 0、グリニッジ標準時2005年4月1日金曜日6時2分3秒、以前に発信したX-Mms: 0、一般 Failure <mfail@example.mil 、gt;、X-Mmsは以前に、日時を送りました: 1、グリニッジ標準時2005年4月1日金曜日8時2分3秒、以前に発信したX-Mms: 1、 Corn <gcorn@example.mil 大佐、gt;、日付: 金曜日、2005年4月1日の18:02:03 -0800From: L。 エバ Message <lem@example.org 、gt;、To: b1ff@mms.example.com Message ID: <99887766.112233@mail.example.org>。
Note that the original 'From:' and 'Date:' values were moved to 'X- Mms-Previously-Sent-By:' and 'X-Mms-Previously-Sent-Date-and-Time:' headers with a leading "0" value. The first 'Resent-From:' and 'Resent-Date:' values were moved to a second set of 'X-Mms- Previously-Sent-' headers, with a leading "1" value. The third set of 'Resent-' headers were moved to the 'Date:', 'To:', and 'From:' headers.
主な「0インチの値」でそのオリジナルの'From:'と日付: '値は以前に発信した'X Mmsに動かされ'て、''X-Mmsは以前に、日付と時間を送った'というヘッダーに注意してください。 ''最初に、From:に憤慨している'日付:に憤慨している'値はセットされた2番目に動かされた'X-Mms以前に、主な「1インチの値」と共に'ヘッダーを送ります。 3番目のセットの''ヘッダーは'日付:'に動かされた'To:に憤慨してください'、および'From:'ヘッダー。
Note also that the format of the date and time differs between the 'Date:' / 'Resent-Date:' and the 'X-Mms-Previously-Sent-Date-and- Time:' headers, in that the latter use HTTP-date [HTTP] instead of date-time [Msg-Fmt].
そして、注意、また、日時の形式は'日付:'/'の間で日付:に憤慨する状態で異なります'、以前に'X-Mmsによって送られた期日、-、-: 'ヘッダーを調節してください、後者が日付-時間[エムエスジー-Fmt]の代わりにHTTP日付の[HTTP]を使用するので。
'Received:' Headers
'受け取りました: 'ヘッダー
Each system that processes a message SHOULD add a 'Received:' header as per [SMTP]. A message MAY be rejected if the number of 'Received:' headers exceeds a locally-defined maximum, which MUST conform to [SMTP] Section 6.2 and SHOULD be no less than 100.
SHOULDが[SMTP]に従って'受け取った'というヘッダーを加えるというメッセージを処理する各システム。 '受け取った'というヘッダーの数が[SMTP]セクション6.2に従わなければならない局所的に定義された最大を超えているなら、メッセージは拒絶されるかもしれません、そして、SHOULDは100のように拒絶されます。
Gellens Standards Track [Page 19] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[19ページ]。
Sensitivity
感度
The 'Sensitivity:' header field (value = "personal" or "private")
[VPIM] indicates the desire of a voice message originator to send the
message contents to the original recipient list with assurance that
the message will not be forwarded further by either the messaging
system or the actual message recipient(s). Since sensitivity is not
an MMS feature, any messages that contain a 'Sensitivity:' header
MUST NOT be sent to an MMS system. The associated negative delivery
status report MUST include the extended status code [RESP] 5.6.0 as
specified in [VPIM] ("Other or undefined protocol status") indicating
that privacy could not be ensured.
'感度: 'ヘッダーフィールド(値=の「個人的である」か「個人的な」)[VPIM]は音声メール創始者がオリジナルの受取人リストにメッセージ内容を自信を持って送るメッセージがメッセージシステムか実際のメッセージ受取人のどちらかによってさらに転送されない願望を示します。 以来、感度はMMSの特徴、'感度を含むあらゆるメッセージではありません: 'MMSシステムにヘッダーを送ってはいけません。 関連否定的配送現状報告が拡張ステータスコード[RESP]を含まなければならない、5.6、.0、[VPIM]で指定されるように、そのプライバシーを示す(「他の、または、未定義のプロトコル状態」)は確実にすることができませんでした。
Content
内容
The message content appears in the message body.
メッセージ内容はメッセージ本体に現れます。
2.1.4. Report Generation and Conversion
2.1.4. レポート作成と変換
Internet message systems use the multipart/report MIME type for delivery and disposition reports as specified in [Report-Fmt]. This format is a two- or three-part MIME message; one part is a structured format describing the event being reported in an easy-to-parse format. Specific reports have a format that is built on [Report-Fmt]. Delivery reports are specified in [DSN-Msg]. Message disposition reports, which include read reports, are specified in [MDN].
インターネットメッセージシステムは[レポート-Fmt]での指定されるとしての配送と気質レポートに複合/レポートMIMEの種類を使用します。 この形式は、2か3部分のMIMEメッセージです。 一部が分析しやすい形式で報告される出来事について説明する構造化された形式です。 特定のレポートには、[レポート-Fmt]で築き上げられる形式があります。 配送レポートは[DSN-エムエスジー]で指定されます。 メッセージ気質レポート(読書レポートを含んでいる)は[MDN]で指定されます。
By contrast, MMS reports are plain text, with no defined structure specified. This makes it difficult to convert from an MMS report to a standard Internet report.
対照的に、MMSレポートは定義された構造が全く指定されていないプレーンテキストです。 これで、MMSレポートから標準のインターネットレポートまで変換するのは難しくなります。
An implementation conforming to this specification MUST convert reports received from one side (MMS or Internet mail) destined for the other. In addition, reports MUST be generated as appropriate for messages received from either side. For example, if an MM to be sent via Internet mail is not deliverable, a delivery status MM shall be generated. Likewise, if an Internet message is received that cannot be further relayed or delivered, a delivery status report [DSN-Msg] MUST be generated.
この仕様に従う実現はもう片方のために運命づけられた半面(MMSかインターネット・メール)から受け取られたレポートを変換しなければなりません。 さらに、どちらの側からも受け取られたメッセージのために適宜レポートを作らなければなりません。 例えば、インターネット・メールで送るのは提出物です、配送状態ということであるMMであるなら、MMが発生するものとします。 同様に、インターネットメッセージが受信されているなら、それをさらにリレーできませんし、渡すことができないで、配送現状報告[DSN-エムエスジー]を発生させなければなりません。
When creating delivery or disposition reports from MMS reports, the MMS report should be parsed to determine the reported event and time, status, and the headers of the referenced (original) message. These elements, once determined, are used to populate the subparts of the delivery or disposition report. The first subpart is of type text/plain, and contains a human-readable explanation of the event. This text may include a statement that the report was synthesized
MMSレポートから配送か気質レポートを作成するとき、MMSレポートは、参照をつけられた(オリジナルの)メッセージの報告された出来事、時間、状態、およびヘッダーを決定するために分析されるべきです。 これらのかつて決定している要素は、配送か気質レポートの下位区分に居住するのに使用されます。 最初の下位区分は、タイプテキスト/平野があって、出来事の人間読み込み可能な説明を含んでいます。 本稿はレポートが統合されたという声明を含むかもしれません。
Gellens Standards Track [Page 20] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[20ページ]。
based on an MMS report. The second subpart is of type report/delivery-status (for delivery reports) or report/disposition- notification (for disposition reports). This second part contains a structured itemization of the event. The optional third subpart is of type message/rfc822 and includes the headers and optionally the body of the referenced (original) message. Note that, per [DSN-Msg], the 'DSN-Gateway:' field in delivery reports MUST be created.
MMSに基づいて、報告してください。 2番目の下位区分はタイプ配送レポート/状態(配送レポートのための)かレポート/気質通知(気質レポートのための)のものです。 この第二部は出来事の構造化された個条書きを含んでいます。 3番目の任意の下位区分は、タイプメッセージ/rfc822にはあって、ヘッダーを含んでいます、そして、任意に、参照箇所のボディー(オリジナルの)は通信します。 配送レポートで[DSN-エムエスジー]単位で'DSN-ゲートウェイ: '分野を作成しなければならないことに注意してください。
2.1.4.1. Delivery Report Mapping from MMS to Internet Message
2.1.4.1. MMSからインターネットメッセージまでの配送レポートマッピング
Below, Table 4 maps information elements from MMS delivery reports to the format specified in [DSN-Msg].
以下では、Table4はMMS配送レポートから[DSN-エムエスジー]で指定された形式まで情報要素を写像します。
2.1.4.1.1. Table 4: Delivery Report Mappings (MMS to Internet Message)
2.1.4.1.1. テーブル4: 配送レポートマッピング(インターネットメッセージへのMMS)
======================|============|===================================
Information Element |MMS Delivery|[DSN-Msg] Element
|Report Elem |
======================|============|===================================
ID of message whose |Message-Id: |'Message-ID:' preserved in third
delivery status is | |subpart of delivery report.
being reported | |
----------------------|------------|-----------------------------------
Recipient address of |From: |'Final-Recipient' field of the
the original message | |per-recipient section.
(object of delivery | |
report) | |
----------------------|------------|-----------------------------------
Destination address of|To: |'To:' header field value of top-
report | |level.
----------------------|------------|-----------------------------------
Date and time the |Date: |'Date:' header field value of top-
message was handled | |level.
----------------------|------------|-----------------------------------
======================|============|=================================== 情報要素|MMS配送|[DSN-エムエスジー] 要素|レポートElem| ======================|============|=================================== メッセージのID、だれのもの|メッセージイド: |'Message ID:'3番目の配送で保存されて、状態はそうです。| |配送レポート報告された存在の下位区分| | ----------------------|------------|----------------------------------- 受取人アドレス|From: |オリジナルのメッセージの'最終的な受取人'分野| |1受取人あたりのセクション。 (配送の目的| | レポート) | | ----------------------|------------|----------------------------------- 送付先アドレス|To: |'To:'先端レポートのヘッダーフィールド値| |レベル。 ----------------------|------------|----------------------------------- 日時|日付: |先端メッセージの'日付:'ヘッダーフィールド価値は扱われました。| |レベル。 ----------------------|------------|-----------------------------------
Gellens Standards Track [Page 21] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[21ページ]。
======================|============|===================================
Information Element |MMS Delivery|[DSN-Msg] Element
|Report Elem |
======================|============|===================================
Delivery status of |X-Mms- |Action and Status fields of
original message to | Status: |per-recipient section.
each recipient | |
| |The 'Action' field indicates if the
| |message was delivered.
| |
| |For failed delivery, an appropriate
| |'Status' value shall be included
| |per [DSN-Msg].
| |
| |The Action field is set to one of
| |the following values:
| |
| |* delivered (used for MMS status
| |values 'retrieved' and 'rejected',
| |depending on 'Status' code).
| |
| |* failed (used for MMS status
| |values 'expired' and 'unreachable')
| |
| |* delayed MAY be used for MMS
| |status value 'deferred'
| |
| |* relayed (used for MMS status
| |value 'indeterminate')
| |
| |* expanded (SHOULD NOT be used)
----------------------|------------|-----------------------------------
Status Text | |Text in first part (human-readable
| |part).
----------------------|------------|-----------------------------------
======================|============|=================================== 情報要素|MMS配送|[DSN-エムエスジー] 要素|レポートElem| ======================|============|=================================== 配送状態|X-Mms|オリジナルの分野が通信する動作とStatus| 状態: |1受取人あたりのセクション 各受取人| | | |'動作'分野は示します。| |メッセージは提供されました。 | | | |失敗した配送のために適切| |'状態'値は含まれているものとします。| |[DSN-エムエスジー]単位で。 | | | |Action分野は1つに設定されます。| |以下の値: | | | |* 配送しました(MMSのために、'状態'コードで状態| | | | '検索され'て、'拒絶された'値、依存を使用します)。 | | | |* 失敗されます(状態| | 値が'吐き出した'MMSに中古の、そして、'手の届かない')。| | | |* 遅らせられて、MMSに使用されるかもしれません。| |'延期された'状態値| | | |* リレーされます(MMS状態| | 値のために、'不確定'で、使用されます)。| | | |* 広げる、(SHOULD NOT、使用されてください、)----------------------|------------|----------------------------------- 状態テキスト| |最初に、部分のテキスト、(人間読み込み可能|、|、部分) ----------------------|------------|-----------------------------------
When an MMS Relay/Server generates a [DSN-Msg] in response to a message received using [SMTP] on MM3:
MMS Relay/サーバが、メッセージに対応した[DSN-エムエスジー]容認された使用がMM3の[SMTP]であると生成すると:
* Top-level header field 'To:' SHOULD be the [SMTP] return-path of
the message whose status is being reported.
* トップレベルヘッダーは[SMTP]がリターンパスであったなら状態が報告されているメッセージについて'To:'SHOULDをさばきます。
* Top-level header field 'From:' SHOULD be the address of the
recipient that the delivery-report concerns.
* 受取人のアドレスがそれであったならヘッダーフィールド'From:'SHOULDを先端で平らにしてください。配送レポート関心。
* The first part of the [DSN-Msg] SHOULD include the MM Status Text
field that would have been generated for an MM1 delivery-report.
* [DSN-エムエスジー]SHOULDの最初の部分はMM1配送レポートのために生成されたMM Status Text分野を含んでいます。
Gellens Standards Track [Page 22] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[22ページ]。
2.1.4.2 Delivery Report Mapping from Internet Message to MMS
2.1.4.2 インターネットメッセージからMMSまでの配送レポートマッピング
Below, Table 5 maps information elements from a delivery report as specified in [DSN-Msg] to the format of an MMS delivery report. Note that a single DSN that reports multiple recipients will result in several MMS delivery reports.
以下では、Table5は[DSN-エムエスジー]における指定されるとしての配送レポートからMMS配送レポートの形式まで情報要素を写像します。 複数の受取人を報告する独身のDSNがいくつかのMMS配送レポートをもたらすことに注意してください。
2.1.4.2.1. Table 5: Delivery Report Mappings (Internet Message to MMS)
2.1.4.2.1. テーブル5: 配送レポートマッピング(MMSへのインターネットメッセージ)
===================|==================|================================
Information Element|MMS Delivery |[DSN-Msg] Element
|Report Element |
===================|==================|================================
ID of the original |Message-Id: |'Message-ID:' header preserved
message (object of | |in third sub-part of report.
delivery report) | |
-------------------|------------------|--------------------------------
Recipient address |From: |If available, the 'Original
of the original | |-Recipient' field of the per-
message (object of | |recipient section should be
delivery report) | |used; otherwise, the 'Final-
| |Recipient' field of the per-
| |recipient section is used.
-------------------|------------------|--------------------------------
Destination address|To: |'To:' header field value of
of report | |top-level.
| |
| |Value taken from [SMTP] envelope
| |return-path of message being
| |reported, not its 'From:' header
| |field.
-------------------|------------------|--------------------------------
Date and time the |Date: |'Date:' header field value of
message was handled| |top-level.
-------------------|------------------|--------------------------------
===================|==================|================================ 情報要素|MMS配送|[DSN-エムエスジー] 要素|レポート要素| ===================|==================|================================ オリジナルのID|メッセージイド: |'Message ID:'ヘッダーはメッセージを保存しました(|オブジェクト| レポート配送の3番目のサブ部分で報告してください)。| | -------------------|------------------|-------------------------------- 受取人アドレス|From: |利用可能である、'オリジナルのオリジナル'| |-'受取人'分野、-、メッセージ(|オブジェクト| 受取人部は配送レポートであるべきです)| |使用されます。 そうでなければ、'決勝'| |'受取人'分野、-| |受取人部は使用されています。 -------------------|------------------|-------------------------------- 送付先アドレス|To: |''ヘッダーが値をさばくレポートのTo:| |トップレベル。 | | | |[SMTP]封筒から取られた値| |メッセージのリターンパス存在| |'From:'ヘッダーではなく報告されます。| |さばきます。 -------------------|------------------|-------------------------------- 日時|日付: |メッセージの'日付:'ヘッダーフィールド価値は扱われました。| |トップレベル。 -------------------|------------------|--------------------------------
Gellens Standards Track [Page 23] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[23ページ]。
===================|==================|================================
Information Element|MMS Delivery |[DSN-Msg] Element
|Report Element |
===================|==================|================================
Delivery status of |X-Mms-Status: |'Action' and 'Status' fields of
original message | |per-recipient section.
|Set to one of the |
|following values: |
| |
|'retrieved' (used |
|for 'Action' value|
|'delivered'). |
| |
|'unreachable' |
|(used for 'Action'|
|value 'failed') |
| |
|'forwarded' (used |
|for 'Action' value|
|'relayed') |
| |
|'deferred' MUST |
|NOT be used |
|(ignore DSNs with |
|'Action' value |
|'delayed') |
-------------------|------------------|--------------------------------
Status Text | |Text in first part (human-
| |readable part).
===================|==================|================================
===================|==================|================================ 情報要素|MMS配送|[DSN-エムエスジー] 要素|レポート要素| ===================|==================|================================ 配送状態|X-Mms-状態: |オリジナルのメッセージの'動作'と'状態'分野| |1受取人あたりのセクション。 |1つに、セットします。| |次の値: | | | |'検索される'、(中古である、| | '動作のために、'|評価してください| '提供される')です。 | | | |'手が届きません'。| |('動作'のために、| 値が'失敗したこと'を使用します) | | | |'進められる'、(中古である、| | '動作のために、'|評価してください| 'リレーされる')です。| | | |'延期'はそうしなければなりません。| |使用されないでください。| |(|DSNsを無視してください| '動作'値| | '延着') | -------------------|------------------|-------------------------------- 状態テキスト| |最初に、部分(人間| | 読み込み可能な部分)のテキスト。 ===================|==================|================================
2.1.4.3. Read Report Mapping from MMS to Internet Message
2.1.4.3. MMSからインターネットメッセージまでレポートマッピングを読んでください。
Below, Table 6 maps information elements from MMS read reports to the format specified in [MDN].
以下では、Table6はレポートが読まれたMMSから[MDN]で指定された形式まで情報要素を写像します。
2.1.4.3.1. Table 6: Read Report Mappings (MMS to Internet Message)
2.1.4.3.1. テーブル6: レポートマッピングを読んでください。(インターネットメッセージへのMMS)
======================|============|===================================
Information Element |MMS Delivery|[MDN] Element
|Report Elem |
======================|============|===================================
ID of the original |Message-Id: |'Message-ID:' header preserved in
message (object of | |third part of report.
read report) | |
----------------------|------------|-----------------------------------
Recipient address of |From: |'Final-Recipient' field.
the original message | |
======================|============|=================================== 情報要素|MMS配送|[MDN]要素|レポートElem| ======================|============|=================================== オリジナルのID|メッセージイド: |'Message ID:'メッセージ|反対してください| レポートの3番目の一部、(レポートを読む)に保存されたヘッダー| | ----------------------|------------|----------------------------------- 受取人アドレス|From: |'最終的な受取人'分野オリジナルのメッセージ| |
Gellens Standards Track [Page 24] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[24ページ]。
======================|============|===================================
Information Element |MMS Delivery|[MDN] Element
|Report Elem |
======================|============|===================================
Destination address of|To: |'To:' header field value of top-
report | |level.
| |
| |Value taken from 'Disposition-
| |Notification-To:' header field of
| |message being reported, not its
| |'From:' header field.
----------------------|------------|-----------------------------------
Date and time the |Date: |'Date:' header field value of top-
message was handled | |level.
----------------------|------------|-----------------------------------
Disposition of message|X-Mms-Read- |Disposition-field
being reported | Status: |
| |For X-MMS-Read-Status value 'read',
| |use 'disposition-type' value
| |'displayed'; for X-MMS-Read-Status
| |value 'Deleted without being read',
| |use 'disposition-type' value
| |'deleted').
----------------------|------------|-----------------------------------
Status Text | |Text in first part (human-readable
| |part).
======================|============|===================================
======================|============|=================================== 情報要素|MMS配送|[MDN]要素|レポートElem| ======================|============|=================================== 送付先アドレス|To: |'To:'先端レポートのヘッダーフィールド値| |レベル。 | | | |'気質'から取られた値| |'通知To:'ヘッダーフィールド| |報告されるメッセージ、それ| |'From:'ヘッダーフィールド。 ----------------------|------------|----------------------------------- 日時|日付: |先端メッセージの'日付:'ヘッダーフィールド価値は扱われました。| |レベル。 ----------------------|------------|----------------------------------- メッセージの気質|X-Mmsによって読まれる、-|報告される気質分野| 状態: | | |状態値が読まれたX-MMSに関しては、'読んでください'| |'気質タイプ'値を使用してください。| |'表示されます'。 状態が読まれたX-MMSのために| |'読まれないで削除された'値| |'気質タイプ'値を使用してください。| |'削除') ----------------------|------------|----------------------------------- 状態テキスト| |最初に、部分のテキスト、(人間読み込み可能| |部分) ======================|============|===================================
When an MMS Relay/Server generates an [MDN] in response to a message received using [SMTP] on MM3:
MMS Relay/サーバがいつメッセージに対応して[MDN]を生成するかはMM3の[SMTP]を使用することで受信されました:
* Top-level header field 'To:' SHOULD be the value of the
'Disposition-Notification-To:' header field of the message whose
disposition is being reported.
* '気質通知To:'の値が気質が報告されているメッセージのヘッダーフィールドであったならヘッダーフィールド'To:'SHOULDを先端で平らにしてください。
* Top-level header field 'From:' SHOULD be the address of the
recipient that the read report concerns.
* 読みが報告する受取人のアドレスが関心であったならヘッダーフィールド'From:'SHOULDを先端で平らにしてください。
2.1.4.4. Disposition Report Mapping from Internet Message to MMS
2.1.4.4. インターネットメッセージからMMSまでの気質レポートマッピング
Below, Table 7 maps information elements from a disposition report as specified in [MDN] to the format of an MMS read report.
以下では、[MDN]での指定されるとしての気質レポートからMMSの形式までの情報要素が読むTable7地図が報告します。
Gellens Standards Track [Page 25] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[25ページ]。
2.1.4.4.1. Table 7: Disposition Report Mappings
(Internet Message to MMS)
2.1.4.4.1. テーブル7: 気質レポートマッピング(MMSへのインターネットメッセージ)
===================|==================|================================
Information Element|MMS Read Report |[MDN] Element
|Element |
===================|==================|================================
ID of the original |Message-Id: |'Message-ID:' header preserved
message (object of | |in third subpart of report.
disposition report)| |
-------------------|------------------|--------------------------------
Recipient address |From: |'Final-Recipient' field.
of the original | |
message | |
-------------------|------------------|--------------------------------
Destination address|To: |'To:' header field value of
of report | |top-level.
| |
| |Value taken from 'Disposition-
| |Notification-To:' header field
| |of message being reported, not
| |its 'From:' header field.
-------------------|------------------|--------------------------------
Date and time the |Date: |'Date:' header field value of
message was handled| |top-level.
-------------------|------------------|--------------------------------
Disposition of |X-Mms-Read-Status:|disposition-field.
message being | |
reported |Set to one of the |
|following values: |
| |
|'read' (used for |
|disposition-type |
|value 'displayed')|
| |
|'Deleted without |
|being read' (used |
|for disposition- |
|types 'deleted', |
|'denied' and |
|'failed' when |
|action-mode is |
|'automatic- |
|action') |
-------------------|------------------|--------------------------------
Status Text | |Text in first part (human-
| |readable part).
===================|==================|================================
===================|==================|================================ 情報要素|MMSはレポートを読みます。|[MDN]要素|要素| ===================|==================|================================ オリジナルのID|メッセージイド: |'Message ID:'ヘッダーはメッセージを保存しました(|オブジェクト| レポート気質の3番目の下位区分では、報告してください)。| | -------------------|------------------|-------------------------------- 受取人アドレス|From: |'最終的な受取人'分野オリジナルについて| | メッセージ| | -------------------|------------------|-------------------------------- 送付先アドレス|To: |''ヘッダーが値をさばくレポートのTo:| |トップレベル。 | | | |'気質'から取られた値| |'通知To:'ヘッダーフィールド| |報告されるメッセージについて| |その'From:'ヘッダーフィールド。 -------------------|------------------|-------------------------------- 日時|日付: |メッセージの'日付:'ヘッダーフィールド価値は扱われました。| |トップレベル。 -------------------|------------------|-------------------------------- 気質|X-Mmsは状態を読みます:、| 気質分野. メッセージがあります。| | 報告されます。|1つに、セットします。| |次の値: | | | |'読んでください、'(中古|、| 気質タイプ、| | 値が'表示した'、)| | | |'削除されます'| |'読まれる、'(使用されます|、|、| | 気質| | '削除された'タイプ、| | '否定'、および'失敗'、いつ|、| 動作モード、| | 'オートマチック| | 動作'であるか、)| -------------------|------------------|-------------------------------- 状態テキスト| |最初に、部分(人間| | 読み込み可能な部分)のテキスト。 ===================|==================|================================
Gellens Standards Track [Page 26] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[26ページ]。
2.1.5. Message Delivery
2.1.5. メッセージ配送
Within Internet mail, when [SMTP] is used and delivery reports are requested [DSN-SMTP], delivery is considered to be acceptance of a message by the final server, that is, the server closest to the recipient. When an MMS Relay/Server receives a message using [SMTP] and a delivery report is requested, the MMS Relay/Server MAY consider the message delivered when it has been sent to the MMS User Agent.
[SMTP]が使用されていて、配送レポートが要求されているとき[DSN-SMTP]、インターネット・メールの中では、すなわち、最終的なサーバによるメッセージの承認、サーバが受取人に最も近かったなら、配送は考えられます。 MMS Relay/サーバが[SMTP]を使用することでメッセージを受け取って、配送レポートが要求されているとき、MMS Relay/サーバはMMS Userエージェントにそれを送ったとき提供するメッセージを考えるかもしれません。
3. Security Considerations
3. セキュリティ問題
Both MMS and Internet mail have their own set of security risks and considerations. This document specifies how to exchange messages between these two environments, so it is only appropriate to discuss considerations specific to this functionality, not those inherent in either environment.
MMSとインターネット・メールの両方には、それら自身のセキュリティリスクと問題のセットがあります。 このドキュメントがこれらの2つの環境の間でメッセージを交換する方法を指定するので、単に環境で固有のそれらではなく、この機能性に特定の問題について議論するのは適切です。
When a message uses end-to-end security mechanisms such as [PGP] or S/MIME [SMIME], servers MUST be careful not to accidently destroy the integrity of the protected content (for example, by altering any text within the region covered by a signature while mapping between MMS and email). [Mime-Sec-gw] discusses issues with use of such mechanisms in gateways.
メッセージが[PGP]かS/MIME[SMIME]などの終わりから終わりへのセキュリティー対策を使用するとき、サーバは、事故に保護された内容(例えばMMSとメールの間で写像している間に署名でカバーされた領域の中のどんなテキストも変更することによって)の保全を破壊しないように慎重でなければなりません。 [秒のgwをまねてください] ゲートウェイでのそのようなメカニズムの使用の問題について議論します。
Some MMS features contain inherently more risk than others, including reply charging and sender address hiding. Support for these mechanisms is not included in this document.
いくつかのMMSの特徴が本来回答充電と送付者アドレス隠れることを含む他のものより多くのリスクを含みます。 これらのメカニズムのサポートは本書では含まれていません。
4. IANA Considerations
4. IANA問題
IANA has added "MMS" as one of the "WITH protocol types" under its "MAIL Parameters" registry. The description is "Multimedia Messaging Service"; the reference is to this document.
IANAは「メールパラメタ」登録の下の「プロトコルタイプ」の1つとして「MMS」を加えました。 記述は「マルチメディア・メッセージング・サービス」です。 このドキュメントには参照があります。
5. Acknowledgements
5. 承認
A number of people contributed to this document, especially the members of the IETF Lemonade working group, including Greg Vaudreuil. John Klensin did a very thorough and helpful review. Greg White caught a large number of nits. Ted Hardie was very helpful. Alexey Melnikov and Chris Newman sent very useful and detailed comments.
多くの人々がこのドキュメント、特にグレッグ・ボードルイを含むIETF Lemonadeワーキンググループのメンバーに貢献しました。 ジョンKlensinは非常に徹底的で役立っているレビューをしました。 グレッグ・ホワイトは何夜も捕らえました。 テッド・ハーディーは非常に助けになりました。 Alexeyメリニコフとクリス・ニューマンは非常に役に立って詳細なコメントを送りました。
6. Normative References
6. 引用規格
[DSN-Msg] Moore, K. and G. Vaudreuil, "An Extensible Message
Format for Delivery Status Notifications", RFC 3464,
January 2003.
[DSN-エムエスジー] ムーアとK.とG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC3464、2003年1月。
Gellens Standards Track [Page 27] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[27ページ]。
[DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP)
Service Extension for Delivery Status Notifications
(DSNs)", RFC 3461, January 2003.
[DSN-SMTP]ムーア、K.、「配送状態通知(DSNs)のためのシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3461、2003年1月。
[Hdr-Enc] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for
Non-ASCII Text ", RFC 2047, November 1996.
[Hdr-Enc]ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[IDN] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[IDN] Faltstrom、P.、ホフマン、P.、およびA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[MDN] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004.
[MDN] ハンセン、T.、およびG.ボードルイ(「メッセージ気質通知」、RFC3798)は2004がそうするかもしれません。
[Msg-Fmt] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[エムエスジー-Fmt] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[Report-Fmt] Vaudreuil, G., "The Multipart/Report Content Type for
the Reporting of Mail System Administrative Messages",
RFC 3462, January 2003.
[レポート-Fmt] ボードルイ、G.、「メールのシステムの管理メッセージの報告のための複合/レポートcontent type」、RFC3462、2003年1月。
[RESP] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
3463, January 2003.
[RESP] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC3463、2003年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[SMTP] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[OMA] OMA specifications are available at the OMA web site
<http://www.openmobilealliance.org>.
[OMA]OMA仕様はOMAウェブサイト<http://www.openmobilealliance.org>で利用可能です。
[OMA-MMS] OMA-WAP-MMS-ENC-V1_2-20040323-C
[OMA-MMS]OMA-ワップMMS-ENC-V1_2-20040323C
[3GPP2] 3GPP2 specifications are available at the 3GPP2 (Third
Generation Partnership Project 2) web site
<http://www.3gpp2.org>.
[3GPP2]3GPP2仕様は3GPP2(3番目のGeneration Partnership Project2)ウェブサイト<http://www.3gpp2.org>で利用可能です。
[3GPP] 3GPP specifications are available at the 3GPP (Third
Generation Partnership Project) web site
<http://www.3gpp.org>
[3GPP]3GPP仕様は3GPP(第3Generation Partnership Project)ウェブサイト<http://www.3gpp.org>で利用可能です。
Gellens Standards Track [Page 28] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[28ページ]。
[Stage_3] "MMS MM1 Stage 3 using OMA/WAP", X.S0016-310
[ステージ_3] 「OMA/WAPを使用するMMS MM1ステージ3」、X.S0016-310
"MMS MM4 Stage 3 Inter-Carrier Interworking", X.S0016-
340
「MMS MM4ステージ3相互キャリヤーの織り込む」X.S0016-340
"Multimedia Messaging Service: Functional description;
Stage 2", TS 23.140 Release 5.
「マルチメディア・メッセージング・サービス:」 機能的な記述。 2インチ、t23.140リリース5を上演してください。
7. Informative References
7. 有益な参照
[BINARY] Vaudreuil, G., "SMTP Service Extensions for
Transmission of Large and Binary MIME Messages", RFC
3030, December 2000.
[2進]のボードルイ、G.、「大きくて2進のMIMEメッセージの伝達のためのSMTPサービス拡張子」、RFC3030、2000年12月。
[Deliver-By] Newman, D., "Deliver By SMTP Service Extension", RFC
2852, June 2000.
ニューマン、D.が「SMTPサービス拡張子で提供する」[近く、配送します]、RFC2852、2000年6月。
[Hdrs] Palme, J., "Common Internet Message Headers", RFC 2076,
February 1997.
[Hdrs]パルメ、J.、「一般的なインターネットメッセージヘッダー」、RFC2076、1997年2月。
[Mime-Sec-gw] Freed, N., "Gateways and MIME Security Multiparts", RFC
2480, January 1999.
[秒のgwをまねてください] フリードと、N.と、「ゲートウェイとMIMEセキュリティMultiparts」、RFC2480、1月1999日
[PGP] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, August 2001.
2001年8月の[PGP]エルキンズとM.とデルTortoとD.とレヴィエン、R.とT.Roessler、「OpenPGPがあるMIMEセキュリティ」RFC3156。
[SMIME] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[SMIME] Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様」、RFC3851、2004年7月。
[Submission] Gellens, R. and J. Klensin, "Message Submission", RFC
2476, December 1998.
[服従]GellensとR.とJ.Klensin、「メッセージ提案」、RFC2476、1998年12月。
[VPIM] Vaudreuil, G. and G. Parsons, "Voice Profile for
Internet Mail - version 2 (VPIMv2)", RFC 3801, June
2004.
[VPIM] ボードルイ、G.、およびG.パーソンズ、「インターネットメールのためにProfileを声に出してください--バージョン2(VPIMv2)」、RFC3801、6月2004日
[Overview] "Multimedia Messaging Services (MMS) Overview",
X.S0016-000
[概要]「マルチメディアメッセージサービス(MMS)概要」、X.S0016-000
[Stage_1] "Multimedia Messaging Services (MMS); Stage 1",
Requirements, October 2002, S.R0064-0.
[ステージ_1] 「マルチメディアメッセージサービス(MMS)」。 1インチ、要件2002年10月、S.R0064-0を上演してください。
[Stage_2] "Multimedia Messaging Service (MMS); Stage 2",
Functional Specification, April 2003, X.S0016-200.
[ステージ_2] 「マルチメディア・メッセージング・サービス(MMS)」。 2インチ、機能的な仕様2003年4月、X.S0016-200を上演してください。
"Multimedia Messaging Service; Media formats and
codecs", TS26.140Release 5.
「マルチメディア・メッセージング・サービス」。 「メディア形式とコーデック」、TS26.140Release5
Gellens Standards Track [Page 29] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[29ページ]。
Author's Address
作者のアドレス
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121
ランドル・Gellensのクアルコムの法人組織の5775モアハウス・Driveサンディエゴ、カリフォルニア 92121
EMail: randy@qualcomm.com
メール: randy@qualcomm.com
Gellens Standards Track [Page 30] RFC 4356 Mapping Between MMS and Internet Mail January 2006
Gellens規格はメール2006年1月にMMSとインターネットの間のRFC4356マッピングを追跡します[30ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Gellens Standards Track [Page 31]
Gellens標準化過程[31ページ]
一覧
スポンサーリンク
