diff options
Diffstat (limited to 'doc/rfc/rfc4356.txt')
| -rw-r--r-- | doc/rfc/rfc4356.txt | 1739 |
1 files changed, 1739 insertions, 0 deletions
diff --git a/doc/rfc/rfc4356.txt b/doc/rfc/rfc4356.txt new file mode 100644 index 0000000..3cb1fa3 --- /dev/null +++ b/doc/rfc/rfc4356.txt @@ -0,0 +1,1739 @@ + + + + + + +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 + +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. + +Copyright Notice + + 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. + + 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. + + 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. + + + + + + + + + + + + + + + + +Gellens Standards Track [Page 1] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + +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. Introduction + +1.1. Scope + + 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]. + + 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. + + 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. + + + +Gellens Standards Track [Page 2] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + 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. + + All MM3 Stage 2 [Stage_2] functions are supported except for reply + charging and sender address hiding. + +1.2. Conventions Used in This Document + + 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]. + +1.3. Definitions + + --------------------|---------------------------------------------- + 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. + --------------------|---------------------------------------------- + + + + +Gellens Standards Track [Page 3] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + --------------------|---------------------------------------------- + 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. + --------------------|---------------------------------------------- + +1.4. Abbreviations + + --------|---------------------------------------------------------- + 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]. + --------|---------------------------------------------------------- + +1.5. Assumptions + + 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]. + +2. Mapping Between MMS and Internet Mail + + 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 and Internet mail extensions are used for features such as + delivery reports, message expiration, and discovery of server support + for optional features. + + + + + + +Gellens Standards Track [Page 4] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + +2.1. Mapping Specification + +2.1.1. MMS to Internet Mail + + 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]. + + 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. + + Section 2.1.3 lists the mappings between X-Mms-* headers and Internet + message header fields and SMTP values. + + 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. + +2.1.2. Internet Mail to 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. + + The MMS Relay/Server converts control information received from the + Internet mail server into appropriate information elements of an MM. + + Section 2.1.3 lists the mappings between X-Mms-* headers and Internet + message header fields and SMTP values. + + 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. + + + + + + + + + + + +Gellens Standards Track [Page 5] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + +2.1.3. MMS Information Element Mappings + + 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. + +2.1.3.1. Table 1: Information Element Mappings + + =================|=================|================|============== + 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 | + _________________|_________________|________________|______________ + + + + + + + +Gellens Standards Track [Page 6] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + =================|=================|================|============== + 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: + _________________|_________________|________________|______________ + + + +Gellens Standards Track [Page 7] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + =================|=================|================|============== + 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. + + Note 2: [VPIM] specifies how conforming messages are identified. + +2.1.3.2. Conversion of Messages from MMS to Internet Format + + 3GPP MMS Version + + The 'X-Mms-3GPP-MMS-Version:' header, if present, SHOULD be removed. + + Message Type (of PDU) + + The 'X-Mms-Message-Type:' header, if present, SHOULD be removed. + + + + +Gellens Standards Track [Page 8] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + Transaction ID + + The 'X-Mms-Transaction-Id:' header, if present, SHOULD be removed. + + Message ID + + The 'Message-Id:' header MUST be retained. If not present, it MUST + be created, with a unique value, per [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. + + 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:;'. + + The 'To:' header SHOULD NOT appear more than once. The 'Cc:' header + SHOULD NOT appear more than once. + + Each recipient address MUST obey the length restrictions per [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]. + + 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. + + 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. + + + + + +Gellens Standards Track [Page 9] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + Sender address + + The address of the message sender SHOULD appear in the 'From:' + header. + + 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. + + 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. + + The address(es) in the 'From:' header SHOULD be in the form of + fully-qualified domains. Unqualified E.164 numbers SHOULD NOT be + used. + + 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. + + 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. + + The sender address MUST obey the length restrictions of [SMTP]. + + Content type + + The 'Content-Type:' header SHOULD be preserved. + + + + + + + + + + +Gellens Standards Track [Page 10] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + 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.) + + Time of Expiry + + The 'X-Mms-Expiry:' header, if present, SHOULD be removed. + + 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]. + + 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. + + Earliest delivery time + + The 'X-Mms-Delivery-Time:' header, if present, SHOULD be removed. + + 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. + + The 'X-Mms-Delivery-Report:' header, if present, SHOULD be removed. + + 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: + + + + +Gellens Standards Track [Page 11] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + +2.1.3.2.1. Table 2: Importance Mappings (MMS to Internet Message) + + ---------------------------|------------------ + '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. + + 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. + + The 'X-Mms-Sender-Visibility:' header, if present, SHOULD be removed. + + Read reply request + + A request for a read reply SHOULD be transmitted using a + 'Disposition-Notification-To:' header as specified in [MDN]. + + The 'X-Mms-Read-Reply:' header, if present, SHOULD be removed. + + 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. + + + + + + + +Gellens Standards Track [Page 12] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + 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. + + 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. + + 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. + + 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. + + 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: + + 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. + + + + +Gellens Standards Track [Page 13] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + A 'To:' header SHOULD be created using list syntax with a value of + "unrecoverable-recipients" and no mailboxes. + + A 'Message-ID:' header SHOULD be created. + + 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. + + 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. + + Example: + + The MMS message: + + 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". + + + + + +Gellens Standards Track [Page 14] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + 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]. + + 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. + +2.1.3.3. Conversion of Messages from Internet to MMS Format + + 3GPP MMS Version + + An 'X-Mms-3GPP-MMS-Version:' header SHOULD be added. + + Message Type (of PDU) + + An 'X-Mms-Message-Type:' header SHOULD be used in accordance with the + specific MMS interface (e.g., MM1, MM4). + + Transaction ID + + An 'X-Mms-Transaction-Id:' header SHOULD be used in accordance with + the specific MMS interface (e.g., MM1, MM4). + + Message 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. + + + + + +Gellens Standards Track [Page 15] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + 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. + + Sender address + + The 'From:' header MUST be retained. + + 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. + + 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]. + + 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. + + 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. + + + + + + + + + + +Gellens Standards Track [Page 16] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + 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. + + 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: + +2.1.3.3.1. Table 3: Priority Mappings (Internet Message to 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' + -------------------------------|---------------------- + + Normal importance messages SHOULD omit the 'X-Mms-Priority:' header. + + 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. + + Subject + + The 'Subject:' header MUST be preserved. + + + +Gellens Standards Track [Page 17] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + Resending + + Mapping from 'Resent-' and other [Msg-Fmt] headers to 'X-Mms- + Previously-Sent-' headers SHOULD be done as follows: + + 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. + + 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. + + 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. + + 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. + + 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: + + 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> + + + + +Gellens Standards Track [Page 18] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + L. Eva then resends to her MMS device: + + 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: + + 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. + + 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]. + + '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. + + + + + +Gellens Standards Track [Page 19] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + 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. + + Content + + The message content appears in the message body. + +2.1.4. Report Generation and Conversion + + 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]. + + 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. + + 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. + + 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 + + + +Gellens Standards Track [Page 20] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + 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. + +2.1.4.1. Delivery Report Mapping from MMS to Internet Message + + Below, Table 4 maps information elements from MMS delivery reports to + the format specified in [DSN-Msg]. + +2.1.4.1.1. Table 4: Delivery Report Mappings (MMS to Internet Message) + +======================|============|=================================== +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. +----------------------|------------|----------------------------------- + + + + + + + + + + + + + + + + + +Gellens Standards Track [Page 21] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + +======================|============|=================================== +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: + + * Top-level header field 'To:' SHOULD be the [SMTP] return-path of + the message whose status is being reported. + + * 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. + + + + +Gellens Standards Track [Page 22] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + +2.1.4.2 Delivery Report Mapping from Internet Message to 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. + +2.1.4.2.1. Table 5: Delivery Report Mappings (Internet Message to 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. +-------------------|------------------|-------------------------------- + + + + + + + + + + + + + + + + +Gellens Standards Track [Page 23] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + +===================|==================|================================ +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). +===================|==================|================================ + +2.1.4.3. Read Report Mapping from MMS to Internet Message + + Below, Table 6 maps information elements from MMS read reports to the + format specified in [MDN]. + +2.1.4.3.1. Table 6: Read Report Mappings (MMS to Internet Message) + +======================|============|=================================== +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 | | + + + +Gellens Standards Track [Page 24] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + +======================|============|=================================== +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: + + * 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. + +2.1.4.4. Disposition Report Mapping from Internet Message to MMS + + Below, Table 7 maps information elements from a disposition report as + specified in [MDN] to the format of an MMS read report. + + + + + + + + + +Gellens Standards Track [Page 25] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + +2.1.4.4.1. Table 7: Disposition Report Mappings + (Internet Message to 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). +===================|==================|================================ + + + +Gellens Standards Track [Page 26] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + +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. + +3. Security Considerations + + 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. + + 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. + + 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. + +4. IANA Considerations + + 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. + +5. Acknowledgements + + 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. + +6. Normative References + + [DSN-Msg] Moore, K. and G. Vaudreuil, "An Extensible Message + Format for Delivery Status Notifications", RFC 3464, + January 2003. + + + +Gellens Standards Track [Page 27] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + [DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) + Service Extension for Delivery Status Notifications + (DSNs)", RFC 3461, January 2003. + + [Hdr-Enc] Moore, K., "MIME (Multipurpose Internet Mail + Extensions) Part Three: Message Header Extensions for + Non-ASCII Text ", RFC 2047, November 1996. + + [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. + + [IDN] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications + (IDNA)", RFC 3490, March 2003. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [MDN] Hansen, T. and G. Vaudreuil, "Message Disposition + Notification", RFC 3798, May 2004. + + [Msg-Fmt] Resnick, P., "Internet Message Format", RFC 2822, April + 2001. + + [Report-Fmt] Vaudreuil, G., "The Multipart/Report Content Type for + the Reporting of Mail System Administrative Messages", + RFC 3462, January 2003. + + [RESP] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC + 3463, January 2003. + + [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [OMA] OMA specifications are available at the OMA web site + <http://www.openmobilealliance.org>. + + [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>. + + [3GPP] 3GPP specifications are available at the 3GPP (Third + Generation Partnership Project) web site + <http://www.3gpp.org> + + + + +Gellens Standards Track [Page 28] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + + [Stage_3] "MMS MM1 Stage 3 using OMA/WAP", X.S0016-310 + + "MMS MM4 Stage 3 Inter-Carrier Interworking", X.S0016- + 340 + + "Multimedia Messaging Service: Functional description; + Stage 2", TS 23.140 Release 5. + +7. Informative References + + [BINARY] Vaudreuil, G., "SMTP Service Extensions for + Transmission of Large and Binary MIME Messages", RFC + 3030, December 2000. + + [Deliver-By] Newman, D., "Deliver By SMTP Service Extension", RFC + 2852, June 2000. + + [Hdrs] Palme, J., "Common Internet Message Headers", RFC 2076, + February 1997. + + [Mime-Sec-gw] Freed, N., "Gateways and MIME Security Multiparts", RFC + 2480, January 1999. + + [PGP] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, + "MIME Security with OpenPGP", RFC 3156, August 2001. + + [SMIME] Ramsdell, B., "Secure/Multipurpose Internet Mail + Extensions (S/MIME) Version 3.1 Message Specification", + RFC 3851, July 2004. + + [Submission] Gellens, R. and J. Klensin, "Message Submission", RFC + 2476, December 1998. + + [VPIM] Vaudreuil, G. and G. Parsons, "Voice Profile for + Internet Mail - version 2 (VPIMv2)", RFC 3801, June + 2004. + + [Overview] "Multimedia Messaging Services (MMS) Overview", + X.S0016-000 + + [Stage_1] "Multimedia Messaging Services (MMS); Stage 1", + Requirements, October 2002, S.R0064-0. + + [Stage_2] "Multimedia Messaging Service (MMS); Stage 2", + Functional Specification, April 2003, X.S0016-200. + + "Multimedia Messaging Service; Media formats and + codecs", TS26.140Release 5. + + + +Gellens Standards Track [Page 29] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + +Author's Address + + Randall Gellens + QUALCOMM Incorporated + 5775 Morehouse Drive + San Diego, CA 92121 + + EMail: randy@qualcomm.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gellens Standards Track [Page 30] + +RFC 4356 Mapping Between MMS and Internet Mail January 2006 + + +Full Copyright Statement + + 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. + + 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. + + 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. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Gellens Standards Track [Page 31] + |