[要約] RFC 4356は、MMSとインターネットメールの間のマッピングに関する標準化ドキュメントです。このRFCの目的は、MMSとインターネットメールの相互運用性を向上させるためのガイドラインを提供することです。
Network Working Group R. Gellens
Request for Comments: 4356 Qualcomm
Category: Standards Track January 2006
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントは、MMS X-MMS-*ヘッダーで使用される情報要素のマッピングと、SMTPおよびインターネットメッセージヘッダーで使用されているものと、配信および処分レポートを含む、これら2つのサービス間でメッセージを交換する方法を指定しています。
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
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]および[MSG-FMT]で定義されているように、メッセージを交換する方法について説明します。これには、メッセージ形式の翻訳、メッセージヘッダー要素、メッセージ配信レポート[DSN-MSG]、およびメッセージ処分レポート[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.
MMSアーキテクチャ[stage_2]および仕様[stage_3]は、インターフェイスをmmxという名前の参照ポイントと呼びます。たとえば、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.
このドキュメントには、インターネットメール[VPIM]の音声プロファイルによって指定された音声メッセージのサポートが含まれています。VPIM仕様により、インターネットメール形式[MSG-FMT]を使用してボイスメールシステム間でボイスメッセージを交換し、[SMTP]を介して輸送できます。したがって、MMS MM3インターフェイスは、MMSシステムとボイスメールシステム間でボイスメッセージを交換する機能をサポートしています。このような使用は、ボイスメディアがユーザーが構成したマルチメディアメッセージの一部であることとは異なることに注意してください。
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.
MM3は、Shortメッセージングサービス（SMS）や外部メールストア（ボイスメールシステムなど）へのアクセスなど、インターネットメール以外の「外部」（非MMS）システムとの相互作用にも使用できることに注意してください。この仕様は、MM3のこれらの他の使用またはサブインターフェイスに対処しません。インターネットメールの相互作業と特にメッセージの交換にのみ関心があります。
All MM3 Stage 2 [Stage_2] functions are supported except for reply charging and sender address hiding.
すべてのMM3ステージ2 [stage_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].
このドキュメントの「必須」、「必須」、「必要はない」、「そうでない」、「そうでない」、「必要はない」、「必要はない」というキーワードは、「RFCSで使用するためのキーワードで要件レベルを示す」で説明されています。「[キーワード]。
--------------------|----------------------------------------------
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.
--------------------|----------------------------------------------
--------------------|----------------------------------------------
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.
--------------------|----------------------------------------------
--------|----------------------------------------------------------
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].
--------|----------------------------------------------------------
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仕様の概要の概要[概要]、MMSステージ1（ステージ）[ステージ_1]、ステージ2（アーキテクチャと抽象メッセージ）[ステージ_2]、および3GPP/3GPP2ステージ3の内容にすでに精通していると想定されています。（プロトコル）[stage_3]ドキュメント。また、読者はインターネットメール、特にRFC 2821 [SMTP]およびRFC 2822 [MSG-FMT]に精通していると想定されています。
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リレー/サーバーと外部サーバー間のインターワーキングを定義します。つまり、情報要素は、[HDR]や標準[SMTP]要素などの標準インターネットメッセージ[MSG-FMT]ヘッダーフィールドを使用して交換されます。
SMTP and Internet mail extensions are used for features such as delivery reports, message expiration, and discovery of server support for optional features.
SMTPおよびインターネットメール拡張機能は、配信レポート、メッセージの有効期限、オプションの機能のサーバーサポートの発見などの機能に使用されます。
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リレー/サーバーは、必要に応じて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リレー/サーバーは、MMに関連付けられた情報要素を使用して、転送プロトコルに必要な制御情報（インターネットメッセージヘッダーフィールドとSMTPエンベロープ値）を定義する必要があります。
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は、標準のインターネットメッセージレポート形式（MultiPart/Report）に変換する必要があります。インターネットメッセージレポートの変換に加えて、MMSリレー/サーバーは配信を生成し、必要に応じて受信したメッセージのレポートMMSを読み取る必要があります。詳細については、セクション2.1.4を参照してください。
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リレー/サーバーは、受信メッセージを受信システム内で使用するMM形式に変換します。
The MMS Relay/Server converts control information received from the Internet mail server into appropriate information elements of an MM.
MMSリレー/サーバーは、インターネットメールサーバーから受信した制御情報を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.
標準のインターネットメッセージレポート形式（MultiPart/Report）メッセージは、必要に応じて配信またはレポートMMSに変換される場合があります。レポートMMSの変換に加えて、このドキュメントに準拠した実装は、必要に応じて受信したインターネットメッセージの標準的なインターネットメッセージ配信と処分レポートを生成する必要があります。詳細については、セクション2.1.4を参照してください。
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]パラメーター、[MSG-FMT]ヘッダー、および[DSN-MSG]フィールドの間のマッピングを以下の表1にまとめ、後続のセクションで詳しく説明します。「MMSヘッダー」は[OMA-MMS]からのものです。マッピングする必要がある情報要素のみがリストされていることに注意してください。[MSG-FMT]ここにリストされていないヘッダーは、変更されていない渡される必要があります。
=================|=================|================|==============
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 |
_________________|_________________|________________|______________
=================|=================|================|==============
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:
_________________|_________________|________________|______________
=================|=================|================|==============
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>
=================|=================|================|==============
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機能ではないため、「感度」を含むメッセージはすべてMMSシステムに送信されないでください。
Note 2: [VPIM] specifies how conforming messages are identified.
注2：[VPIM]は、適合メッセージの識別方法を指定します。
3GPP MMS Version
3GPP MMSバージョン
The 'X-Mms-3GPP-MMS-Version:' header, if present, SHOULD be removed.
'x-mms-3gpp-mms-version：'ヘッダーは、存在する場合は削除する必要があります。
Message Type (of PDU)
メッセージタイプ（PDUの）
The 'X-Mms-Message-Type:' header, if present, SHOULD be removed.
'x-mms-message-type：'ヘッダーは、存在する場合は削除する必要があります。
Transaction ID
トランザクションID
The 'X-Mms-Transaction-Id:' header, if present, SHOULD be removed.
'x-mms-transaction-id：'ヘッダーは、存在する場合は削除する必要があります。
Message ID
メッセージID
The 'Message-Id:' header MUST be retained. If not present, it MUST be created, with a unique value, per [Msg-Fmt].
'message-id：'ヘッダーは保持する必要があります。存在しない場合は、[MSG-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-Message-ID：」ヘッダーを保持したい場合があります。このようなシステムは、「X-」から始まるヘッダーが、インターネットMTAを介したトランジット中に削除される可能性があることに注意する必要があります。
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:;'.
各受信者のアドレスは、[SMTP]エンベロープでRCPTとして送信する必要があります。開示されたすべての受信者は、「to」または 'cc：'ヘッダーにも表示される必要があります。少なくとも1つは「 '、'、 'cc：'、または 'bcc：'ヘッダーが存在する必要があります。存在しない場合、「to」ヘッダーを作成する必要があります。たとえば、「To：unisclosed-Recipients：;」など、名前が人間の読者に示される空のグループ構文を使用してください。
The 'To:' header SHOULD NOT appear more than once. The 'Cc:' header SHOULD NOT appear more than once.
「to：」ヘッダーは複数回表示しないでください。'cc：'ヘッダーは複数回表示してはなりません。
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].
現在のインターネットメッセージ形式では、ヘッダーには7ビットのUS-ASCII文字のみが存在する必要があります。アドレスドメイン内の非7ビット文字は、[IDN]でエンコードする必要があります。アドレスのローカル部分に7ビット以外の文字がある場合、メッセージを拒否する必要があります。ヘッダーの他の場所では7ビット以外の文字は、[HDR-ENC]に従ってエンコードする必要があります。
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番号を使用しないでください。
Sender address
送信者アドレス
The address of the message sender SHOULD appear in the 'From:' header.
メッセージ送信者のアドレスは、 '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.
すべてのユーザー生成メッセージのメッセージ送信者のアドレス（ 'x-mms-message-class：personal'）は、[smtp]エンベロープで値からのメールとして送信する必要があります。
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：'ヘッダーのアドレスは、完全に資格のあるドメインの形である必要があります。資格のないe.164番号を使用しないでください。
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.
メールループのリスクがあるため、すべての自動化されたMMS（ 'x-mms-message-class：auto'など）について、メールがnull（ "<>"）に設定されることが重要です。値からのメールは、自動化されたすべてのメッセージに対してnullに設定する必要があります。これには、レポート、「オフィス外」の返信などが含まれます。
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ビットのUS-ASCII文字のみが存在する必要があります。アドレスドメイン内の非7ビット文字は、[IDN]でエンコードする必要があります。アドレスのローカル部分に7ビット以外の文字がある場合、メッセージを拒否する必要があります。ヘッダーの他の場所では7ビット以外の文字は、[HDR-ENC]に従ってエンコードする必要があります。[SMTP]拡張機能を定義して、エンコードされていない8ビット文字の送信を許可することが可能であることに注意してくださいが、そのような拡張[HDR-ENC]を使用する必要があります。
The sender address MUST obey the length restrictions of [SMTP].
送信者アドレスは、[SMTP]の長さの制限に従う必要があります。
Content type
コンテンツタイプ
The 'Content-Type:' header SHOULD be preserved.
「コンテンツタイプ：」ヘッダーは保存する必要があります。
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-message-class：'ヘッダーは、メッセージのソースに関する情報を提供するために保持される場合があります。「優先順位：バルク」ヘッダーは、class = autoまたはclass = Advertisement用に挿入できます。上記の「送信者アドレス」を参照してください。（class = personal and class =情報は特別な取り扱いを必要としません。）
Time of Expiry
有効期限の時間
The 'X-Mms-Expiry:' header, if present, SHOULD be removed.
'x-mms-expiry：'ヘッダーは、存在する場合は削除する必要があります。
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 "で指定されているように、「r」のバイモードを使用して配信バイエクステンションを使用して、[smtp]エンベロープに送信する必要があります。
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]配信バイエクステンションは、有効期限まで残っていることに注意してください。各サーバーは、メッセージを所有している時間だけで値を減少させます。'x-mms-expiry：'ヘッダーには、メッセージが有効期限が切れると見なされる絶対時間、またはメッセージが期限切れと見なされるまで相対的な時間を含めることができます。
Earliest delivery time
最も早い配達時間
The 'X-Mms-Delivery-Time:' header, if present, SHOULD be removed.
'x-mms-delivery-time：'ヘッダーは、存在する場合は削除する必要があります。
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.
[DSN-SMTP]で指定されたDSN拡張子を使用して「成功」または「なし」の通知を要求するDSN拡張機能を使用して、配信ステータス通知（DSNS）の要求は[SMTP]エンベロープに送信する必要があります（ 'x-の値に応じてmms-delivery-report 'ヘッダー）。Notify拡張子を使用する場合、変更されていない受信者アドレスをORCPT値として送信する必要があります。
The 'X-Mms-Delivery-Report:' header, if present, SHOULD be removed.
'x-mms-delivery-report：'ヘッダーは、存在する場合は削除する必要があります。
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.
メッセージ送信者の重要性値（「優先度」とも呼ばれますが、これはサービスクラスの値と混同される可能性があります）は、「重要性」というヘッダーを使用して送信する必要があります。
Suggested mappings are shown in Table 2:
提案されたマッピングを表2に示します。
---------------------------|------------------
'X-Mms-Priority: High' |'Importance: High'
---------------------------|------------------
'X-Mms-Priority: Normal' |[omit]
---------------------------|------------------
'X-Mms-Priority: Low' |'Importance: Low'
---------------------------|------------------
Normal importance messages should omit the 'Importance:' header.
通常の重要性メッセージは、「重要性：」ヘッダーを省略する必要があります。
The 'X-Mms-Priority:' header, if present, SHOULD be removed.
'x-mms-priority：'ヘッダーは、存在する場合は削除する必要があります。
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.
'x-mms-sender-visibility：' 'hide'の値を持つヘッダーを含むメッセージを拒否する必要があります。
The 'X-Mms-Sender-Visibility:' header, if present, SHOULD be removed.
'x-mms-sender-visibility：'ヘッダーは、存在する場合は削除する必要があります。
Read reply request
返信リクエストを読んでください
A request for a read reply SHOULD be transmitted using a 'Disposition-Notification-To:' header as specified in [MDN].
読み取り返信のリクエストは、[MDN]で指定されている「気質 - notification：」ヘッダーを使用して送信する必要があります。
The 'X-Mms-Read-Reply:' header, if present, SHOULD be removed.
'x-mms-read-reply：'ヘッダーは、存在する場合は削除する必要があります。
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.
返信充電許可と受け入れは、ユーザーエージェントとサーバーの両方のサポートを必要とする複雑な問題です。誤って適用された返信充電は、誤った請求を引き起こす可能性があります。セキュリティの問題が適切に対処されるまで、このインターフェイスを使用する場合、返信充電を尊重しないでください。
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-reply-charging：'、 'x-mms-reply-charging-deadline：'、 'x-mms-reply-charging-size：'、および 'x-mms-reply-charging-id：'ヘッダーは削除される場合があります。返信充電の使用要求を含むメッセージ（ 'x-mms-reply-charging-id：'および 'x-mms-reply-charging：eccepted'または 'x-mms-reply-charging：eccupted（textのみ）'ヘッダー）拒否されるべきです。
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.
「件名：」ヘッダーは保存する必要があります。現在のインターネットメッセージ形式では、7ビットのUS-ASCII文字のみが存在する必要があります。他の文字は[HDR-ENC]に従ってエンコードする必要があります。エンコードされていない8ビット文字の送信を可能にする[SMTP]拡張機能を定義する可能性があるが、そのような拡張機能がない場合は、[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人以上の新しい受信者にresすることがあります。既存のヘッダーの上部に新しい「resり」ヘッダーが追加されるたびに、複数回resしている可能性があります。したがって、複数のシリーズの「Resent-」ヘッダーが存在する場合、オリジナルシリーズが最後です。最新のものは最初です。
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-forward-counter：'ヘッダーは、存在する場合は削除する必要があります。「resant-count：」ヘッダーはお勧めしません。ループ制御は通常、「受信」ヘッダーをカウントすることによって行われます。ヘッダーは「resent」ヘッダーよりも一般的です。
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-previvisly-sent-by：」には、1つ以上のアドレスが続く数字が含まれます。'x-mms-prevevisally-sent-date-time：' '' on number x x x x exlow date timeが含まれます。両方のヘッダーでは、メッセージの元の提出に対応するエントリに「0」という数字が使用され、その後の各リセンデントに対してより高い値が使用されます。最終的な（最新の）控えめな情報は、「from」と 'date：'ヘッダーです。「X-MMS-Forward-counter：」もあります。これは、メッセージが何回resしているかを示しています。
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:
「x-mms-previally-sent-by： '、'、 'x-mms-previally-sent-date-time：'、および 'x-mms-forward-counter：'ヘッダーは、存在する場合、削除する必要があります。それらに含まれる情報は、次のように[MSG-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-prevevisally-sent-and time：' '"0"で始まる値を使用する必要があるヘッダーは、「日付」を作成するために使用する必要があります。日付時間[MSG-FMT]。'x-mms-previsally-sent-by：'ヘッダーは、「0」から始まる値を使用して、 'from：'ヘッダーを作成する必要があります。
A 'To:' header SHOULD be created using list syntax with a value of "unrecoverable-recipients" and no mailboxes.
'to：' 'ヘッダーは、「recoverable-recipients」とメールボックスの値を持つリスト構文を使用して作成する必要があります。
A 'Message-ID:' header SHOULD be created.
'message-id：'ヘッダーを作成する必要があります。
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.
「1」またはより大きな値から始まる値のヘッダーは、「resent-date：」ヘッダーにマッピングされます。「1」またはより大きな値から始まる値が「res by-by：」ヘッダーにマッピングされる「x-mms-prevevisally-sent-by：」ヘッダー。
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：'、 'date：'、および 'message-id：'ヘッダーは「resent-from：」、 'resent-to：'、 'resent-date：'、and 'にマッピングされます。resent-message-id：「resent-*」ヘッダーの最上位ブロックのヘッダー。
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>
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>
'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からインターネットメールにゲートウェイされている場合、[smtp]に従って「receive： 'receive：」ヘッダーを追加する必要があります。「with」節は「mms」を指定する必要があります。
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.
「受信した」ヘッダーの数が局所的に定義された最大値を超えている場合、メッセージは拒否される場合があります。
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.
メッセージコンテンツはメッセージ本文に表示されます。インターネットメッセージ形式では、ラインエンディングをus-ascii cr lfオクテットとしてエンコードする必要があることに注意してください。したがって、このプロパティを持っていないチャーセットエンコーディングは、テキスト/*ボディパーツでは使用できません。（それらは他の体の部分で使用される場合がありますが、それらが適切にエンコードされている場合、またはバイナリ伝送が交渉された場合、たとえば[バイナリ]。）特に、MMSはUTF-16を許可しますが、インターネットメッセージ形式はそうではありません。UTF-16エンコーディングは、インターネットメッセージ形式/プロトコルでの使用に適したUTF-8または別のcharSetおよびエンコードに翻訳する必要があります。
3GPP MMS Version
3GPP MMSバージョン
An 'X-Mms-3GPP-MMS-Version:' header SHOULD be added.
'x-mms-3gpp-mms-version：'ヘッダーを追加する必要があります。
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-message-type：'ヘッダーは、特定の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-Transaction-ID：'ヘッダーは、特定のMMSインターフェイス（MM1、MM4など）に従って使用する必要があります。
Message ID
メッセージID
The 'Message-Id:' header MUST be retained. If not present, it MUST be created, with a unique value.
'message-id：'ヘッダーは保持する必要があります。存在しない場合は、一意の価値で作成する必要があります。
Recipient(s) address
受取人住所
'To:' and 'Cc:' headers MUST be retained.
'to：' 'and' cc： 'ヘッダーは保持する必要があります。
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）に含まれる各受信者は、メッセージの受信者と見なされる必要があります。[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.
完全な「コンテンツタイプ：」ヘッダー（任意のパラメーターを含む）を保存する必要があります。
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-message-class：個人的な'ヘッダーは、null以外のリターンパス（SMTPエンベロープの値からのメール）を備えたすべての受信メッセージに対して作成できます。'x-mms-message-class：auto'ヘッダーは、nullリターンパスを備えたメッセージ用に作成できます。
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].
[X-MMS-Expiry： 'ヘッダーは、[配信]で指定されているように、「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」の場合、[配信]ごとに「リレー」DSNを発行する必要があります。
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-delivery-report：' [dsn-smtp]で指定されているDSN拡張子を使用して、「成功」または「なし」の配信ステータス通知を要求するメッセージのヘッダーを作成する必要があります。メッセージヘッダーのみを返し、MMSヘッダーにマッピングすることができないため、無視する必要があるなど、「遅延」通知または非デフォルトアクションの要求は無視する必要があります。
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-priority：'ヘッダーを使用しました。その結果、一部のクライアントは両方を生成します。
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-priority：'または 'caltual：'ヘッダーは、存在する場合は、 'x-mms-priolity：' headerに置き換える必要があります。両方のヘッダーが存在する場合、「重要：」を使用する必要があります。提案されたマッピングを表3に示します。
-------------------------------|----------------------
'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'
-------------------------------|----------------------
Normal importance messages SHOULD omit the 'X-Mms-Priority:' header.
通常の重要性メッセージは、「X-MMS-Priority：」ヘッダーを省略する必要があります。
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.
[MDN]で指定されているヘッダーに含まれる読み取り返信のリクエストは、 'x-mms-read-reply：' headerに置き換える必要があります。
Subject
主題
The 'Subject:' header MUST be preserved.
「件名：」ヘッダーは保存する必要があります。
Resending
復活
Mapping from 'Resent-' and other [Msg-Fmt] headers to 'X-Mms-Previously-Sent-' headers SHOULD be done as follows:
「resent」およびその他の[msg-fmt]ヘッダーから「x-mms-previally-sent-」ヘッダーへのマッピングは、次のように行う必要があります。
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-prevevisally-sent-by：'ヘッダーにマッピングされます。最上位の 'resent-from：'ヘッダーは、from： 'ヘッダーにマッピングされます。後続の各「resed-from：」ヘッダーの値は、次の主要な値を持つ 'x-mms-prevevisally-sent-by：'ヘッダーにマッピングされます。
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.
オリジナルの「日付：」ヘッダーは、「X-MMS-PREVEVINALY-SENT-TIME： 'ヘッダーにマッピングされます。値は、日付時間構文[MSG-FMT]からHTTP-Date Syntax [HTTP]にも変換されていることに注意してください。最上位の 'resent-date：'ヘッダーは「日付：」ヘッダーにマッピングされます。後続の各 '日付の値：'ヘッダーは、次のより大きな主要値を持つ 'x-mms-prevevisally-sent-date-time：'ヘッダーにマッピングされます。
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つ以上の 'Resent-Message-ID：' 'ヘッダーが存在する場合、最上位のヘッダーは' 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-forward-counter：'ヘッダーは、「resent」ヘッダーが「x-mms-prevevily-sent-」ヘッダーにマッピングされているときに作成する必要があります。その価値は、マッピング前に存在していた「resent-」ブロックの数でなければなりません。
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>
Is resent by Colonel Corn to L. Eva Message:
コーン大佐によってL. evaメッセージにresしています：
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> L. Eva then resends to her MMS device:
resent-date：Fri、2005年4月1日16:02:03 -0800 RESENT-FROM：COLLEL CONREL <GCORN@EXAMPLE.MIL> RESENT-TO：L。EVAメッセージ<Lem@example.org> Resent-Message-ID：<msg234@mail.example.mil>日付：金曜日、2005年4月1日14:02:03 -0800 From：一般障害<mfail@example.mil>へ：大佐コーン<gcorn@example.mil>メッセージ-id：<<<<msg123@mail.example.mil> L. evaは彼女の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>
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>
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.
元の「from：」と「date： '値は' x-mms-previally-sent-by： 'および' x-mms-prevevisally-sent-date-time： 'ヘッダーに移動したことに注意してください。「0」値。最初の「resent-from」と「resent-date：」値は、「x-mms-prevevisally-sent-」ヘッダーの2番目のセットに移動され、主要な「1」値がありました。「resent」ヘッダーの3番目のセットは、「日付」、 'へ：'、および「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].
また、日付と時刻の形式は「日付：」 / 'resent-date：'と「x-mms-prevevisallive-sent-date-time：」の間で異なることに注意してください。-date [http]日付時間[msg-fmt]の代わりに。
'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.
メッセージを処理する各システムは、[smtp]に従って「受信： 'ヘッダーを追加する必要があります。「受信した」ヘッダーの数が局所的に定義された最大値を超えている場合、メッセージは拒否される場合があります。
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.
'sensitivity：' header field（value = "personal"または "private"）[vpim]は、メッセージのコンテンツを元の受信者リストに送信したいという音声メッセージのオリジネーターの欲求を示しています。メッセージングシステムまたは実際のメッセージ受信者のいずれか。感度はMMS機能ではないため、「感度：」ヘッダーを含むメッセージはMMSシステムに送信してはなりません。関連する負の配信ステータスレポートには、[VPIM]（「その他または未定義のプロトコルステータス」）で指定されている拡張ステータスコード[RESP] 5.6.0を含める必要があります。
Content
コンテンツ
The message content appears in the message body.
メッセージコンテンツはメッセージ本文に表示されます。
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].
インターネットメッセージシステム[Report-FMT]で指定されているように、配信および処分レポートのためにマルチパート/レポートMIMEタイプを使用します。この形式は、2部または3部構成のMIMEメッセージです。1つの部分は、簡単な形式で報告されているイベントを説明する構造化された形式です。特定のレポートには、[Report-FMT]に構築された形式があります。配信レポートは[DSN-MSG]で指定されています。読み取りレポートを含むメッセージ処分レポートは、[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-MSG]を生成する必要があります。
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 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レポートから配信または処分レポートを作成する場合、MMSレポートを解析して、報告されたイベントと時間、ステータス、および参照（元の）メッセージのヘッダーを決定する必要があります。これらの要素は、一度決定されると、配信または処分レポートのサブパートを入力するために使用されます。最初のサブパートはタイプテキスト/プレーンで、イベントの人間が読みやすい説明が含まれています。このテキストには、MMSレポートに基づいてレポートが統合されたという声明が含まれる場合があります。2番目のサブパートは、レポート/配信ステータス（配信レポート用）またはレポート/処分 - 解釈（処分レポート用）のタイプです。この2番目の部分には、イベントの構造化されたアイテム化が含まれています。オプションの3番目のサブパートはタイプメッセージ/RFC822で、参照（元の）メッセージのヘッダーとオプションの本文が含まれています。[DSN-MSG]ごとに、「DSN-Gateway： '' field in Delivery Reportsが作成する必要があることに注意してください。
Below, Table 4 maps information elements from MMS delivery reports to the format specified in [DSN-Msg].
以下に、表4は、MMS配信レポートの情報要素を[DSN-MSG]で指定した形式にマッピングします。
======================|============|===================================
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.
----------------------|------------|-----------------------------------
======================|============|===================================
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).
----------------------|------------|-----------------------------------
When an MMS Relay/Server generates a [DSN-Msg] in response to a message received using [SMTP] on MM3:
MMSリレー/サーバーがMM3で[SMTP]を使用して受信したメッセージに応じて[DSN-MSG]を生成する場合：
* Top-level header field 'To:' SHOULD be the [SMTP] return-path of the message whose status is being reported.
* トップレベルのヘッダーフィールド：「ステータスが報告されているメッセージの[SMTP]リターンパスである必要があります。
* Top-level header field 'From:' SHOULD be the address of the recipient that the delivery-report concerns.
* ： 'からのトップレベルのヘッダーフィールド' 'は、配信レポートが懸念している受信者の住所である必要があります。
* 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-MSG]の最初の部分には、MM1配信レポート用に生成されたMMステータステキストフィールドを含める必要があります。
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.
以下に、[DSN-MSG]で指定されている配信レポートの情報要素をMMS配信レポートの形式にマッピングします。複数の受信者を報告する単一のDSNは、いくつかの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.
-------------------|------------------|--------------------------------
===================|==================|================================
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).
===================|==================|================================
Below, Table 6 maps information elements from MMS read reports to the format specified in [MDN].
以下に、MMSの情報要素をマップして、[MDN]で指定された形式へのレポートを読み取ります。
======================|============|===================================
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 | |
======================|============|===================================
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).
======================|============|===================================
When an MMS Relay/Server generates an [MDN] in response to a message received using [SMTP] on MM3:
MMSリレー/サーバーがMM3で[SMTP]を使用して受信したメッセージに応じて[MDN]を生成する場合：
* Top-level header field 'To:' SHOULD be the value of the 'Disposition-Notification-To:' header field of the message whose disposition is being reported.
* 「トップレベルのヘッダーフィールド」は次のとおりです。
* Top-level header field 'From:' SHOULD be the address of the recipient that the read report concerns.
* ： 'からのトップレベルのヘッダーフィールド'は、読み取りレポートが懸念している受信者の住所である必要があります。
Below, Table 7 maps information elements from a disposition report as specified in [MDN] to the format of an MMS read report.
以下に、表7は、[MDN]で指定されている処分レポートからMMS読み取りレポートの形式まで情報要素をマッピングします。
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).
===================|==================|================================
2.1.5. Message Delivery
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リレー/サーバーが[SMTP]を使用してメッセージを受信し、配信レポートが要求されると、MMSリレー/サーバーは、MMSユーザーエージェントに送信されたときに配信されるメッセージを検討する場合があります。
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と電子メールの間でマッピング中の署名によって）。[MIME-SEC-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機能には、返信充電や送信者アドレスの隠れなど、本質的に他のリスクが含まれています。これらのメカニズムのサポートは、このドキュメントには含まれていません。
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は、「MMS」を「MMS」の1つとして、「メールパラメーター」レジストリの下に追加しました。説明は「マルチメディアメッセージングサービス」です。参照はこのドキュメントへのものです。
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.
多くの人々がこの文書、特にGreg Vaudreuilを含むIETFレモネードワーキンググループのメンバーに貢献しました。ジョン・クレンシンは非常に徹底的で有益なレビューを行いました。グレッグ・ホワイトは多数のnitを捕まえた。テッド・ハーディはとても役に立ちました。Alexey MelnikovとChris Newmanは、非常に便利で詳細なコメントを送信しました。
[DSN-Msg] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN-MSG] Moore、K。およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 3464、2003年1月。
[DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[DSN-SMTP] Moore、K。、「Simple Mail Transfer Protocol（SMTP）Service Extension for Delivery Status通知（DSNS）」、RFC 3461、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] Moore、K。、「Mime（多目的インターネットメール拡張）パート3：ASSASCII以外のテキスト用のメッセージヘッダー拡張機能」、RFC 2047、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-HTTP/1.1」、RFC 2616、1999年6月。
[IDN] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[IDN] Faltstrom、P.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MDN] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[MDN] Hansen、T。およびG. Vaudreuil、「メッセージ処分通知」、RFC 3798、2004年5月。
[Msg-Fmt] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[MSG-FMT] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[Report-Fmt] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[Report-FMT] Vaudreuil、G。、「メールシステム管理メッセージのレポートのマルチパート/レポートコンテンツタイプ」、RFC 3462、2003年1月。
[RESP] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[RESP] Vaudreuil、G。、「拡張されたメールシステムステータスコード」、RFC 3463、2003年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[OMA] OMA specifications are available at the OMA web site <http://www.openmobilealliance.org>.
[OMA] OMA仕様は、OMA Webサイト<http://www.openmobilealliance.org>で入手できます。
[OMA-MMS] OMA-WAP-MMS-ENC-V1_2-20040323-C
[OMA-MMS] OMA-WAP-MMS-ENC-V1_2-20040323-C
[3GPP2] 3GPP2 specifications are available at the 3GPP2 (Third Generation Partnership Project 2) web site <http://www.3gpp2.org>.
[3GPP2] 3GPP2仕様は、3GPP2（第3世代パートナーシッププロジェクト2）Webサイト<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（第3世代パートナーシッププロジェクト）Webサイトで入手できます<http://www.3gpp.org>
[Stage_3] "MMS MM1 Stage 3 using OMA/WAP", X.S0016-310
[stage_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」、TS 23.140リリース5。
[BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[Binary] Vaudreuil、G。、「大型およびバイナリMIMEメッセージの送信用SMTPサービス拡張式」、RFC 3030、2000年12月。
[Deliver-By] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.
[配信]ニューマン、D。、「SMTP Service Extensionによる配信」、RFC 2852、2000年6月。
[Hdrs] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
[HDRS] Palme、J。、「Common Internet Message Headers」、RFC 2076、1997年2月。
[Mime-Sec-gw] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480, January 1999.
[MIME-SEC-GW] Freed、N。、「ゲートウェイとMIMEセキュリティマルチパート」、RFC 2480、1999年1月。
[PGP] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[PGP] Elkins、M.、Del Torto、D.、Levien、R。、およびT. Roessler、「Mime Security with OpenPGP」、RFC 3156、2001年8月。
[SMIME] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[SMIME] Ramsdell、B。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[Submission] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[提出] Gellens、R。およびJ. Klensin、「Message Submission」、RFC 2476、1998年12月。
[VPIM] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[VPIM] Vaudreuil、G。およびG. Parsons、「インターネットメールの音声プロファイル - バージョン2（VPIMV2）」、RFC 3801、2004年6月。
[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.
[Stage_1] "マルチメディアメッセージングサービス（MMS）;ステージ1"、要件、2002年10月、S.R0064-0。
[Stage_2] "Multimedia Messaging Service (MMS); Stage 2", Functional Specification, April 2003, X.S0016-200.
[Stage_2] "マルチメディアメッセージングサービス（MMS）;ステージ2"、機能仕様、2003年4月、X.S0016-200。
"Multimedia Messaging Service; Media formats and codecs", TS26.140Release 5.
「マルチメディアメッセージングサービス、メディアフォーマットとコーデック」、TS26.140RELEASE 5。
Author's Address
著者の連絡先
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121
ランドールゲレンズクアルコムIncorporated 5775モアハウスドライブサンディエゴ、カリフォルニア92121
EMail: randy@qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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エディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。