Internet Draft: Mapping Between MMS and Internet Mail R. Gellens Document: draft-ietf-lemonade-mms-mapping-06.txt Qualcomm Expires: April 2006 October 2005 Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols which 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 which start with "X-Mms-" to carry a variety of user agent and server related information elements. Gellens [Page 1] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 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 [Page 2] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Conventions Used in this Document . . . . . . . . . . . . 3 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 1.5 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 2 Mapping Between MMS and Internet Mail . . . . . . . . . . . . 6 2.1 Mapping Specification . . . . . . . . . . . . . . . . . . 6 2.1.1 MMS to Internet Mail . . . . . . . . . . . . . . . . . 6 2.1.2 Internet Mail to MMS . . . . . . . . . . . . . . . . 7 2.1.3 MMS Information Element Mappings . . . . . . . . . . . 7 2.1.3.1 Table 1: Information Element Mappings . . . . . . 8 2.1.3.2 Conversion of messages from MMS to Internet format 10 2.1.3.2.1 Table 2: Importance Mappings (MMS to Internet 13 2.1.3.3 Conversion of messages from Internet to MMS format 17 2.1.3.3.1 Table 4: Priority Mappings (Internet Message t 19 2.1.4 Report Generation and Conversion . . . . . . . . . . . 22 2.1.4.1 Delivery Report Mapping from MMS to Internet Messa 22 2.1.4.1.1 Table 5: Delivery Report Mappings (MMS to Inte 23 2.1.4.2 Delivery Report Mapping from Internet Message to M 24 2.1.4.2.1 Table 6: Delivery Report Mappings (Internet Me 25 2.1.4.3 Read Report Mapping from MMS to Internet Message 26 2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet 27 2.1.4.4 Disposition Report Mapping from Internet Message t 28 2.1.4.4.1 Table 8: Disposition Report Mappings (Internet 28 2.1.5 Message Delivery . . . . . . . . . . . . . . . . . . 29 3 Security Considerations . . . . . . . . . . . . . . . . . . . 29 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 5 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 6 Normative References . . . . . . . . . . . . . . . . . . . . 30 7 Informative References . . . . . . . . . . . . . . . . . . . . 31 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . 32 Appendix A: Changes Since Last Version . . . . . . . . . . . . 33 Intellectual Property Statement . . . . . . . . . . . . . . . 34 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 34 1 Introduction 1.1 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]. Gellens [Page 3] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 1.2 Scope This document describes how to exchange messages between 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 and message disposition reports ([DSN-Msg] and [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 which 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 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. 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.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 their own Header and Body. The Body |contains information intended for the message |recipient (human or software). --------------------|---------------------------------------------- Gellens [Page 4] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 --------------------|---------------------------------------------- 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 nor in |the Body. While some of it may be copied into |the Content on delivery, envelope information |only exists while the message is in transit, |and contains information used by SMTP 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 --------------------|---------------------------------------------- Gellens [Page 5] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 1.4 Abbreviations --------|---------------------------------------------------------- MSA |Message Submission Agent. A server which accepts messages |from User Agents and processes them; either delivering |them locally or relaying to an MTA. --------|---------------------------------------------------------- MTA |Mail Transfer Agent. A server which 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 and standard [SMTP] elements. SMTP and Internet mail extensions are used for features such as delivery reports, message expiration, discovery of server support for optional features, etc. 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. Gellens [Page 6] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 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 [Page 7] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 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 the table below, and detailed in subsequent sections. The "MMS Headers" are from [OMA-MMS]. Note that only information elements which 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 [Page 8] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 =================|=================|================|============== 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 [Page 9] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 =================|=================|================|============== 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 | | =================|=================|================|============== 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 which 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) Gellens [Page 10] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 The 'X-Mms-Message-Type:' header, if present, SHOULD be removed. 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 which 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 [Page 11] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 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. 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.) Gellens [Page 12] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 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, 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: 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' ---------------------------|------------------ Gellens [Page 13] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 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. Subject The 'Subject:' header MUST be preserved. 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 which would permit transmission of unencoded 8-bit characters, but in the absence of such an extension [Hdr-Enc] MUST be used. Resending Gellens [Page 14] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 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. 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. Gellens [Page 15] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 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 X-Mms-Previously-Sent-Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT X-Mms-Previously-Sent-By: 1, Colonel Corn Date: Fri, 1 Apr 2005 18:02:03 -0800 From: L. Eva Message 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 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 Date: Fri, 1 Apr 2005 06:02:03 +0000 From: General Failure To: Colonel Corn 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". 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]. Gellens [Page 16] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 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.) In particular, MMS allows UTF-16, while Internet message format does not. UTF-16 encoding MUST be translated to UTF-8 or another charset and encoding which 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. 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. Gellens [Page 17] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 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. Earliest delivery time An 'X-Mms-Delivery-Time:' header SHOULD NOT be created. Delivery report request An 'X-Mms-Delivery-Report:' header SHOULD be created for messages which 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. 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. Gellens [Page 18] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 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: 2.1.3.3.1 Table 4: 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. 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 Gellens [Page 19] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 mapped to an 'X-Mms-Previously-Sent-By:' header with the next larger leading value. The original 'Date:' header is mapped to '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 To: Colonel Corn Message-ID: Is resent by Colonel Corn to L. Eva Message: Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800 Resent-From: Colonel Corn Resent-To: L. Eva Message Resent-Message-ID: Date: Fri, 1 Apr 2005 14:02:03 -0800 From: General Failure To: Colonel Corn Message-ID: L. Eva then resends to her MMS device: Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800 Resent-From: L. Eva Message 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 Gellens [Page 20] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 Resent-To: L. Eva Message Resent-Message-ID: Date: Fri, 1 Apr 2005 14:02:03 -0800 From: General Failure To: Colonel Corn Message-ID: 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 X-Mms-Previously-Sent-Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT X-Mms-Previously-Sent-By: 1, Colonel Corn Date: Fri, 1 Apr 2005 18:02:03 -0800 From: L. Eva Message 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. 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 which contain a 'Sensitivity:' header MUST NOT be sent to an MMS system. The associated negative delivery status report MUST include the extended Gellens [Page 21] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 status code [RESP] 5.6.0 as specified in [VPIM] ("Other or undefined protocol status") indicating that privacy could not be assured. 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 which 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 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. Gellens [Page 22] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 2.1.4.1 Delivery Report Mapping from MMS to Internet Message The following table maps information elements from MMS delivery reports to the format specified in [DSN-Msg]. 2.1.4.1.1 Table 5: 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 [Page 23] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 ======================|============|=================================== 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 [Page 24] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 2.1.4.2 Delivery Report Mapping from Internet Message to MMS The following table 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 which reports multiple recipients will result in several MMS delivery reports. 2.1.4.2.1 Table 6: 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. ===================|==================|================================ Gellens [Page 25] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 ===================|==================|================================ Information Element|MMS Delivery |[DSN-Msg] Element |Report Element | ===================|==================|================================ Date and time the |Date: |'Date:' header field value of message was handled| |top-level -------------------|------------------|-------------------------------- 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) ===================|==================|================================ Gellens [Page 26] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 2.1.4.3 Read Report Mapping from MMS to Internet Message The following table maps information elements from MMS read reports to the format specified in [MDN]. 2.1.4.3.1 Table 7: 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 | | ----------------------|------------|----------------------------------- 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 . Gellens [Page 27] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 * 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 The following table maps information elements from a disposition report as specified in [MDN] to the format of an MMS read report. 2.1.4.4.1 Table 8: 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 ===================|==================|================================ Gellens [Page 28] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 ===================|==================|================================ Information Element|MMS Read Report |[MDN] Element |Element | ===================|==================|================================ 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. 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. Gellens [Page 29] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 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 are not included in this document. 4 IANA Considerations IANA is requested to add "MMS" as a "WITH protocol types" under its "MAIL Parameters" registry. The description is "Multimedia Messaging Service"; the reference is to this document. 5 Acknowledgments A number of people contributed to this document, especially the members of the IETF Lemonade 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 IETF: [DSN-Msg] "An Extensible Message Format for Delivery Status Notifications", Moore, Vaudreuil, RFC 3464, January 2003. [DSN-SMTP] "SMTP Service Extension for Delivery Status Notifications", Moore, RFC 3461, January 2003. [Hdr-Enc] "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", Moore, RFC 2047, November 1996. [HTTP] "Hypertext Transfer Protocol -- HTTP/1.1", Fielding et al, RFC 2616, June 1999. [IDN] "Internationalizing Domain Names in Applications (IDNA)", Faltstrom, Hoffman, Costello, RFC 3490, March 2003. Gellens [Page 30] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [MDN] "Message Disposition Notification", Hansen, Vaudreuil, RFC 3798, May 2004. [Msg-Fmt] "Internet Message Format", Resnick, RFC 2822, April 2001. [Report-Fmt] "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", Vaudreuil, RFC 3462, January 2003 [RESP] "Enhanced Mail System Status Codes", Vaudreuil, RFC 3463, January 2003. [SMTP] "Simple Mail Transfer Protocol", Klensin, RFC 2821, April 2001. OMA: OMA specifications are available at the OMA web site . [OMA-MMS] OMA-WAP-MMS-ENC-V1_2-20040323-C 3GPP2 and 3GPP: 3GPP2 specifications are available at the 3GPP2 (Third Generation Partnership Project 2) web site . 3GPP specifications are available at the 3GPP (Third Generation Partnership Project) web site [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 IETF: Gellens [Page 31] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 [BINARY] SMTP Service Extensions for Transmission of Large and Binary MIME Messages", Vaudreuil, Parsons, RFC 3030, December 2000. [Codes] "SMTP Service Extension for Returning Enhanced Error Codes", Freed, RFC 2034, October 1996. [Deliver-By] "Deliver By SMTP Service Extension", Newman, RFC 2852, June 2000. [Hdrs] "Common Internet Message Headers", J. Palme, RFC 2076, February 1997. [Mime-Sec-gw] "Gateways and MIME Security Multiparts", N. Freed, RFC 2480, January 1999. [PGP] "MIME Security with OpenPGP", Elkins, Del Torto, Levien, Roessler, RFC 3156, August 2001 [SMIME] "S/MIME Version 3 Message Specification", Ramsdell, RFC 2633, June 1999 [Submission] "Message Submission", Gellens, Klensin, RFC 2476, December 1998. [VPIM] "Voice Profile for Internet Mail - version 2 (VPIMv2)", Vaudreuil, Parsons, RFC 3801, June 2004. [Formats] "Multimedia Messaging Service (MMS) Media Format and Codecs for cdma2000 Spread Spectrum Systems", C.S0045 [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. 8 Author's Address Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 Gellens [Page 32] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 randy@qualcomm.com Appendix A: Changes Since Last Version [ This section to be deleted upon publication ] Changes from -05 to -06: o Editorial cleanups o Clarified that X-Priority is an older, non-standard header. Clarified that if both X-Priority and Importance appear, Importance SHOULD be used. o Clarified text regarding E.164 numbers o Changed SHOULD NOT to MUST NOT on unqualified E.164 numbers in address headers (otherwise messages are non-replyable) o Deleted X-Priority mapping table from MMS to Internet Mail o Deleted wording (accidently pasted) in table on Delivery Report Mappings (MMS to Internet Message) o Deleted unused [Auth], [IPSec], and [StartTLS] references o Rewrote text on mapping between Resent- and X-Mms-Previously-Sent- headers. o Corrected text that confused Envelope-ID and Message-ID. Changes from -04 to -05: o Abstract now mentions use of X-MMS-* headers in MMS. o Deleted "(MAY set to locally-generated value to hide sender identity)" from Table 1. o Deleted X-Priority from Table 1. o Replaced comment with empty group syntax' header in section 2.1.3.2. o Added Acknowledgements section. o Removed distinction between SMTP/821 and ESMTP/2821. o Removed discussion of sender address hiding. o Removed content transformation. o Replaced "Gateway" with reference to RFC 2821 Section 2.3.8. o Deleted 'Resent-Count:' o Deleted background information on resending/forwarding. o Changed 'Received:' headder generation to MUST on MMS->Internet. o Specified response code for "sensitivity" as per [VPIM]. o Changed "sensitivity" response code from SHOULD to MUST. o Removed reference to RFC 934. o Removed definition and mentions of anonymous remailer. o Rewrote and greatly simplified Security Considerations. o Added "MMS" as a "WITH protocol type" and requested IANA to register this in its "MAIL Parameters" registry. o Moved MMS references from Informative to Normative. o Removed hand-waving about Message-ID. o Attempted to clarify responsibility for report generation. Gellens [Page 33] Expires April 2006 Internet Draft Mapping Between MMS and Internet Mail October 2005 Intellectual Property Statement 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. Full Copyright Statement Copyright (C) The Internet Society (2005). 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. Gellens [Page 34] Expires April 2006