draft-ietf-lemonade-mms-mapping-06.txt   rfc4356.txt 
Internet Draft: Mapping Between MMS and Internet Mail R. Gellens Network Working Group R. Gellens
Document: draft-ietf-lemonade-mms-mapping-06.txt Qualcomm Request for Comments: 4356 Qualcomm
Expires: April 2006 October 2005 Category: Standards Track January 2006
Mapping Between the Multimedia Messaging Service (MMS) Mapping Between the Multimedia Messaging Service (MMS)
and Internet Mail and Internet Mail
Status of this Memo 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 This document specifies an Internet standards track protocol for the
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet community, and requests discussion and suggestions for
Internet-Draft Shadow Directories can be accessed at improvements. Please refer to the current edition of the "Internet
http://www.ietf.org/shadow.html. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2006).
Abstract Abstract
The cellular telephone industry has defined a service known as the The cellular telephone industry has defined a service known as the
Multimedia Messaging Service (MMS). This service uses formats and Multimedia Messaging Service (MMS). This service uses formats and
protocols which are similar to, but differ in key ways from, those protocols that are similar to, but differ in key ways from, those
used in Internet mail. used in Internet mail.
One important difference between MMS and Internet Mail is that MMS One important difference between MMS and Internet Mail is that MMS
uses headers which start with "X-Mms-" to carry a variety of user uses headers that start with "X-Mms-" to carry a variety of user
agent and server related information elements. agent- and server-related information elements.
Gellens [Page 1] Expires April 2006
This document specifies how to exchange messages between these two This document specifies how to exchange messages between these two
services, including mapping information elements as used in MMS services, including mapping information elements as used in MMS
X-Mms-* headers as well as delivery and disposition reports, to and X-Mms-* headers as well as delivery and disposition reports, to and
from that used in SMTP and Internet message headers. from that used in SMTP and Internet message headers.
Gellens [Page 2] Expires April 2006
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
1.1 Conventions Used in this Document . . . . . . . . . . . . 3 1.1. Scope ......................................................2
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Conventions Used in This Document ..........................3
1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Definitions ................................................3
1.4 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Abbreviations ..............................................4
1.5 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Assumptions ................................................4
2 Mapping Between MMS and Internet Mail . . . . . . . . . . . . 6 2. Mapping Between MMS and Internet Mail ...........................4
2.1 Mapping Specification . . . . . . . . . . . . . . . . . . 6 2.1. Mapping Specification ......................................5
2.1.1 MMS to Internet Mail . . . . . . . . . . . . . . . . . 6 2.1.1. MMS to Internet Mail ................................5
2.1.2 Internet Mail to MMS . . . . . . . . . . . . . . . . 7 2.1.2. Internet Mail to MMS ................................5
2.1.3 MMS Information Element Mappings . . . . . . . . . . . 7 2.1.3. MMS Information Element Mappings ....................6
2.1.3.1 Table 1: Information Element Mappings . . . . . . 8 2.1.4. Report Generation and Conversion ...................20
2.1.3.2 Conversion of messages from MMS to Internet format 10 2.1.5. Message Delivery ...................................27
2.1.3.2.1 Table 2: Importance Mappings (MMS to Internet 13 3. Security Considerations ........................................27
2.1.3.3 Conversion of messages from Internet to MMS format 17 4. IANA Considerations ............................................27
2.1.3.3.1 Table 4: Priority Mappings (Internet Message t 19 5. Acknowledgements ...............................................27
2.1.4 Report Generation and Conversion . . . . . . . . . . . 22 6. Normative References ...........................................27
2.1.4.1 Delivery Report Mapping from MMS to Internet Messa 22 7. Informative References .........................................29
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 1. Introduction
1.2 Scope 1.1. Scope
This document describes how to exchange messages between MMS systems This document describes how to exchange messages between Multimedia
(as defined by 3GPP/3GPP2/OMA) and Internet mail systems (that is, Messaging Service (MMS) systems (as defined by [3GPP][3GPP2][OMA])
[SMTP] and [Msg-Fmt]). This includes the translation of message and Internet mail systems (that is, [SMTP] and [Msg-Fmt]). This
formats, message header elements, message delivery reports and includes the translation of message formats, message header elements,
message disposition reports ([DSN-Msg] and [MDN]). message delivery reports [DSN-Msg], and message disposition reports
[MDN].
The MMS architecture [Stage_2] and specifications [Stage_3] refer to The MMS architecture [Stage_2] and specifications [Stage_3] refer to
interfaces as reference points named MMx. For example, MM1 is the interfaces as reference points named MMx. For example, MM1 is the
client-server interface, MM4 is the server-server interface, and MM3 client-server interface, MM4 is the server-server interface, and MM3
is an interface to "external" or non-MMS systems. The specification is an interface to "external" or non-MMS systems. The specification
in this document can be used for message exchange between any system in this document can be used for message exchange between any system
which uses Internet Message formats and protocols and an MMS system; that uses Internet message formats and protocols and an MMS system;
from the perspective of the MMS system, reference point MM3 is used. from the perspective of the MMS system, reference point MM3 is used.
This document includes support for voice messages specified by the This document includes support for voice messages specified by the
Voice Profile for Internet Mail [VPIM]. The VPIM specification Voice Profile for Internet Mail [VPIM]. The VPIM specification
allows voice messages to be exchanged between voice mail systems allows voice messages to be exchanged between voice mail systems
using Internet mail format [Msg-Fmt] and transported via [SMTP]. using the Internet mail format [Msg-Fmt] and transported via [SMTP].
Thus, the MMS MM3 interface supports the ability to exchange voice Thus, the MMS MM3 interface supports the ability to exchange voice
messages between an MMS system and a voice mail system. Note that 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 such use is distinct from voice media being part of a user-composed
multimedia message. multimedia message.
Note that MM3 can also be used for interworking with "external" Note that MM3 can also be used for interworking with "external"
(non-MMS) systems other than Internet mail, such as Short Messaging (non-MMS) systems other than Internet mail, such as Short Messaging
Service (SMS) and access to external mail stores (such as a voice Service (SMS) and access to external mail stores (such as a voice
mail system). This specification does not address these other uses mail system). This specification does not address these other uses
or sub-interfaces of MM3; it is only concerned with Internet mail or sub-interfaces of MM3; it is only concerned with Internet mail
interworking and specifically exchange of messages. interworking and specifically exchange of messages.
All MM3 Stage 2 [Stage_2] functions are supported except for reply All MM3 Stage 2 [Stage_2] functions are supported except for reply
charging and sender address hiding. charging and sender address hiding.
1.3 Definitions 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 Body |The portion of an [SMTP] message's Content
|following the Header (that is, following the |following the Header (that is, following the
|first blank line). The Body may contain |first blank line). The Body may contain
|structured parts and sub-parts, each of which |structured parts and sub-parts, each of which
|may have their own Header and Body. The Body |may have its own Header and Body. The Body
|contains information intended for the message |contains information intended for the message
|recipient (human or software). |recipient (human or software).
--------------------|---------------------------------------------- --------------------|----------------------------------------------
Gellens [Page 4] Expires April 2006
--------------------|----------------------------------------------
Content |The portion of an SMTP message that is Content |The portion of an SMTP message that is
|delivered. The Content consists of a Header |delivered. The Content consists of a Header
|and a Body. |and a Body.
--------------------|---------------------------------------------- --------------------|----------------------------------------------
Disposition Report |Feedback information to an originator User Disposition Report |Feedback information to an originator User
|Agent by a recipient User Agent about |Agent by a recipient User Agent about
Message Disposition |handling of an original message. This may Message Disposition |handling of an original message. This may
Notification |include notification that the message was or Notification |include notification that the message was or
|was not read, was deleted unread, etc. |was not read, was deleted unread, etc.
--------------------|---------------------------------------------- --------------------|----------------------------------------------
Envelope |The portion of an SMTP message not included in Envelope |The portion of an SMTP message not included in
|the Content; that is, not in the Header nor in |the Content, that is, not in the Header or in
|the Body. While some of it may be copied into |the Body. While some of it may be copied into
|the Content on delivery, envelope information |the Content on delivery, envelope information
|only exists while the message is in transit, |exists only while the message is in transit,
|and contains information used by SMTP agents |and contains information used by SMTP agents
|(MTAs). |(Mail Transfer Agents (MTAs)).
--------------------|---------------------------------------------- --------------------|----------------------------------------------
Gateway |See [SMTP], Section 2.3.8. Gateway |See [SMTP], Section 2.3.8.
--------------------|---------------------------------------------- --------------------|----------------------------------------------
--------------------|----------------------------------------------
Header |The first part of an SMTP message's Content. Header |The first part of an SMTP message's Content.
|The Header is separated from the Body by a |The Header is separated from the Body by a
|blank line. The Header consists of Fields |blank line. The Header consists of Fields
|(such as "To:"), also known as Header Fields |(such as "To:"), also known as Header Fields
|or Headers. The message Header contains |or Headers. The message Header contains
|information used by User Agents. |information used by User Agents.
--------------------|---------------------------------------------- --------------------|----------------------------------------------
Relay/Server |An MMS server. See [Stage_2]. For purposes Relay/Server |An MMS server. See [Stage_2]. For purposes
|of this document, an MMS Relay/Server acts as |of this document, an MMS Relay/Server acts as
|a gateway when it receives or sends messages |a gateway when it receives or sends messages
|via Internet mail. |via Internet mail.
--------------------|---------------------------------------------- --------------------|----------------------------------------------
User Agent |An MMS or Email user agent User Agent |An MMS or email user agent.
--------------------|---------------------------------------------- --------------------|----------------------------------------------
Gellens [Page 5] Expires April 2006 1.4. Abbreviations
1.4 Abbreviations
--------|---------------------------------------------------------- --------|----------------------------------------------------------
MSA |Message Submission Agent. A server which accepts messages MSA |Message Submission Agent. A server that accepts messages
|from User Agents and processes them; either delivering |from User Agents and processes them, either delivering
|them locally or relaying to an MTA. |them locally or relaying to an MTA. See [Submission].
--------|---------------------------------------------------------- --------|----------------------------------------------------------
MTA |Mail Transfer Agent. A server which implements [SMTP]. MTA |Mail Transfer Agent. A server that implements [SMTP].
--------|---------------------------------------------------------- --------|----------------------------------------------------------
1.5 Assumptions 1.5. Assumptions
It is assumed that the reader is already familiar with the contents It is assumed that the reader is already familiar with the contents
of the 3GPP2 MMS Specification Overview [Overview], MMS Stage 1 of the 3GPP2 MMS Specification Overview [Overview], MMS Stage 1
(requirements) [Stage_1] and Stage 2 (architecture and abstract (requirements) [Stage_1] and Stage 2 (architecture and abstract
messages) [Stage_2], and 3GPP/3GPP2 Stage 3 (protocols) [Stage_3] messages) [Stage_2], and 3GPP/3GPP2 Stage 3 (protocols) [Stage_3]
documents. It is also assumed that the reader is familiar with documents. It is also assumed that the reader is familiar with
Internet mail, especially RFC 2821 [SMTP] and RFC 2822 [Msg-Fmt]. Internet mail, especially RFC 2821 [SMTP] and RFC 2822 [Msg-Fmt].
2 Mapping Between MMS and Internet Mail 2. Mapping Between MMS and Internet Mail
This section defines the interworking between MMS Relay/Servers and This section defines the interworking between MMS Relay/Servers and
External Servers using native [SMTP]. That is, information elements External Servers using native [SMTP]. That is, information elements
are exchanged using standard Internet Message [Msg-Fmt] header are exchanged using standard Internet message [Msg-Fmt] header
fields and standard [SMTP] elements. fields, such as those in [Hdrs], and standard [SMTP] elements.
SMTP and Internet mail extensions are used for features such as SMTP and Internet mail extensions are used for features such as
delivery reports, message expiration, discovery of server support delivery reports, message expiration, and discovery of server support
for optional features, etc. for optional features.
2.1 Mapping Specification 2.1. Mapping Specification
2.1.1 MMS to Internet Mail 2.1.1. MMS to Internet Mail
When sending a message to an Internet mail system the MMS When sending a message to an Internet mail system, the MMS
Relay/Server MUST convert the MM if required, and MUST comply with Relay/Server MUST convert the MM if required, and MUST comply with
the requirements of [SMTP]. the requirements of [SMTP].
The MMS Relay/Server SHOULD use the information elements associated The MMS Relay/Server SHOULD use the information elements associated
with the MM to define the control information (Internet Message with the MM to define the control information (Internet message
header fields and SMTP envelope values) needed for the transfer header fields and SMTP envelope values) needed for the transfer
protocol. protocol.
Gellens [Page 6] Expires April 2006 Section 2.1.3 lists the mappings between X-Mms-* headers and Internet
Section 2.1.3 lists the mappings between X-Mms-* headers and message header fields and SMTP values.
Internet Message header fields and SMTP values.
Delivery and read report MMs SHOULD be converted to standard Delivery and read report MMs SHOULD be converted to standard Internet
Internet Message report format (multipart/report). In addition to message report format (multipart/report). In addition to converting
converting Internet Message reports, the MMS Relay/Server MUST Internet Message reports, the MMS Relay/Server MUST generate delivery
generate delivery and read report MMs for received messages as and read report MMs for received messages as appropriate. See
appropriate. See section 2.1.4 for more information. Section 2.1.4 for more information.
2.1.2 Internet Mail to MMS 2.1.2. Internet Mail to MMS
When receiving a message from an Internet mail system the MMS When receiving a message from an Internet mail system, the MMS
Relay/Server converts incoming messages to the MM format used within Relay/Server converts incoming messages to the MM format used within
the receiving system. the receiving system.
The MMS Relay/Server converts control information received from the The MMS Relay/Server converts control information received from the
Internet mail server into appropriate information elements of an MM. Internet mail server into appropriate information elements of an MM.
Section 2.1.3 lists the mappings between X-Mms-* headers and Section 2.1.3 lists the mappings between X-Mms-* headers and Internet
Internet Message header fields and SMTP values. message header fields and SMTP values.
Standard Internet Message report format (multipart/report) messages Standard Internet message report format (multipart/report) messages
MAY be converted to delivery or read report MMs, as appropriate. In MAY be converted to delivery or read report MMs, as appropriate. In
addition to converting report MMs, implementations conforming to addition to converting report MMs, implementations conforming to this
this document MUST generate standard Internet Message delivery and document MUST generate standard Internet message delivery and
disposition reports for received Internet messages as appropriate. disposition reports for received Internet messages as appropriate.
See section 2.1.4 for more information. See Section 2.1.4 for more information.
Gellens [Page 7] Expires April 2006
2.1.3 MMS Information Element Mappings 2.1.3. MMS Information Element Mappings
The mappings between MMS elements and SMTP/Internet Message elements The mappings between MMS elements and SMTP/Internet message elements
([SMTP] parameters, [Msg-Fmt] headers, and [Dsn-Msg] fields) are ([SMTP] parameters, [Msg-Fmt] headers, and [DSN-Msg] fields) are
summarized in the table below, and detailed in subsequent sections. summarized in table 1 below, and detailed in subsequent sections.
The "MMS Headers" are from [OMA-MMS]. Note that only information The "MMS Headers" are from [OMA-MMS]. Note that only information
elements which need to be mapped are listed. [Msg-Fmt] headers not elements that need to be mapped are listed. [Msg-Fmt] headers not
listed here SHOULD be passed unaltered listed here SHOULD be passed unaltered.
2.1.3.1 Table 1: Information Element Mappings 2.1.3.1. Table 1: Information Element Mappings
=================|=================|================|============== =================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|============== =================|=================|================|==============
3GPP MMS Version |N/A |N/A |X-Mms-3GPP-MMS 3GPP MMS Version |N/A |N/A |X-Mms-3GPP-MMS
| | | -Version: | | | -Version:
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Message Type |N/A |N/A |X-Mms-Message- Message Type |N/A |N/A |X-Mms-Message-
(of PDU) | | | Type: (of PDU) | | | Type:
_________________|_________________|________________|______________ _________________|_________________|________________|______________
skipping to change at line 306 skipping to change at page 6, line 48
|("<>") for all | | |("<>") for all | |
|automatically- | | |automatically- | |
|generated MMs | | |generated MMs | |
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Content type |N/A |Content-Type: |Content-type: Content type |N/A |Content-Type: |Content-type:
| | | | | |
| |For voice mes- | | |For voice mes- |
| |sages compliant | | |sages compliant |
| |to [VPIM], see | | |to [VPIM], see |
| |Note 2 | | |Note 2 |
=================|=================|================|============== _________________|_________________|________________|______________
Gellens [Page 8] Expires April 2006
=================|=================|================|============== =================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|============== =================|=================|================|==============
Message class |Class=auto: |MAY set 'Prece |X-Mms-Message- Message class |Class=auto: |MAY set 'Prece |X-Mms-Message-
|MUST set MAIL | dence: bulk' | Class: |MUST set MAIL | dence: bulk' | Class:
|FROM to null |on class=auto | |FROM to null |on class=auto |
|("<>"). | | |("<>"). | |
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Date and time |N/A |Date: |Date: Date and time |N/A |Date: |Date:
of submission | | | of submission | | |
skipping to change at line 356 skipping to change at page 7, line 51
Reply-charging |(not currently |(not currently |X-Mms-Reply- Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging: permission |supported) |supported) | Charging:
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply- Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging- permission |supported) |supported) | Charging-
deadline | | | Deadline: deadline | | | Deadline:
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply- Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging- permission |supported) |supported) | Charging-
limitation | | | Size: limitation | | | Size:
=================|=================|================|============== _________________|_________________|________________|______________
Gellens [Page 9] Expires April 2006
=================|=================|================|============== =================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|============== =================|=================|================|==============
Reply charging |(not currently |(not currently |X-Mms-Reply- Reply charging |(not currently |(not currently |X-Mms-Reply-
usage request |supported) |supported) | Charging- usage request |supported) |supported) | Charging-
| | | Id: | | | Id:
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Reply charging |(not currently |(not currently |X-Mms-Reply- Reply charging |(not currently |(not currently |X-Mms-Reply-
usage reference |supported) |supported) | Charging: usage reference |supported) |supported) | Charging:
_________________|_________________|________________|______________ _________________|_________________|________________|______________
skipping to change at line 389 skipping to change at page 8, line 34
Hop/host trace |N/A |Received: |(Not sup- Hop/host trace |N/A |Received: |(Not sup-
| | |ported) | | |ported)
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Sensitivity |N/A |Sensitivity: see|N/A Sensitivity |N/A |Sensitivity: see|N/A
| |Note 1 | | |Note 1 |
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Content |N/A |<message body> |<message body> Content |N/A |<message body> |<message body>
=================|=================|================|============== =================|=================|================|==============
Note 1: The [VPIM] 'Sensitivity' header element indicates the Note 1: The [VPIM] 'Sensitivity' header element indicates the
privacy requested by the message originator (values are "personal" privacy requested by the message originator (values are "personal" or
or "private"); per [VPIM], a message recipient MUST NOT forward a "private"); per [VPIM], a message recipient MUST NOT forward a
message with a 'Sensitivity' header. Since sensitivity is not an message with a 'Sensitivity' header. Since sensitivity is not an MMS
MMS feature, any messages which contain a 'Sensitivity:' header feature, any messages that contain a 'Sensitivity:' header SHOULD NOT
SHOULD NOT be sent to an MMS system. be sent to an MMS system.
Note 2: [VPIM] specifies how conforming messages are identified. Note 2: [VPIM] specifies how conforming messages are identified.
2.1.3.2 Conversion of messages from MMS to Internet format 2.1.3.2. Conversion of Messages from MMS to Internet Format
3GPP MMS Version 3GPP MMS Version
The 'X-Mms-3GPP-MMS-Version:' header, if present, SHOULD be removed. The 'X-Mms-3GPP-MMS-Version:' header, if present, SHOULD be removed.
Message Type (of PDU) Message Type (of PDU)
Gellens [Page 10] Expires April 2006
The 'X-Mms-Message-Type:' header, if present, SHOULD be removed. The 'X-Mms-Message-Type:' header, if present, SHOULD be removed.
Transaction ID Transaction ID
The 'X-Mms-Transaction-Id:' header, if present, SHOULD be removed. The 'X-Mms-Transaction-Id:' header, if present, SHOULD be removed.
Message ID Message ID
The 'Message-Id:' header MUST be retained. If not present it MUST The 'Message-Id:' header MUST be retained. If not present, it MUST
be created, with a unique value, per [Msg-Fmt]. be created, with a unique value, per [Msg-Fmt].
To facilitate the case where an MMS message traverses the Internet To facilitate the case where an MMS message traverses the Internet
prior to returning to an MMS system, implementations might wish to prior to returning to an MMS system, implementations might wish to
retain the 'X-Mms-Message-Id:' header. Such systems should be aware retain the 'X-Mms-Message-Id:' header. Such systems should be aware
that headers which begin with "X-" might be removed during transit that headers that begin with "X-" might be removed during transit
through Internet MTAs. through Internet MTAs.
Recipient(s) address Recipient(s) address
The address of each recipient MUST be transmitted in the [SMTP] The address of each recipient MUST be transmitted in the [SMTP]
envelope as a RCPT TO value. All disclosed recipients SHOULD also envelope as a RCPT TO value. All disclosed recipients SHOULD also
appear in a 'To:' or 'Cc:' header. At least one 'To:', 'Cc:', or 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 'Bcc:' header MUST be present. If none are present, a 'To:' header
SHOULD be created using empty group syntax whose name gives an SHOULD be created using empty group syntax whose name gives an
indication to a human reader, for example 'To: indication to a human reader, for example, 'To: undisclosed-
undisclosed-recipients:;'. recipients:;'.
The 'To:' header SHOULD NOT appear more than once. The 'Cc:' header The 'To:' header SHOULD NOT appear more than once. The 'Cc:' header
SHOULD NOT appear more than once. SHOULD NOT appear more than once.
Each recipient address MUST obey the length restrictions per [SMTP]. Each recipient address MUST obey the length restrictions per [SMTP].
Current Internet message format requires that only 7-bit US-ASCII Current Internet Message format requires that only 7-bit US-ASCII
characters be present in headers. Non-7-bit characters in an characters be present in headers. Non-7-bit characters in an address
address domain must be encoded with [IDN]. If there are any domain must be encoded with [IDN]. If there are any non-7-bit
Non-7-bit characters in the local part of an address, the message characters in the local part of an address, the message MUST be
MUST be rejected. Non-7-bit characters elsewhere in a header MUST rejected. Non-7-bit characters elsewhere in a header MUST be encoded
be encoded according to [Hdr-Enc]. according to [Hdr-Enc].
All recipient addresses in the [SMTP] envelope must be All recipient addresses in the [SMTP] envelope must be fully-
fully-qualified in accordance with [SMTP]. In particular, messages qualified in accordance with [SMTP]. In particular, messages MUST
MUST NOT be sent to an Internet mail system with an unqualified NOT be sent to an Internet mail system with an unqualified E.164
E.164 number (i.e., a number with no domain) instead of a number (i.e., a number with no domain) instead of a fully-qualified
fully-qualified domain name. domain name.
All addresses in 'To:', 'Cc:', and 'Bcc:' headers MUST be in the All addresses in 'To:', 'Cc:', and 'Bcc:' headers MUST be in the form
form of fully-qualified domains. Unqualified E.164 numbers MUST NOT of fully-qualified domains. Unqualified E.164 numbers MUST NOT be
be used. used.
Gellens [Page 11] Expires April 2006
Sender address Sender address
The address of the message sender SHOULD appear in the 'From:' The address of the message sender SHOULD appear in the 'From:'
header. header.
The address of the message sender for all user-generated messages The address of the message sender for all user-generated messages
('X-Mms-Message-Class: Personal') SHOULD be transmitted in the ('X-Mms-Message-Class: Personal') SHOULD be transmitted in the
[SMTP] envelope as the MAIL FROM value. [SMTP] envelope as the MAIL FROM value.
The return addresses in the [SMTP] envelope must be fully-qualified The return addresses in the [SMTP] envelope must be fully-qualified
in accordance with [SMTP]. In particular, messages MUST NOT be sent in accordance with [SMTP]. In particular, messages MUST NOT be sent
to an Internet mail system with an E.164 number instead of a to an Internet mail system with an E.164 number instead of a fully-
fully-qualified domain name. Note that qualified E.164 numbers, qualified domain name. Note that qualified E.164 numbers, that is,
that is, those that contain an E.164 number as the local-part of an those that contain an E.164 number as the local-part of an address
address that also includes a domain, are acceptable. that also includes a domain, are acceptable.
The address(es) in the 'From:' header SHOULD be in the form of The address(es) in the 'From:' header SHOULD be in the form of
fully-qualified domains. Unqualified E.164 numbers SHOULD NOT be fully-qualified domains. Unqualified E.164 numbers SHOULD NOT be
used. used.
Because of the risk of mail loops, it is critical that the MAIL FROM 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 be set to null ("<>") for all automatically-generated MMs (such as
'X-Mms-Message-Class: Auto'). The MAIL FROM value MUST be set to 'X-Mms-Message-Class: Auto'). The MAIL FROM value MUST be set to
null for all automatically-generated messages. This includes null for all automatically-generated messages. This includes
reports, "out-of-office" replies, etc. reports, "out-of-office" replies, etc.
Current Internet message format requires that only 7-bit US-ASCII Current Internet message format requires that only 7-bit US-ASCII
characters be present in headers. Non-7-bit characters in an characters be present in headers. Non-7-bit characters in an address
address domain must be encoded with [IDN]. If there are any domain must be encoded with [IDN]. If there are any Non-7-bit
Non-7-bit characters in the local part of an address, the message characters in the local part of an address, the message MUST be
MUST be rejected. Non-7-bit characters elsewhere in a header MUST rejected. Non-7-bit characters elsewhere in a header MUST be encoded
be encoded according to [Hdr-Enc]. Note that it would be possible according to [Hdr-Enc]. Note that it would be possible to define an
to define an [SMTP] extension to permit transmission of unencoded [SMTP] extension to permit transmission of unencoded 8-bit
8-bit characters, but in the absence of such an extension [Hdr-Enc] characters, but in the absence of such an extension [Hdr-Enc] MUST be
MUST be used. used.
The sender address MUST obey the length restrictions of [SMTP]. The sender address MUST obey the length restrictions of [SMTP].
Content type Content type
The 'Content-Type:' header SHOULD be preserved. The 'Content-Type:' header SHOULD be preserved.
Message class Message class
The 'X-Mms-Message-Class:' header MAY be retained in order to The 'X-Mms-Message-Class:' header MAY be retained in order to provide
provide information on the source of the message. A 'Precedence: information on the source of the message. A 'Precedence: bulk'
bulk' header MAY be inserted for class=auto or class=advertisement. header MAY be inserted for class=auto or class=advertisement. See
See 'Sender Address' above. (Class=personal and class=informational 'Sender Address' above. (Class=personal and class=informational do
do not require special handling.) not require special handling.)
Gellens [Page 12] Expires April 2006
Time of Expiry Time of Expiry
The 'X-Mms-Expiry:' header, if present, SHOULD be removed. The 'X-Mms-Expiry:' header, if present, SHOULD be removed.
The remaining time until the message is considered expired SHOULD be The remaining time until the message is considered expired SHOULD be
transmitted in the [SMTP] envelope by using the DELIVER-BY extension transmitted in the [SMTP] envelope by using the DELIVER-BY extension
with a by-mode of "R", as specified in [Deliver-By]. with a by-mode of "R", as specified in [Deliver-By].
Note that the [SMTP] DELIVER-BY extension carries time remaining Note that the [SMTP] DELIVER-BY extension carries time remaining
until expiration; each server decrements the value by the amount of until expiration; each server decrements the value by the amount of
time it has possessed the message. The 'X-Mms-Expiry:' header may time it has possessed the message. The 'X-Mms-Expiry:' header may
contain either the absolute time at which the message is considered contain either the absolute time at which the message is considered
expired or the relative time until the message is considered expired or the relative time until the message is considered expired.
expired.
Earliest delivery time Earliest delivery time
The 'X-Mms-Delivery-Time:' header, if present, SHOULD be removed. The 'X-Mms-Delivery-Time:' header, if present, SHOULD be removed.
Future delivery is a message submission, not message relay feature. Future delivery is a message submission (e.g., [Submission]), not
message relay feature.
Delivery report request Delivery report request
Requests for delivery status notifications (DSNs) SHOULD be Requests for delivery status notifications (DSNs) SHOULD be
transmitted in the [SMTP] envelope by using the DSN extension as transmitted in the [SMTP] envelope by using the DSN extension as
specified in [DSN-SMTP] to request "success" or "none" notification specified in [DSN-SMTP] to request "success" or "none" notification
(depending on the value of the 'X-Mms-Delivery-Report' header). (depending on the value of the 'X-Mms-Delivery-Report' header). When
When the NOTIFY extension is used, the unaltered recipient address the NOTIFY extension is used, the unaltered recipient address SHOULD
SHOULD be transmitted as the ORCPT value. be transmitted as the ORCPT value.
The 'X-Mms-Delivery-Report:' header, if present, SHOULD be removed. The 'X-Mms-Delivery-Report:' header, if present, SHOULD be removed.
Importance Importance
The message sender's importance value (also called "priority", The message sender's importance value (also called "priority",
although this can be confused with class-of-service values) SHOULD although this can be confused with class-of-service values) SHOULD be
be transmitted using an 'Importance:' header. transmitted using an 'Importance:' header.
Suggested mappings: Suggested mappings are shown in Table 2:
2.1.3.2.1 Table 2: Importance Mappings (MMS to Internet Message) 2.1.3.2.1. Table 2: Importance Mappings (MMS to Internet Message)
---------------------------|------------------ ---------------------------|------------------
'X-Mms-Priority: High' |'Importance: High' 'X-Mms-Priority: High' |'Importance: High'
---------------------------|------------------ ---------------------------|------------------
'X-Mms-Priority: Normal' |[omit] 'X-Mms-Priority: Normal' |[omit]
---------------------------|------------------ ---------------------------|------------------
'X-Mms-Priority: Low' |'Importance: Low' 'X-Mms-Priority: Low' |'Importance: Low'
---------------------------|------------------ ---------------------------|------------------
Gellens [Page 13] Expires April 2006
Normal importance messages should omit the 'Importance:' header. Normal importance messages should omit the 'Importance:' header.
The 'X-Mms-Priority:' header, if present, SHOULD be removed. The 'X-Mms-Priority:' header, if present, SHOULD be removed.
Sender visibility Sender visibility
Support for sender address hiding is not currently supported. Support for sender address hiding is not currently supported.
A message that contains an 'X-Mms-Sender-Visibility:' header with a A message that contains an 'X-Mms-Sender-Visibility:' header with a
value of 'Hide' SHOULD be rejected. value of 'Hide' SHOULD be rejected.
The 'X-Mms-Sender-Visibility:' header, if present, SHOULD be The 'X-Mms-Sender-Visibility:' header, if present, SHOULD be removed.
removed.
Read reply request Read reply request
A request for a read reply SHOULD be transmitted using a A request for a read reply SHOULD be transmitted using a
'Disposition-Notification-To:' header as specified in [MDN]. 'Disposition-Notification-To:' header as specified in [MDN].
The 'X-Mms-Read-Reply:' header, if present, SHOULD be removed. The 'X-Mms-Read-Reply:' header, if present, SHOULD be removed.
Reply-charging Reply charging
Reply charging permission and acceptance are complex issues Reply charging permission and acceptance are complex issues requiring
requiring both user agent and server support. Misapplied reply both user agent and server support. Misapplied reply charging may
charging may cause incorrect billing. Until the security issues cause incorrect billing. Until the security issues have been
have been properly addressed, reply charging SHOULD NOT be honored properly addressed, reply charging SHOULD NOT be honored when using
when using this interface. this interface.
The 'X-Mms-Reply-Charging:', 'X-Mms-Reply-Charging-Deadline:', The 'X-Mms-Reply-Charging:', 'X-Mms-Reply-Charging-Deadline:', 'X-
'X-Mms-Reply-Charging-Size:', and 'X-Mms-Reply-Charging-Id:' headers Mms-Reply-Charging-Size:', and 'X-Mms-Reply-Charging-Id:' headers MAY
MAY be removed. Messages containing a reply-charging usage request be removed. Messages containing a reply-charging usage request ('X-
('X-Mms-Reply-Charging-Id:' and 'X-Mms-Reply-Charging: accepted' or Mms-Reply-Charging-Id:' and 'X-Mms-Reply-Charging: accepted' or 'X-
'X-Mms-Reply-Charging: accepted (text only)' headers) SHOULD be Mms-Reply-Charging: accepted (text only)' headers) SHOULD be
rejected. rejected.
Subject Subject
The 'Subject:' header MUST be preserved. Current Internet message The 'Subject:' header MUST be preserved. The current Internet
format requires that only 7-bit US-ASCII characters be present. message format requires that only 7-bit US-ASCII characters be
Other characters MUST be encoded according to [Hdr-Enc]. Note that present. Other characters MUST be encoded according to [Hdr-Enc].
it is possible for an [SMTP] extension to be defined which would Note that it is possible for an [SMTP] extension to be defined that
permit transmission of unencoded 8-bit characters, but in the would permit transmission of unencoded 8-bit characters, but in the
absence of such an extension [Hdr-Enc] MUST be used. absence of such an extension, [Hdr-Enc] MUST be used.
Resending Resending
Gellens [Page 14] Expires April 2006 A message may be resent to one or more new recipients. It may be
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
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 the top of the existing headers. Thus, if more than one series of
'Resent-' headers are present, the original series is the last; the 'Resent-' headers are present, the original series is the last; the
most recent is the first. most recent is the first.
Forward counter Forward counter
An 'X-Mms-Forward-Counter:' header, if present, SHOULD be removed. An 'X-Mms-Forward-Counter:' header, if present, SHOULD be removed.
The 'Resent-Count:' header is NOT RECOMMENDED. Loop control is The 'Resent-Count:' header is NOT RECOMMENDED. Loop control is
usually done by counting 'Received' headers, which are more general usually done by counting 'Received' headers, which are more general
than 'Resent-' headers. than 'Resent-' headers.
Previously-Sent Information Previously-Sent Information
MMS lists the resending history of a message in two headers: MMS lists the resending history of a message in two headers: 'X-
'X-Mms-Previously-Sent-By:' and Mms-Previously-Sent-By:' and 'X-Mms-Previously-Sent-Date-and-Time:'.
'X-Mms-Previously-Sent-Date-and-Time:'. 'X-Mms-Previously-Sent-By:' 'X-Mms-Previously-Sent-By:' contains a number followed by one or
contains a number followed by one or more addresses. more addresses. 'X-Mms-Previously-Sent-Date-and-Time:' contains a
'X-Mms-Previously-Sent-Date-and-Time:' contains a number followed by number followed by a date-time. With both headers, the number "0" is
a date-time. With both headers, the number "0" is used for the used for the entry that corresponds to the original submission of the
entry that corresponds to the original submission of the message, message, with higher values being used for each subsequent resending.
with higher values being used for each subsequent resending. The The final (most recent) resending information is in the 'From:' and
final (most recent) resending information is in the 'From:' and
'Date:' headers. There is also an 'X-Mms-Forward-Counter:' that 'Date:' headers. There is also an 'X-Mms-Forward-Counter:' that
indicates how many times the message has been resent. indicates how many times the message has been resent.
Any 'X-Mms-Previously-Sent-By:', Any 'X-Mms-Previously-Sent-By:', 'X-Mms-Previously-Sent-Date-and-
'X-Mms-Previously-Sent-Date-and-Time:', and 'X-Mms-Forward-Counter:' Time:', and 'X-Mms-Forward-Counter:' headers, if present, SHOULD be
headers, if present, SHOULD be removed. The information contained removed. The information contained in them SHOULD be translated into
in them SHOULD be translated into [Msg-Fmt] headers as follows: [Msg-Fmt] headers as follows:
The 'X-Mms-Previously-Sent-Date-and-Time:' header whose value starts The 'X-Mms-Previously-Sent-Date-and-Time:' header whose value starts
with "0" SHOULD be used to create a 'Date:' header, converting the 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 date and time from HTTP-date [HTTP] to date-time [Msg-Fmt]. The 'X-
'X-Mms-Previously-Sent-By:' header whose value starts with "0" Mms-Previously-Sent-By:' header whose value starts with "0" SHOULD be
SHOULD be used to create a 'From:' header. used to create a 'From:' header.
A 'To:' header SHOULD be created using list syntax with a value of A 'To:' header SHOULD be created using list syntax with a value of
"unrecoverable-recipients" and no mailboxes. "unrecoverable-recipients" and no mailboxes.
A 'Message-ID:' header SHOULD be created. A 'Message-ID:' header SHOULD be created.
Any 'X-Mms-Previously-Sent-Date-and-Time:' headers whose value Any 'X-Mms-Previously-Sent-Date-and-Time:' headers whose value starts
starts with "1" or a larger value are mapped to 'Resent-Date:' with "1" or a larger value are mapped to 'Resent-Date:' headers.
headers. Any 'X-Mms-Previously-Sent-By:' headers whose value starts Any 'X-Mms-Previously-Sent-By:' headers whose value starts with "1"
with "1" or a larger value are mapped to 'Resent-By:' headers. or a larger value are mapped to 'Resent-By:' headers.
Gellens [Page 15] Expires April 2006
The 'From:', 'To:', 'Date:', and 'Message-ID:' headers are mapped to The 'From:', 'To:', 'Date:', and 'Message-ID:' headers are mapped to
'Resent-From:', 'Resent-To:', 'Resent-Date:', and 'Resent-From:', 'Resent-To:', 'Resent-Date:', and 'Resent-Message-
'Resent-Message-ID:' headers in the top-most block of 'Resent-*' ID:' headers in the top-most block of 'Resent-*' headers.
headers.
Example: Example:
The MMS message: The MMS message:
X-Mms-Forward-Counter: 2 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-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-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-Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT
X-Mms-Previously-Sent-By: 1, Colonel Corn <gcorn@example.mil> X-Mms-Previously-Sent-By: 1, Colonel Corn <gcorn@example.mil>
skipping to change at line 690 skipping to change at page 14, line 49
Resent-Date: Fri, 1 Apr 2005 08:02:03 +0000 Resent-Date: Fri, 1 Apr 2005 08:02:03 +0000
Resent-From: Colonel Corn <gcorn@example.mil> Resent-From: Colonel Corn <gcorn@example.mil>
Date: Fri, 1 Apr 2005 06:02:03 +0000 Date: Fri, 1 Apr 2005 06:02:03 +0000
From: General Failure <mfail@example.mil> From: General Failure <mfail@example.mil>
To: Colonel Corn <gcorn@example.mil> To: Colonel Corn <gcorn@example.mil>
Message-ID: <000.000.000@gateway.example.org> Message-ID: <000.000.000@gateway.example.org>
'Received:' Headers 'Received:' Headers
When a message is gatewayed from MMS to Internet mail, a 'Received:' When a message is gatewayed from MMS to Internet mail, a 'Received:'
header MUST be added as per [SMTP]. The "with" clause should header MUST be added as per [SMTP]. The "with" clause should specify
specify "MMS". "MMS".
A message MAY be rejected if the number of 'Received:' headers A message MAY be rejected if the number of 'Received:' headers
exceeds a locally-defined maximum, which MUST conform to [SMTP] exceeds a locally-defined maximum, which MUST conform to [SMTP]
section 6.2 and SHOULD be no less than 100. Section 6.2 and SHOULD be no less than 100.
Privacy Privacy
Note that MMS systems do not currently support the 'Privacy' header Note that MMS systems do not currently support the 'Privacy' header
field as described by [VPIM]. field as described by [VPIM].
Gellens [Page 16] Expires April 2006
Content Content
The message content appears in the message body. Note that Internet The message content appears in the message body. Note that Internet
message format requires that line-endings be encoded as US-ASCII CR message format requires that line endings be encoded as US-ASCII CR
LF octets, thus charset encodings that do not have this property 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 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 parts, but only when they are suitably encoded or when binary
transmission has been negotiated.) In particular, MMS allows UTF-16, transmission has been negotiated, e.g., [BINARY].) In particular,
while Internet message format does not. UTF-16 encoding MUST be MMS allows UTF-16, whereas the Internet message format does not.
translated to UTF-8 or another charset and encoding which is UTF-16 encoding MUST be translated to UTF-8 or another charset and
suitable for use in Internet message format/protocols. encoding that is suitable for use in Internet message
format/protocols.
2.1.3.3 Conversion of messages from Internet to MMS format 2.1.3.3. Conversion of Messages from Internet to MMS Format
3GPP MMS Version 3GPP MMS Version
An 'X-Mms-3GPP-MMS-Version:' header SHOULD be added. An 'X-Mms-3GPP-MMS-Version:' header SHOULD be added.
Message Type (of PDU) Message Type (of PDU)
An 'X-Mms-Message-Type:' header SHOULD be used in accordance with An 'X-Mms-Message-Type:' header SHOULD be used in accordance with the
the specific MMS interface (e.g., MM1, MM4). specific MMS interface (e.g., MM1, MM4).
Transaction ID Transaction ID
An 'X-Mms-Transaction-Id:' header SHOULD be used in accordance with An 'X-Mms-Transaction-Id:' header SHOULD be used in accordance with
the specific MMS interface (e.g., MM1, MM4). the specific MMS interface (e.g., MM1, MM4).
Message ID Message ID
The 'Message-Id:' header MUST be retained. If not present it MUST The 'Message-Id:' header MUST be retained. If not present, it MUST
be created, with a unique value. be created, with a unique value.
Recipient(s) address Recipient(s) address
'To:' and 'Cc:' headers MUST be retained. 'To:' and 'Cc:' headers MUST be retained.
Each recipient contained in the [SMTP] envelope (RCPT TO values) Each recipient contained in the [SMTP] envelope (RCPT TO values) MUST
MUST be considered a recipient of the message. Recipients who be considered a recipient of the message. Recipients who appear in
appear in address headers but not the [SMTP] envelope MUST be address headers but not the [SMTP] envelope MUST be ignored.
ignored. Recipients who appear in the [SMTP] envelope but do not Recipients who appear in the [SMTP] envelope but do not appear in
appear in headers are considered "blind" (Bcc) recipients; such headers are considered "blind" (Bcc) recipients; such recipients MUST
recipients MUST NOT be added to message headers (including address NOT be added to message headers (including address and trace headers)
and trace headers) unless there is only one recipient total. unless there is only one recipient total.
Gellens [Page 17] Expires April 2006
Sender address Sender address
The 'From:' header MUST be retained. The 'From:' header MUST be retained.
Content type Content type
The complete 'Content-Type:' header (including any parameters) The complete 'Content-Type:' header (including any parameters) SHOULD
SHOULD be preserved. be preserved.
Message class Message class
An 'X-Mms-Message-Class: personal' header MAY be created for all An 'X-Mms-Message-Class: personal' header MAY be created for all
received messages with a non-null return path (MAIL FROM value in received messages with a non-null return path (MAIL FROM value in the
the SMTP envelope). An 'X-Mms-Message-Class: auto' header MAY be SMTP envelope). An 'X-Mms-Message-Class: auto' header MAY be created
created for messages with a null return path. for messages with a null return path.
Time of Expiry Time of Expiry
An 'X-Mms-Expiry:' header SHOULD be created if the message contains An 'X-Mms-Expiry:' header SHOULD be created if the message contains a
a relative time to expiration in the DELIVER-BY extension with a relative time to expiration in the DELIVER-BY extension with a by-
by-mode of "R", as specified in [Deliver-By]. mode of "R", as specified in [Deliver-By].
If the by-mode is "N", a "relayed" DSN MUST be issued per 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. [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 Delivery report request
An 'X-Mms-Delivery-Report:' header SHOULD be created for messages An 'X-Mms-Delivery-Report:' header SHOULD be created for messages
which request 'success' or 'none' delivery status notification by that request 'success' or 'none' delivery status notification by use
use of the DSN extension as specified in [DSN-SMTP]. Requests for of the DSN extension as specified in [DSN-SMTP]. Requests for
'delay' notifications or non-default actions, such as that only the 'delay' notifications or non-default actions, such as that only the
message headers should be returned, cannot be mapped onto MMS message headers should be returned, cannot be mapped onto MMS headers
headers and thus SHOULD be ignored. and thus SHOULD be ignored.
Importance Importance
The message sender's importance value (also called "priority", The message sender's importance value (also called "priority",
although this can be confused with class-of-service values) is although this can be confused with class-of-service values) is
expressed with an 'Importance:' header. Historically, some clients expressed with an 'Importance:' header. Historically, some clients
used the older and non-standard 'X-Priority:' header for this used the older and non-standard 'X-Priority:' header for this
purpose. As a result, some clients generate both. purpose. As a result, some clients generate both.
Gellens [Page 18] Expires April 2006
An 'X-Priority:' or 'Importance:' header, if present, SHOULD be An 'X-Priority:' or 'Importance:' header, if present, SHOULD be
replaced with an 'X-Mms-Priority:' header. If both headers are replaced with an 'X-Mms-Priority:' header. If both headers are
present, 'Importance:' SHOULD be used. Suggested mappings: present, 'Importance:' SHOULD be used. Suggested mappings are shown
in Table 3:
2.1.3.3.1 Table 4: Priority Mappings (Internet Message to MMS) 2.1.3.3.1. Table 3: Priority Mappings (Internet Message to MMS)
-------------------------------|---------------------- -------------------------------|----------------------
'X-Priority: 1 (highest)' |'X-Mms-Priority: High' 'X-Priority: 1 (highest)' |'X-Mms-Priority: High'
-------------------------------|---------------------- -------------------------------|----------------------
'X-Priority: 2 (high)' |'X-Mms-Priority: High' 'X-Priority: 2 (high)' |'X-Mms-Priority: High'
-------------------------------|---------------------- -------------------------------|----------------------
'Importance: High' |'X-Mms-Priority: High' 'Importance: High' |'X-Mms-Priority: High'
-------------------------------|---------------------- -------------------------------|----------------------
'X-Priority: 3 (normal)' | [omitted] 'X-Priority: 3 (normal)' | [omitted]
-------------------------------|---------------------- -------------------------------|----------------------
skipping to change at line 828 skipping to change at page 17, line 46
-------------------------------|---------------------- -------------------------------|----------------------
Normal importance messages SHOULD omit the 'X-Mms-Priority:' header. Normal importance messages SHOULD omit the 'X-Mms-Priority:' header.
Sender visibility Sender visibility
Support for sender address hiding is not currently supported. Support for sender address hiding is not currently supported.
Read reply request Read reply request
A request for a read reply contained in a A request for a read reply contained in a 'Disposition-Notification-
'Disposition-Notification-To:' header as specified in [MDN] SHOULD To:' header as specified in [MDN] SHOULD be replaced with an 'X-Mms-
be replaced with an 'X-Mms-Read-Reply:' header. Read-Reply:' header.
Subject Subject
The 'Subject:' header MUST be preserved. The 'Subject:' header MUST be preserved.
Resending Resending
Mapping from 'Resent-' and other [Msg-Fmt] headers to Mapping from 'Resent-' and other [Msg-Fmt] headers to 'X-Mms-
'X-Mms-Previously-Sent-' headers SHOULD be done as follows: 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 The original 'From:' header is mapped to an 'X-Mms-Previously-Sent-
mapped to an 'X-Mms-Previously-Sent-By:' header with the next larger By:' header with a leading "0" value. The value of the top-most
leading value. '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 The original 'Date:' header is mapped to an 'X-Mms-Previously-Sent-
'X-Mms-Previously-Sent-Date-and-Time:' header with a leading "0" Date-and-Time:' header with a leading "0" value. Note that the value
value. Note that the value is also converted from date-time syntax is also converted from date-time syntax [Msg-Fmt] to HTTP-date syntax
[Msg-Fmt] to HTTP-date syntax [HTTP]. The value of the top-most [HTTP]. The value of the top-most 'Resent-Date:' header is mapped to
'Resent-Date:' header is mapped to the 'Date:' header. The value of the 'Date:' header. The value of each subsequent 'Date:' header is
each subsequent 'Date:' header is mapped to an mapped to an 'X-Mms-Previously-Sent-Date-and-Time:' header with the
'X-Mms-Previously-Sent-Date-and-Time:' header with the next larger next larger leading value.
leading value.
If one or more 'Resent-Message-ID:' headers are present, the If one or more 'Resent-Message-ID:' headers are present, the top-most
top-most one SHOULD be mapped to 'Message-ID:'; otherwise the one SHOULD be mapped to 'Message-ID:'; otherwise, the 'Message-ID:'
'Message-ID:' header should be retained. header should be retained.
An 'X-Mms-Forward-Counter:' header SHOULD be created when 'Resent-' An 'X-Mms-Forward-Counter:' header SHOULD be created when 'Resent-'
headers have been mapped to 'X-Mms-Previously-Sent-' headers. Its headers have been mapped to 'X-Mms-Previously-Sent-' headers. Its
value SHOULD be the number of 'Resent-' blocks that existed prior to value SHOULD be the number of 'Resent-' blocks that existed prior to
mapping. mapping.
Example: Example:
The original message: The original message:
skipping to change at line 887 skipping to change at page 19, line 4
Is resent by Colonel Corn to L. Eva Message: Is resent by Colonel Corn to L. Eva Message:
Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800 Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800
Resent-From: Colonel Corn <gcorn@example.mil> Resent-From: Colonel Corn <gcorn@example.mil>
Resent-To: L. Eva Message <lem@example.org> Resent-To: L. Eva Message <lem@example.org>
Resent-Message-ID: <msg234@mail.example.mil> Resent-Message-ID: <msg234@mail.example.mil>
Date: Fri, 1 Apr 2005 14:02:03 -0800 Date: Fri, 1 Apr 2005 14:02:03 -0800
From: General Failure <mfail@example.mil> From: General Failure <mfail@example.mil>
To: Colonel Corn <gcorn@example.mil> To: Colonel Corn <gcorn@example.mil>
Message-ID: <msg123@mail.example.mil> Message-ID: <msg123@mail.example.mil>
L. Eva then resends to her MMS device: L. Eva then resends to her MMS device:
Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800 Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800
Resent-From: L. Eva Message <lem@example.org> Resent-From: L. Eva Message <lem@example.org>
Resent-To: b1ff@mms.example.com Resent-To: b1ff@mms.example.com
Resent-Message-ID: <99887766.112233@mail.example.org> Resent-Message-ID: <99887766.112233@mail.example.org>
Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800 Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800
Resent-From: Colonel Corn <gcorn@example.mil> Resent-From: Colonel Corn <gcorn@example.mil>
Gellens [Page 20] Expires April 2006
Resent-To: L. Eva Message <lem@example.org> Resent-To: L. Eva Message <lem@example.org>
Resent-Message-ID: <msg234@mail.example.mil> Resent-Message-ID: <msg234@mail.example.mil>
Date: Fri, 1 Apr 2005 14:02:03 -0800 Date: Fri, 1 Apr 2005 14:02:03 -0800
From: General Failure <mfail@example.mil> From: General Failure <mfail@example.mil>
To: Colonel Corn <gcorn@example.mil> To: Colonel Corn <gcorn@example.mil>
Message-ID: <msg123@mail.example.mil> Message-ID: <msg123@mail.example.mil>
This would be mapped to an MMS message as: This would be mapped to an MMS message as:
X-Mms-Forward-Counter: 2 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-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-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-Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT
X-Mms-Previously-Sent-By: 1, Colonel Corn <gcorn@example.mil> X-Mms-Previously-Sent-By: 1, Colonel Corn <gcorn@example.mil>
Date: Fri, 1 Apr 2005 18:02:03 -0800 Date: Fri, 1 Apr 2005 18:02:03 -0800
From: L. Eva Message <lem@example.org> From: L. Eva Message <lem@example.org>
To: b1ff@mms.example.com To: b1ff@mms.example.com
Message-ID: <99887766.112233@mail.example.org> Message-ID: <99887766.112233@mail.example.org>
Note that the original 'From:' and 'Date:' values were moved to Note that the original 'From:' and 'Date:' values were moved to 'X-
'X-Mms-Previously-Sent-By:' and Mms-Previously-Sent-By:' and 'X-Mms-Previously-Sent-Date-and-Time:'
'X-Mms-Previously-Sent-Date-and-Time:' headers with a leading "0" headers with a leading "0" value. The first 'Resent-From:' and
value. The first 'Resent-From:' and 'Resent-Date:' values were 'Resent-Date:' values were moved to a second set of 'X-Mms-
moved to a second set of 'X-Mms-Previously-Sent-' headers, with a Previously-Sent-' headers, with a leading "1" value. The third set
leading "1" value. The third set of 'Resent-' headers were moved to of 'Resent-' headers were moved to the 'Date:', 'To:', and 'From:'
the 'Date:', 'To:', and 'From:' headers. headers.
Note also that the format of the date and time differs between the Note also that the format of the date and time differs between the
'Date:' / 'Resent-Date:' and the 'Date:' / 'Resent-Date:' and the 'X-Mms-Previously-Sent-Date-and-
'X-Mms-Previously-Sent-Date-and-Time:' headers, in that the latter Time:' headers, in that the latter use HTTP-date [HTTP] instead of
use HTTP-date [HTTP] instead of date-time [Msg-Fmt]. date-time [Msg-Fmt].
'Received:' Headers 'Received:' Headers
Each system that processes a message SHOULD add a 'Received:' header Each system that processes a message SHOULD add a 'Received:' header
as per [SMTP]. A message MAY be rejected if the number of as per [SMTP]. A message MAY be rejected if the number of
'Received:' headers exceeds a locally-defined maximum, which MUST 'Received:' headers exceeds a locally-defined maximum, which MUST
conform to [SMTP] section 6.2 and SHOULD be no less than 100. conform to [SMTP] Section 6.2 and SHOULD be no less than 100.
Sensitivity Sensitivity
The 'Sensitivity:' header field (value = "personal" or "private") The 'Sensitivity:' header field (value = "personal" or "private")
[VPIM] indicates the desire of a voice message originator to send [VPIM] indicates the desire of a voice message originator to send the
the message contents to the original recipient list with assurance message contents to the original recipient list with assurance that
that the message will not be forwarded further by either the the message will not be forwarded further by either the messaging
messaging system or the actual message recipient(s). Since system or the actual message recipient(s). Since sensitivity is not
sensitivity is not an MMS feature, any messages which contain a an MMS feature, any messages that contain a 'Sensitivity:' header
'Sensitivity:' header MUST NOT be sent to an MMS system. The MUST NOT be sent to an MMS system. The associated negative delivery
associated negative delivery status report MUST include the extended status report MUST include the extended status code [RESP] 5.6.0 as
specified in [VPIM] ("Other or undefined protocol status") indicating
Gellens [Page 21] Expires April 2006 that privacy could not be ensured.
status code [RESP] 5.6.0 as specified in [VPIM] ("Other or undefined
protocol status") indicating that privacy could not be assured.
Content Content
The message content appears in the message body. The message content appears in the message body.
2.1.4 Report Generation and Conversion 2.1.4. Report Generation and Conversion
Internet Message systems use the multipart/report MIME type for Internet message systems use the multipart/report MIME type for
delivery and disposition reports as specified in [Report-Fmt]. This delivery and disposition reports as specified in [Report-Fmt]. This
format is a two- or three-part MIME message; one part is a format is a two- or three-part MIME message; one part is a structured
structured format describing the event being reported in an format describing the event being reported in an easy-to-parse
easy-to-parse format. Specific reports have a format which is built format. Specific reports have a format that is built on
on [Report-Fmt]. Delivery reports are specified in [DSN-Msg]. [Report-Fmt]. Delivery reports are specified in [DSN-Msg]. Message
Message disposition reports, which include read reports, are disposition reports, which include read reports, are specified in
specified in [MDN]. [MDN].
By contrast, MMS reports are plain text, with no defined structure By contrast, MMS reports are plain text, with no defined structure
specified. This makes it difficult to convert from an MMS report to specified. This makes it difficult to convert from an MMS report to
a standard Internet report. a standard Internet report.
An implementation conforming to this specification MUST convert An implementation conforming to this specification MUST convert
reports received from one side (MMS or Internet mail) destined for reports received from one side (MMS or Internet mail) destined for
the other. In addition, reports MUST be generated as appropriate the other. In addition, reports MUST be generated as appropriate for
for messages received from either side. For example, if an MM to be messages received from either side. For example, if an MM to be sent
sent via Internet mail is not deliverable, a delivery status MM via Internet mail is not deliverable, a delivery status MM shall be
shall be generated. Likewise, if an Internet message is received generated. Likewise, if an Internet message is received that cannot
that cannot be further relayed or delivered, a delivery status be further relayed or delivered, a delivery status report [DSN-Msg]
report [DSN-Msg] MUST be generated. MUST be generated.
When creating delivery or disposition reports from MMS reports, the When creating delivery or disposition reports from MMS reports, the
MMS report should be parsed to determine the reported event and MMS report should be parsed to determine the reported event and time,
time, status, and the headers of the referenced (original) message. status, and the headers of the referenced (original) message. These
These elements, once determined, are used to populate the subparts elements, once determined, are used to populate the subparts of the
of the delivery or disposition report. The first subpart is of type delivery or disposition report. The first subpart is of type
text/plain, and contains a human-readable explanation of the event. text/plain, and contains a human-readable explanation of the event.
This text may include a statement that the report was synthesized This text may include a statement that the report was synthesized
based on an MMS report. The second subpart is of type based on an MMS report. The second subpart is of type
report/delivery-status (for delivery reports) or report/delivery-status (for delivery reports) or report/disposition-
report/disposition-notification (for disposition reports). This notification (for disposition reports). This second part contains a
second part contains a structured itemization of the event. The structured itemization of the event. The optional third subpart is
optional third subpart is of type message/rfc822 and includes the of type message/rfc822 and includes the headers and optionally the
headers and optionally the body of the referenced (original) body of the referenced (original) message. Note that, per [DSN-Msg],
message. Note that, per [Dsn-Msg], the 'DSN-Gateway:' field in the 'DSN-Gateway:' field in delivery reports MUST be created.
delivery reports MUST be created.
Gellens [Page 22] Expires April 2006
2.1.4.1 Delivery Report Mapping from MMS to Internet Message 2.1.4.1. Delivery Report Mapping from MMS to Internet Message
The following table maps information elements from MMS delivery Below, Table 4 maps information elements from MMS delivery reports to
reports to the format specified in [DSN-Msg]. the format specified in [DSN-Msg].
2.1.4.1.1 Table 5: Delivery Report Mappings (MMS to Internet Message) 2.1.4.1.1. Table 4: Delivery Report Mappings (MMS to Internet Message)
======================|============|=================================== ======================|============|===================================
Information Element |MMS Delivery|[DSN-Msg] Element Information Element |MMS Delivery|[DSN-Msg] Element
|Report Elem | |Report Elem |
======================|============|=================================== ======================|============|===================================
ID of message whose |Message-Id: |'Message-ID:' preserved in third ID of message whose |Message-Id: |'Message-ID:' preserved in third
delivery status is | |subpart of delivery report. delivery status is | |subpart of delivery report.
being reported | | being reported | |
----------------------|------------|----------------------------------- ----------------------|------------|-----------------------------------
Recipient address of |From: |'Final-Recipient' field of the Recipient address of |From: |'Final-Recipient' field of the
the original message | |per-recipient section. the original message | |per-recipient section.
(object of delivery | | (object of delivery | |
report) | | report) | |
----------------------|------------|----------------------------------- ----------------------|------------|-----------------------------------
Destination address of|To: |'To:' header field value of top- Destination address of|To: |'To:' header field value of top-
report | |level. report | |level.
----------------------|------------|----------------------------------- ----------------------|------------|-----------------------------------
Date and time the |Date: |'Date:' header field value of top- Date and time the |Date: |'Date:' header field value of top-
message was handled | |level message was handled | |level.
======================|============|=================================== ----------------------|------------|-----------------------------------
Gellens [Page 23] Expires April 2006
======================|============|=================================== ======================|============|===================================
Information Element |MMS Delivery|[DSN-Msg] Element Information Element |MMS Delivery|[DSN-Msg] Element
|Report Elem | |Report Elem |
======================|============|=================================== ======================|============|===================================
Delivery status of |X-Mms- |Action and Status fields of Delivery status of |X-Mms- |Action and Status fields of
original message to | Status: |per-recipient section. original message to | Status: |per-recipient section.
each recipient | | each recipient | |
| |The 'Action' field indicates if the | |The 'Action' field indicates if the
| |message was delivered. | |message was delivered.
| | | |
| |For failed delivery an appropriate | |For failed delivery, an appropriate
| |'Status' value shall be included | |'Status' value shall be included
| |per [DSN-Msg]. | |per [DSN-Msg].
| | | |
| |The Action field is set to one of | |The Action field is set to one of
| |the following values: | |the following values:
| | | |
| |* delivered (used for MMS status | |* delivered (used for MMS status
| |values 'retrieved' and 'rejected', | |values 'retrieved' and 'rejected',
| |depending on 'Status' code). | |depending on 'Status' code).
| | | |
skipping to change at line 1061 skipping to change at page 22, line 38
| | | |
| |* delayed MAY be used for MMS | |* delayed MAY be used for MMS
| |status value 'deferred' | |status value 'deferred'
| | | |
| |* relayed (used for MMS status | |* relayed (used for MMS status
| |value 'indeterminate') | |value 'indeterminate')
| | | |
| |* expanded (SHOULD NOT be used) | |* expanded (SHOULD NOT be used)
----------------------|------------|----------------------------------- ----------------------|------------|-----------------------------------
Status Text | |Text in first part (human-readable Status Text | |Text in first part (human-readable
| |part) | |part).
----------------------|------------|----------------------------------- ----------------------|------------|-----------------------------------
When an MMS Relay/Server generates a [DSN-Msg] in response to a When an MMS Relay/Server generates a [DSN-Msg] in response to a
message received using [SMTP] on MM3: message received using [SMTP] on MM3:
* Top-level header field 'To:' SHOULD be the [SMTP] return-path of * Top-level header field 'To:' SHOULD be the [SMTP] return-path of
the message whose status is being reported. the message whose status is being reported.
* Top-level header field 'From:' SHOULD be the address of the * Top-level header field 'From:' SHOULD be the address of the
recipient that the delivery-report concerns. recipient that the delivery-report concerns.
* The first part of the [DSN-Msg] SHOULD include the MM Status Text * The first part of the [DSN-Msg] SHOULD include the MM Status Text
field that would have been generated for an MM1 delivery-report. field that would have been generated for an MM1 delivery-report.
Gellens [Page 24] Expires April 2006
2.1.4.2 Delivery Report Mapping from Internet Message to MMS 2.1.4.2 Delivery Report Mapping from Internet Message to MMS
The following table maps information elements from a delivery report Below, Table 5 maps information elements from a delivery report as
as specified in [DSN-Msg] to the format of an MMS delivery report. specified in [DSN-Msg] to the format of an MMS delivery report. Note
Note that a single DSN which reports multiple recipients will result that a single DSN that reports multiple recipients will result in
in several MMS delivery reports. several MMS delivery reports.
2.1.4.2.1 Table 6: Delivery Report Mappings (Internet Message to MMS) 2.1.4.2.1. Table 5: Delivery Report Mappings (Internet Message to MMS)
===================|==================|================================ ===================|==================|================================
Information Element|MMS Delivery |[DSN-Msg] Element Information Element|MMS Delivery |[DSN-Msg] Element
|Report Element | |Report Element |
===================|==================|================================ ===================|==================|================================
ID of the original |Message-Id: |'Message-ID:' header preserved ID of the original |Message-Id: |'Message-ID:' header preserved
message (object of | |in third sub-part of report. message (object of | |in third sub-part of report.
delivery report) | | delivery report) | |
-------------------|------------------|-------------------------------- -------------------|------------------|--------------------------------
Recipient address |From: |If available, the 'Original Recipient address |From: |If available, the 'Original
of the original | |-Recipient' field of the per- of the original | |-Recipient' field of the per-
message (object of | |recipient section should be message (object of | |recipient section should be
delivery report) | |used; otherwise the 'Final- delivery report) | |used; otherwise, the 'Final-
| |Recipient' field of the per- | |Recipient' field of the per-
| |recipient section is used | |recipient section is used.
-------------------|------------------|-------------------------------- -------------------|------------------|--------------------------------
Destination address|To: |'To:' header field value of Destination address|To: |'To:' header field value of
of report | |top-level. of report | |top-level.
| | | |
| |Value taken from [SMTP] envelope | |Value taken from [SMTP] envelope
| |return-path of message being | |return-path of message being
| |reported, not its 'From:' header | |reported, not its 'From:' header
| |field. | |field.
===================|==================|================================ -------------------|------------------|--------------------------------
Date and time the |Date: |'Date:' header field value of
Gellens [Page 25] Expires April 2006 message was handled| |top-level.
-------------------|------------------|--------------------------------
===================|==================|================================ ===================|==================|================================
Information Element|MMS Delivery |[DSN-Msg] Element Information Element|MMS Delivery |[DSN-Msg] Element
|Report 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 Delivery status of |X-Mms-Status: |'Action' and 'Status' fields of
original message | |per-recipient section original message | |per-recipient section.
|Set to one of the | |Set to one of the |
|following values: | |following values: |
| | | |
|'retrieved' (used | |'retrieved' (used |
|for 'Action' value| |for 'Action' value|
|'delivered'). | |'delivered'). |
| | | |
|'unreachable' | |'unreachable' |
|(used for 'Action'| |(used for 'Action'|
|value 'failed') | |value 'failed') |
skipping to change at line 1144 skipping to change at page 24, line 33
|for 'Action' value| |for 'Action' value|
|'relayed') | |'relayed') |
| | | |
|'deferred' MUST | |'deferred' MUST |
|NOT be used | |NOT be used |
|(ignore DSNs with | |(ignore DSNs with |
|'Action' value | |'Action' value |
|'delayed') | |'delayed') |
-------------------|------------------|-------------------------------- -------------------|------------------|--------------------------------
Status Text | |Text in first part (human- Status Text | |Text in first part (human-
| |readable part) | |readable part).
===================|==================|================================ ===================|==================|================================
Gellens [Page 26] Expires April 2006 2.1.4.3. Read Report Mapping from MMS to Internet Message
2.1.4.3 Read Report Mapping from MMS to Internet Message
The following table maps information elements from MMS read reports Below, Table 6 maps information elements from MMS read reports to the
to the format specified in [MDN]. format specified in [MDN].
2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet Message) 2.1.4.3.1. Table 6: Read Report Mappings (MMS to Internet Message)
======================|============|=================================== ======================|============|===================================
Information Element |MMS Delivery|[MDN] Element Information Element |MMS Delivery|[MDN] Element
|Report Elem | |Report Elem |
======================|============|=================================== ======================|============|===================================
ID of the original |Message-Id: |'Message-ID:' header preserved in ID of the original |Message-Id: |'Message-ID:' header preserved in
message (object of | |third part of report. message (object of | |third part of report.
read report) | | read report) | |
----------------------|------------|----------------------------------- ----------------------|------------|-----------------------------------
Recipient address of |From: |'Final-Recipient' field Recipient address of |From: |'Final-Recipient' field.
the original message | | the original message | |
======================|============|===================================
Information Element |MMS Delivery|[MDN] Element
|Report Elem |
======================|============|===================================
Destination address of|To: |'To:' header field value of top- Destination address of|To: |'To:' header field value of top-
report | |level. report | |level.
| | | |
| |Value taken from 'Disposition- | |Value taken from 'Disposition-
| |Notification-To:' header field of | |Notification-To:' header field of
| |message being reported, not its | |message being reported, not its
| |'From:' header field. | |'From:' header field.
----------------------|------------|----------------------------------- ----------------------|------------|-----------------------------------
Date and time the |Date: |'Date:' header field value of top- Date and time the |Date: |'Date:' header field value of top-
message was handled | |level message was handled | |level.
----------------------|------------|----------------------------------- ----------------------|------------|-----------------------------------
Disposition of message|X-Mms-Read- |Disposition-field Disposition of message|X-Mms-Read- |Disposition-field
being reported | Status: | being reported | Status: |
| |For X-MMS-Read-Status value 'read', | |For X-MMS-Read-Status value 'read',
| |use 'disposition-type' value | |use 'disposition-type' value
| |'displayed'; for X-MMS-Read-Status | |'displayed'; for X-MMS-Read-Status
| |value 'Deleted without being read', | |value 'Deleted without being read',
| |use 'disposition-type' value | |use 'disposition-type' value
| |'deleted') | |'deleted').
----------------------|------------|----------------------------------- ----------------------|------------|-----------------------------------
Status Text | |Text in first part (human-readable Status Text | |Text in first part (human-readable
| |part) | |part).
======================|============|=================================== ======================|============|===================================
When an MMS Relay/Server generates an [MDN] in response to a message When an MMS Relay/Server generates an [MDN] in response to a message
received using [SMTP] on MM3: received using [SMTP] on MM3:
* Top-level header field 'To:' SHOULD be the value of the * Top-level header field 'To:' SHOULD be the value of the
'Disposition-Notification-To:' header field of the message whose 'Disposition-Notification-To:' header field of the message whose
disposition is being reported . disposition is being reported .
Gellens [Page 27] Expires April 2006
* Top-level header field 'From:' SHOULD be the address of the * Top-level header field 'From:' SHOULD be the address of the
recipient that the read report concerns. recipient that the read report concerns.
2.1.4.4 Disposition Report Mapping from Internet Message to MMS 2.1.4.4. Disposition Report Mapping from Internet Message to MMS
The following table maps information elements from a disposition Below, Table 7 maps information elements from a disposition report as
report as specified in [MDN] to the format of an MMS read report. specified in [MDN] to the format of an MMS read report.
2.1.4.4.1 Table 8: Disposition Report Mappings (Internet Message to 2.1.4.4.1. Table 7: Disposition Report Mappings
MMS) (Internet Message to MMS)
===================|==================|================================ ===================|==================|================================
Information Element|MMS Read Report |[MDN] Element Information Element|MMS Read Report |[MDN] Element
|Element | |Element |
===================|==================|================================ ===================|==================|================================
ID of the original |Message-Id: |'Message-ID:' header preserved ID of the original |Message-Id: |'Message-ID:' header preserved
message (object of | |in third subpart of report. message (object of | |in third subpart of report.
disposition report)| | disposition report)| |
-------------------|------------------|-------------------------------- -------------------|------------------|--------------------------------
Recipient address |From: |'Final-Recipient' field Recipient address |From: |'Final-Recipient' field.
of the original | | of the original | |
message | | message | |
-------------------|------------------|-------------------------------- -------------------|------------------|--------------------------------
Destination address|To: |'To:' header field value of Destination address|To: |'To:' header field value of
of report | |top-level. of report | |top-level.
| | | |
| |Value taken from 'Disposition- | |Value taken from 'Disposition-
| |Notification-To:' header field | |Notification-To:' header field
| |of message being reported, not | |of message being reported, not
| |its 'From:' header field. | |its 'From:' header field.
-------------------|------------------|-------------------------------- -------------------|------------------|--------------------------------
Date and time the |Date: |'Date:' header field value of Date and time the |Date: |'Date:' header field value of
message was handled| |top-level message was handled| |top-level.
===================|==================|================================ -------------------|------------------|--------------------------------
Disposition of |X-Mms-Read-Status:|disposition-field.
Gellens [Page 28] Expires April 2006
===================|==================|================================
Information Element|MMS Read Report |[MDN] Element
|Element |
===================|==================|================================
Disposition of |X-Mms-Read-Status:|disposition-field
message being | | message being | |
reported |Set to one of the | reported |Set to one of the |
|following values: | |following values: |
| | | |
|'read' (used for | |'read' (used for |
|disposition-type | |disposition-type |
|value 'displayed')| |value 'displayed')|
| | | |
|'Deleted without | |'Deleted without |
|being read' (used | |being read' (used |
|for disposition- | |for disposition- |
|types 'deleted', | |types 'deleted', |
|'denied' and | |'denied' and |
|'failed' when | |'failed' when |
|action-mode is | |action-mode is |
|'automatic- | |'automatic- |
|action') | |action') |
-------------------|------------------|-------------------------------- -------------------|------------------|--------------------------------
Status Text | |Text in first part (human- Status Text | |Text in first part (human-
| |readable part) | |readable part).
===================|==================|================================ ===================|==================|================================
2.1.5 Message Delivery 2.1.5. Message Delivery
Within Internet mail, when [SMTP] is used and delivery reports are Within Internet mail, when [SMTP] is used and delivery reports are
requested [DSN-SMTP], delivery is considered to be acceptance of a requested [DSN-SMTP], delivery is considered to be acceptance of a
message by the final server, that is, the server closest to the message by the final server, that is, the server closest to the
recipient. When an MMS Relay/Server receives a message using [SMTP] recipient. When an MMS Relay/Server receives a message using [SMTP]
and a delivery report is requested, the MMS Relay/Server MAY and a delivery report is requested, the MMS Relay/Server MAY consider
consider the message delivered when it has been sent to the MMS User the message delivered when it has been sent to the MMS User Agent.
Agent.
3 Security Considerations 3. Security Considerations
Both MMS and Internet mail have their own set of security risks and Both MMS and Internet mail have their own set of security risks and
considerations. This document specifies how to exchange messages considerations. This document specifies how to exchange messages
between these two environments, so it is only appropriate to discuss between these two environments, so it is only appropriate to discuss
considerations specific to this functionality, not those inherent in considerations specific to this functionality, not those inherent in
either environment. either environment.
Gellens [Page 29] Expires April 2006
When a message uses end-to-end security mechanisms such as [PGP] or When a message uses end-to-end security mechanisms such as [PGP] or
S/MIME [SMIME], servers MUST be careful not to accidently destroy S/MIME [SMIME], servers MUST be careful not to accidently destroy the
the integrity of the protected content (for example, by altering any integrity of the protected content (for example, by altering any text
text within the region covered by a signature while mapping between within the region covered by a signature while mapping between MMS
MMS and email). [Mime-Sec-gw] discusses issues with use of such and email). [Mime-Sec-gw] discusses issues with use of such
mechanisms in gateways. mechanisms in gateways.
Some MMS features contain inherently more risk than others, Some MMS features contain inherently more risk than others, including
including reply charging and sender address hiding. Support for reply charging and sender address hiding. Support for these
these mechanisms are not included in this document. mechanisms is not included in this document.
4 IANA Considerations 4. IANA Considerations
IANA is requested to add "MMS" as a "WITH protocol types" under its IANA has added "MMS" as one of the "WITH protocol types" under its
"MAIL Parameters" registry. The description is "Multimedia "MAIL Parameters" registry. The description is "Multimedia Messaging
Messaging Service"; the reference is to this document. Service"; the reference is to this document.
5 Acknowledgments 5. Acknowledgements
A number of people contributed to this document, especially the A number of people contributed to this document, especially the
members of the IETF Lemonade group, including Greg Vaudreuil. John members of the IETF Lemonade working group, including Greg Vaudreuil.
Klensin did a very thorough and helpful review. Greg White caught a John Klensin did a very thorough and helpful review. Greg White
large number of nits. Ted Hardie was very helpful. Alexey Melnikov caught a large number of nits. Ted Hardie was very helpful. Alexey
and Chris Newman sent very useful and detailed comments. Melnikov and Chris Newman sent very useful and detailed comments.
6 Normative References
IETF:
[DSN-Msg] "An Extensible Message Format for Delivery Status 6. Normative References
Notifications", Moore, Vaudreuil, RFC 3464, January 2003.
[DSN-SMTP] "SMTP Service Extension for Delivery Status [DSN-Msg] Moore, K. and G. Vaudreuil, "An Extensible Message
Notifications", Moore, RFC 3461, January 2003. Format for Delivery Status Notifications", RFC 3464,
January 2003.
[Hdr-Enc] "MIME (Multipurpose Internet Mail Extensions) Part Three: [DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP)
Message Header Extensions for Non-ASCII Text", Moore, RFC 2047, Service Extension for Delivery Status Notifications
November 1996. (DSNs)", RFC 3461, January 2003.
[HTTP] "Hypertext Transfer Protocol -- HTTP/1.1", Fielding et al, [Hdr-Enc] Moore, K., "MIME (Multipurpose Internet Mail
RFC 2616, June 1999. Extensions) Part Three: Message Header Extensions for
Non-ASCII Text ", RFC 2047, November 1996.
[IDN] "Internationalizing Domain Names in Applications (IDNA)", [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Faltstrom, Hoffman, Costello, RFC 3490, March 2003. Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
Gellens [Page 30] Expires April 2006 [IDN] Faltstrom, P., Hoffman, P., and A. Costello,
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate "Internationalizing Domain Names in Applications
Requirement Levels", RFC 2119, Harvard University, March 1997. (IDNA)", RFC 3490, March 2003.
[MDN] "Message Disposition Notification", Hansen, Vaudreuil, RFC [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
3798, May 2004. Requirement Levels", BCP 14, RFC 2119, March 1997.
[Msg-Fmt] "Internet Message Format", Resnick, RFC 2822, April 2001. [MDN] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004.
[Report-Fmt] "The Multipart/Report Content Type for the Reporting of [Msg-Fmt] Resnick, P., "Internet Message Format", RFC 2822, April
Mail System Administrative Messages", Vaudreuil, RFC 3462, January 2001.
2003
[RESP] "Enhanced Mail System Status Codes", Vaudreuil, RFC 3463, [Report-Fmt] Vaudreuil, G., "The Multipart/Report Content Type for
January 2003. the Reporting of Mail System Administrative Messages",
RFC 3462, January 2003.
[SMTP] "Simple Mail Transfer Protocol", Klensin, RFC 2821, April [RESP] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
2001. 3463, January 2003.
OMA: [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
OMA specifications are available at the OMA web site [OMA] OMA specifications are available at the OMA web site
<http://www.openmobilealliance.org>. <http://www.openmobilealliance.org>.
[OMA-MMS] OMA-WAP-MMS-ENC-V1_2-20040323-C [OMA-MMS] OMA-WAP-MMS-ENC-V1_2-20040323-C
3GPP2 and 3GPP: [3GPP2] 3GPP2 specifications are available at the 3GPP2 (Third
3GPP2 specifications are available at the 3GPP2 (Third
Generation Partnership Project 2) web site Generation Partnership Project 2) web site
<http://www.3gpp2.org>. <http://www.3gpp2.org>.
3GPP specifications are available at the 3GPP (Third Generation [3GPP] 3GPP specifications are available at the 3GPP (Third
Partnership Project) web site <http://www.3gpp.org> Generation Partnership Project) web site
<http://www.3gpp.org>
[Stage_3] "MMS MM1 Stage 3 using OMA/WAP", X.S0016-310 [Stage_3] "MMS MM1 Stage 3 using OMA/WAP", X.S0016-310
"MMS MM4 Stage 3 Inter-Carrier Interworking", X.S0016-340 "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: "Multimedia Messaging Service: Functional description;
Stage 2", TS 23.140 Release 5.
Gellens [Page 31] Expires April 2006 7. Informative References
[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", [BINARY] Vaudreuil, G., "SMTP Service Extensions for
Freed, RFC 2034, October 1996. Transmission of Large and Binary MIME Messages", RFC
3030, December 2000.
[Deliver-By] "Deliver By SMTP Service Extension", Newman, RFC 2852, [Deliver-By] Newman, D., "Deliver By SMTP Service Extension", RFC
June 2000. 2852, June 2000.
[Hdrs] "Common Internet Message Headers", J. Palme, RFC 2076, [Hdrs] Palme, J., "Common Internet Message Headers", RFC 2076,
February 1997. February 1997.
[Mime-Sec-gw] "Gateways and MIME Security Multiparts", N. Freed, RFC [Mime-Sec-gw] Freed, N., "Gateways and MIME Security Multiparts", RFC
2480, January 1999. 2480, January 1999.
[PGP] "MIME Security with OpenPGP", Elkins, Del Torto, Levien, [PGP] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
Roessler, RFC 3156, August 2001 "MIME Security with OpenPGP", RFC 3156, August 2001.
[SMIME] "S/MIME Version 3 Message Specification", Ramsdell, RFC
2633, June 1999
[Submission] "Message Submission", Gellens, Klensin, RFC 2476, [SMIME] Ramsdell, B., "Secure/Multipurpose Internet Mail
December 1998. Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[VPIM] "Voice Profile for Internet Mail - version 2 (VPIMv2)", [Submission] Gellens, R. and J. Klensin, "Message Submission", RFC
Vaudreuil, Parsons, RFC 3801, June 2004. 2476, December 1998.
[Formats] "Multimedia Messaging Service (MMS) Media Format and [VPIM] Vaudreuil, G. and G. Parsons, "Voice Profile for
Codecs for cdma2000 Spread Spectrum Systems", C.S0045 Internet Mail - version 2 (VPIMv2)", RFC 3801, June
2004.
[Overview] "Multimedia Messaging Services (MMS) Overview", [Overview] "Multimedia Messaging Services (MMS) Overview",
X.S0016-000 X.S0016-000
[Stage_1] "Multimedia Messaging Services (MMS); Stage 1", [Stage_1] "Multimedia Messaging Services (MMS); Stage 1",
Requirements, October 2002, S.R0064-0. Requirements, October 2002, S.R0064-0.
[Stage_2] "Multimedia Messaging Service (MMS); Stage 2", Functional [Stage_2] "Multimedia Messaging Service (MMS); Stage 2",
Specification, April 2003, X.S0016-200. Functional Specification, April 2003, X.S0016-200.
"Multimedia Messaging Service; Media formats and codecs", "Multimedia Messaging Service; Media formats and
TS26.140Release 5. codecs", TS26.140Release 5.
8 Author's Address Author's Address
Randall Gellens Randall Gellens
QUALCOMM Incorporated QUALCOMM Incorporated
5775 Morehouse Drive 5775 Morehouse Drive
San Diego, CA 92121 San Diego, CA 92121
Gellens [Page 32] Expires April 2006 EMail: randy@qualcomm.com
randy@qualcomm.com
Appendix A: Changes Since Last Version
[ This section to be deleted upon publication ] Full Copyright Statement
Changes from -05 to -06: Copyright (C) The Internet Society (2006).
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: This document is subject to the rights, licenses and restrictions
o Abstract now mentions use of X-MMS-* headers in MMS. contained in BCP 78, and except as set forth therein, the authors
o Deleted "(MAY set to locally-generated value to hide sender retain all their rights.
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 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 Statement Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the procedures with respect to rights in RFC on the procedures with respect to rights in RFC documents can be
documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Full Copyright Statement Acknowledgement
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 Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 195 change blocks. 
576 lines changed or deleted 436 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/