draft-ietf-lemonade-mms-mapping-00.txt   draft-ietf-lemonade-mms-mapping-01.txt 
Internet Draft: Mapping Between MMS and Internet Mail R. Gellens Internet Draft: Mapping Between MMS and Internet Mail R. Gellens
Document: draft-ietf-lemonade-mms-mapping-00.txt Qualcomm Document: draft-ietf-lemonade-mms-mapping-01.txt Qualcomm
Expires: January 2005 July 2004 Expires: April 2005 October 2004
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, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed patent or other IPR claims of which I am aware have been disclosed
and any of which I become aware will be disclosed, in accordance and any of which I become aware will be disclosed, in accordance
with RFC 3668 (BCP 79). with RFC 3668 (BCP 79).
skipping to change at line 45 skipping to change at line 45
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
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 which are similar to, but differ in key ways from those
used in Internet mail. used in Internet mail.
Gellens [Page 1] Expires January 2005 Gellens [Page 1] Expires April 2005
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 ESMTP and Internet message headers. from that used in ESMTP and Internet message headers.
Gellens [Page 2] Expires January 2005 Gellens [Page 2] Expires April 2005
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Conventions Used in this Document . . . . . . . . . . . . 4 1.2 Conventions Used in this Document . . . . . . . . . . . . 4
1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 1.5 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6
2 Mapping Between MMS and Internet Mail . . . . . . . . . . . . 6 2 Mapping Between MMS and Internet Mail . . . . . . . . . . . . 6
2.1 Mapping Specification . . . . . . . . . . . . . . . . . . 6 2.1 Mapping Specification . . . . . . . . . . . . . . . . . . 6
2.1.1 MMS to Internet Mail . . . . . . . . . . . . . . . . . 6 2.1.1 MMS to Internet Mail . . . . . . . . . . . . . . . . . 6
2.1.2 Internet Mail to MMS . . . . . . . . . . . . . . . . 6 2.1.2 Internet Mail to MMS . . . . . . . . . . . . . . . . 7
2.1.3 MMS Information Element Mappings . . . . . . . . . . . 7 2.1.3 MMS Information Element Mappings . . . . . . . . . . . 7
2.1.3.1 Table 1: MM3 Mappings . . . . . . . . . . . . . . 8 2.1.3.1 Table 1: MM3 Mappings . . . . . . . . . . . . . . 8
2.1.3.2 Conversion of messages from MMS to Internet format 10 2.1.3.2 Conversion of messages from MMS to Internet format 10
2.1.3.2.1 Table 2: Importance Mappings (MMS to Internet 13 2.1.3.2.1 Table 2: Importance Mappings (MMS to Internet 14
2.1.3.2.2 Table 3: X-Priority Mappings (MMS to Internet 13 2.1.3.2.2 Table 3: X-Priority Mappings (MMS to Internet 14
2.1.3.3 Conversion of messages from Internet to MMS format 16 2.1.3.3 Conversion of messages from Internet to MMS format 17
2.1.3.3.1 Table 4: Priority Mappings (Internet Message t 18 2.1.3.3.1 Table 4: Priority Mappings (Internet Message t 19
2.1.4 Report Generation and Conversion . . . . . . . . . . 19 2.1.4 Report Generation and Conversion . . . . . . . . . . 20
2.1.4.1 Delivery Report Mapping from MMS to Internet Messa 20 2.1.4.1 Delivery Report Mapping from MMS to Internet Messa 21
2.1.4.1.1 Table 5: Delivery Report Mappings (MMS to Inte 20 2.1.4.1.1 Table 5: Delivery Report Mappings (MMS to Inte 21
2.1.4.2 Delivery Report Mapping from Internet Message to M 22 2.1.4.2 Delivery Report Mapping from Internet Message to M 23
2.1.4.2.1 Table 6: Delivery Report Mappings (Internet Me 22 2.1.4.2.1 Table 6: Delivery Report Mappings (Internet Me 23
2.1.4.3 Read Report Mapping from MMS to Internet Message . 23 2.1.4.3 Read Report Mapping from MMS to Internet Message . 24
2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet 23 2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet 25
2.1.4.4 Disposition Report Mapping from Internet Message t 24 2.1.4.4 Disposition Report Mapping from Internet Message t 26
2.1.4.4.1 Table 8: Disposition Report Mappings (Internet 24 2.1.4.4.1 Table 8: Disposition Report Mappings (Internet 26
2.1.5 Message Delivery . . . . . . . . . . . . . . . . . . . 25 2.1.5 Message Delivery . . . . . . . . . . . . . . . . . . . 27
3 Security Considerations . . . . . . . . . . . . . . . . . . . 25 3 Security Considerations . . . . . . . . . . . . . . . . . . . 27
4 Normative References . . . . . . . . . . . . . . . . . . . . . 27 4 Normative References . . . . . . . . . . . . . . . . . . . . . 29
5 Informative References . . . . . . . . . . . . . . . . . . . 28 5 Informative References . . . . . . . . . . . . . . . . . . . 30
6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 29 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property Statement . . . . . . . . . . . . . . . 29 Intellectual Property Statement . . . . . . . . . . . . . . . 31
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 32
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1 Introduction 1 Introduction
1.1 Scope 1.1 Scope
This specification describes how to exchange messages with Internet This document describes how to exchange messages with Internet mail
mail systems. This includes translation between MMS (as defined by systems. This includes translation between MMS (as defined by
3GPP/3GPP2/OMA) and Internet Mail messages using Extended Simple 3GPP/3GPP2/OMA) and Internet Mail messages using Extended Simple
Mail Transfer Protocol [SMTP] and Internet message format [Msg-Fmt]. Mail Transfer Protocol [SMTP] and Internet message format [Msg-Fmt].
This also includes translation between delivery and disposition This also includes translation between delivery and disposition
reports as used in MMS and in Internet mail ([DSN-Msg] and [MDN]). reports as used in MMS and in Internet mail ([DSN-Msg] and [MDN]).
Gellens [Page 3] Expires January 2005 Gellens [Page 3] Expires April 2005
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; which 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
Voice Profile for Internet Mail [VPIM]. The VPIM specification
allows voice messages to be exchanged between voice mail systems
using Internet mail format [Msg-Fmt] and transported via Extended
Simple Mail Transfer Protocol [SMTP]. Thus, the MMS MM3 interface
supports the ability to exchange voice messages between an MMS
system and a voice mail system. Note that such use is distinct from
voice media being part of a user-composed multimedia message.
Note that MM3 can also be used for interworking with "external" 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. Sender address hiding may be used but is not recommended charging. Sender address hiding may be used but is not recommended
without security assurances which are beyond the scope of this without security assurances which are beyond the scope of this
skipping to change at line 139 skipping to change at line 148
Note that in the text of this document, a distinction is made Note that in the text of this document, a distinction is made
between use of "SMTP" or "Simple Mail Transfer Protocol", and between use of "SMTP" or "Simple Mail Transfer Protocol", and
"ESMTP" or "Extended Simple Mail Transfer Protocol": when the term "ESMTP" or "Extended Simple Mail Transfer Protocol": when the term
"ESMTP" or "Extended" is used, it indicates use of extended features "ESMTP" or "Extended" is used, it indicates use of extended features
of SMTP; that is, those beyond the facilities of RFC 821. (These of SMTP; that is, those beyond the facilities of RFC 821. (These
extended facilities may be in RFC 2821 or in other RFCs, as extended facilities may be in RFC 2821 or in other RFCs, as
indicated by the specific RFC reference used; note that the name of indicated by the specific RFC reference used; note that the name of
the RFC 2821 reference is "SMTP" because that is the official title the RFC 2821 reference is "SMTP" because that is the official title
of the RFC.) of the RFC.)
Gellens [Page 4] Expires April 2005
1.3 Definitions 1.3 Definitions
--------------------|---------------------------------------------- --------------------|----------------------------------------------
Anonymous Remailer |A service which accepts messages and resends Anonymous Remailer |A service which accepts messages and resends
|them to their intended recipient, masking |them to their intended recipient, masking
|information about the original sender. |information about the original sender.
--------------------|---------------------------------------------- --------------------|----------------------------------------------
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
Gellens [Page 4] Expires January 2005
|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 their 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).
--------------------|---------------------------------------------- --------------------|----------------------------------------------
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
skipping to change at line 185 skipping to change at line 194
|(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.
--------------------|---------------------------------------------- --------------------|----------------------------------------------
Gateway Function |An agent which acts as both MMSC and MTA Gateway Function |An agent which acts as both MMSC and MTA
|and/or MSA. |and/or MSA.
--------------------|---------------------------------------------- --------------------|----------------------------------------------
User Agent |An MMS or Email user agent User Agent |An MMS or Email user agent
--------------------|---------------------------------------------- --------------------|----------------------------------------------
Gellens [Page 5] Expires April 2005
1.4 Abbreviations 1.4 Abbreviations
--------|---------------------------------------------------------- --------|----------------------------------------------------------
ESMTP |Extended Simple Mail Transfer Protocol. The use of ESMTP |Extended Simple Mail Transfer Protocol. The use of
|features and capabilities added to SMTP since RFC 821. |features and capabilities added to SMTP since RFC 821.
--------|---------------------------------------------------------- --------|----------------------------------------------------------
MSA |Message Submission Agent. A server which accepts messages MSA |Message Submission Agent. A server which 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.
--------|---------------------------------------------------------- --------|----------------------------------------------------------
MTA |Mail Transfer Agent. A server which implements [SMTP]. MTA |Mail Transfer Agent. A server which implements [SMTP].
--------|---------------------------------------------------------- --------|----------------------------------------------------------
Gellens [Page 5] Expires January 2005
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
skipping to change at line 233 skipping to change at line 242
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] (for example, use of a null return-path the requirements of [SMTP] (for example, use of a null return-path
for automatically-generated messages). for automatically-generated messages).
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 ESMTP values) needed for the transfer protocol. header fields and ESMTP values) needed for the transfer protocol.
Gellens [Page 6] Expires April 2005
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 Message header fields and ESMTP values. Internet Message header fields and ESMTP values.
Delivery and read report MMs SHOULD be converted to standard Delivery and read report MMs SHOULD be converted to standard
Internet Message report format (multipart/report). In addition to Internet Message report format (multipart/report). In addition to
converting Internet Message reports, the MMS Relay/Server MUST converting Internet Message reports, the MMS Relay/Server MUST
generate delivery and read report MMs for received messages as generate delivery and read report MMs for received messages as
appropriate. See section 2.1.4 for more information. appropriate. See section 2.1.4 for more information.
2.1.2 Internet Mail to MMS 2.1.2 Internet Mail to MMS
Gellens [Page 6] Expires January 2005
When receiving a message from an Internet mail system the MMS When receiving a message from an Internet mail system the MMS
Relay/Server MAY convert incoming messages to the MM format used Relay/Server MAY convert incoming messages to the MM format used
within the receiving system. within the receiving system.
The MMS Relay/Server MAY convert control information received from The MMS Relay/Server MAY convert control information received from
the Internet mail server into appropriate information elements of an the Internet mail server into appropriate information elements of an
MM. 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 Message header fields and ESMTP values. Internet Message header fields and ESMTP 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, the MMS Relay/Server MUST addition to converting report MMs, the MMS Relay/Server MUST
generate standard Internet Message delivery and disposition reports generate standard Internet Message delivery and disposition reports
for received Internet messages as appropriate. See section 2.1.4 for received Internet messages as appropriate. See section 2.1.4
for more information. for more information.
Gellens [Page 7] Expires January 2005 Gellens [Page 7] Expires April 2005
2.1.3 MMS Information Element Mappings 2.1.3 MMS Information Element Mappings
The mappings between MMS elements and ESMTP/Internet Message The mappings between MMS elements and ESMTP/Internet Message
elements (either [SMTP] parameters, [Msg-Fmt] headers, or both) are elements (either [SMTP] parameters, [Msg-Fmt] headers, or both) are
summarized in the table below, and detailed in subsequent sections. summarized in the table 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 which need to be mapped are listed. [Msg-Fmt] headers not
listed here SHOULD be passed unaltered listed here SHOULD be passed unaltered
skipping to change at line 308 skipping to change at line 317
|MUST set MAIL |to hide sender | |MUST set MAIL |to hide sender |
|FROM to null |identity in | |FROM to null |identity in |
|("<>") for all |anonymous mes- | |("<>") for all |anonymous mes- |
|automatically- |sages when | |automatically- |sages when |
|generated MMs |receiving sys- | |generated MMs |receiving sys- |
| |tem does not | | |tem does not |
| |support anony- | | |support anony- |
| |mous messages) | | |mous messages) |
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Content type |N/A |Content-Type: |Content-type: Content type |N/A |Content-Type: |Content-type:
_________________|_________________|________________|______________ | | |
Message class |Class=auto: |MAY set 'Prece |X-Mms-Message- | |For voice mes- |
|MUST set MAIL | dence: bulk' | Class: | |sages compliant |
|FROM to null |on class=auto | | |to [VPIM], see |
|("<>"). | | | |Note 2 |
=================|=================|================|============== =================|=================|================|==============
Gellens [Page 8] Expires January 2005 Gellens [Page 8] Expires April 2005
=================|=================|================|============== =================|=================|================|==============
Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header
=================|=================|================|============== =================|=================|================|==============
Message class |Class=auto: |MAY set 'Prece |X-Mms-Message-
|MUST set MAIL | dence: bulk' | Class:
|FROM to null |on class=auto |
|("<>"). | |
_________________|_________________|________________|______________
Date and time |N/A |Date: |Date: Date and time |N/A |Date: |Date:
of submission | | | of submission | | |
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Time of expiry |DELIVER-BY |N/A |X-Mms-Expiry: Time of expiry |DELIVER-BY |N/A |X-Mms-Expiry:
|[Deliver-By] | | |[Deliver-By] | |
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Earliest deliv- |(only for submis-|N/A |X-Mms-Delivery Earliest deliv- |(only for submis-|N/A |X-Mms-Delivery
ery time |sion; not relay) | | -Time: ery time |sion; not relay) | | -Time:
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Delivery report |DSN [DSN-SMTP] |N/A |X-Mms-Delivery Delivery report |DSN [DSN-SMTP] |N/A |X-Mms-Delivery
skipping to change at line 358 skipping to change at line 372
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:
_________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply-
usage request |supported) |supported) | Charging-
| | | Id:
=================|=================|================|============== =================|=================|================|==============
Gellens [Page 9] Expires January 2005 Gellens [Page 9] Expires April 2005
=================|=================|================|============== =================|=================|================|==============
Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header Information Elem |RFC 2821 Element |RFC 2822 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-
| | | Id:
_________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply-
usage reference |supported) |supported) | Charging: usage reference |supported) |supported) | Charging:
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Subject |N/A |Subject: |Subject: Subject |N/A |Subject: |Subject:
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Forward counter |N/A |Resent-Count: |(Not sup- Forward counter |N/A |Resent-Count: |(Not sup-
| | |ported) | | |ported)
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Previously-sent- |N/A |Resent-From: |X-Mms-Previous Previously-sent- |N/A |Resent-From: |X-Mms-Previous
by | | | ly-Sent-By: by | | | ly-Sent-By:
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Previously-sent- |N/A |Resent-Date: |X-Mms- Previously-sent- |N/A |Resent-Date: |X-Mms-
date and-time | | | Previously- date and-time | | | Previously-
| | | Sent-Date: | | | Sent-Date:
_________________|_________________|________________|______________ _________________|_________________|________________|______________
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
| |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
privacy requested by the message originator (values are ”personal‘
or ”private‘); a message recipient MUST NOT forward a message with a
'Sensitivity' header.
Note 2: A MIME-Version header with a comment of ”Voice 2.0‘
indicates that the voice message conforms to [VPIM].
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-Version:' header, if present, SHOULD be removed. The 'X-Mms-Version:' header, if present, SHOULD be removed.
Gellens [Page 10] Expires April 2005
Message Type (of PDU) Message Type (of PDU)
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
An 'X-Mms-Message-Id:' header, if present, SHOULD be retained. An 'X-Mms-Message-Id:' header, if present, SHOULD be retained.
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. If an 'X-Mms-Message-Id:' header be created, with a unique value. If an 'X-Mms-Message-Id:' header
is present and a 'Message-Id:' header is not, the value of the is present and a 'Message-Id:' header is not, the value of the
'X-Mms-Message-Id:' header MAY be used in creating the 'Message-Id:' 'X-Mms-Message-Id:' header MAY be used in creating the 'Message-Id:'
header. header.
Gellens [Page 10] Expires January 2005
The message ID SHOULD be transmitted in the ESMTP envelope as the The message ID SHOULD be transmitted in the ESMTP envelope as the
ENVID parameter, as specified in [DSN-SMTP]. ENVID parameter, as specified in [DSN-SMTP].
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:' or 'Cc:' appear in a 'To:' or 'Cc:' header. At least one 'To:' or 'Cc:'
header MUST be present. If all recipients are undisclosed, a 'To:' header MUST be present. If all recipients are undisclosed, a 'To:'
header MAY be created that contains a comment, for example 'To: header MAY be created that contains a comment, for example 'To:
skipping to change at line 444 skipping to change at line 469
characters, but in the absence of such an extension [Hdr-Enc] MUST characters, but in the absence of such an extension [Hdr-Enc] MUST
be used. be used.
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, unless address hiding has been requested. If address hiding header, unless address hiding has been requested. If address hiding
has been requested, the 'From:' header MAY contain a comment to this has been requested, the 'From:' header MAY contain a comment to this
effect, for example, 'From: (anonymous sender)'. effect, for example, 'From: (anonymous sender)'.
Gellens [Page 11] Expires April 2005
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 SMTP ('X-Mms-Message-Class: Personal') SHOULD be transmitted in the SMTP
envelope as the MAIL FROM value unless address hiding has been envelope as the MAIL FROM value unless address hiding has been
requested and the receiving server is not known and trusted to requested and the receiving server is not known and trusted to
support address hiding. support address hiding.
The 'From:' header and the MAIL FROM value MAY be set to a The 'From:' header and the MAIL FROM value MAY be set to a
locally-generated value to hide the sender identity in anonymous locally-generated value to hide the sender identity in anonymous
messages when the receiving system does not support anonymous messages when the receiving system does not support anonymous
messages. Locally generated addresses MAY be internally mapped to messages. Locally generated addresses MAY be internally mapped to
the actual address to allow replies to anonymous messages, but such the actual address to allow replies to anonymous messages, but such
mapping is beyond the scope of this specification. mapping is beyond the scope of this specification.
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.
Gellens [Page 11] Expires January 2005
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 addresses. Other characters (for example, characters be present in addresses. Other characters (for example,
non-7-bit characters in a phrase part of an address header) MUST be non-7-bit characters in a phrase part of an address header) MUST be
encoded according to [Hdr-Enc]. Note that it would be possible to encoded according to [Hdr-Enc]. Note that it would be possible to
define an SMTP extension to permit transmission of unencoded 8-bit define an SMTP extension to permit transmission of unencoded 8-bit
characters, but in the absence of such an extension [Hdr-Enc] MUST characters, but in the absence of such an extension [Hdr-Enc] MUST
be used. be 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. Content types not The 'Content-Type:' header SHOULD be preserved. Content types not
in widespread use in the Internet MAY be converted into those that in widespread use in the Internet MAY be converted into those that
are, when such conversion can be done without significant loss of are, when such conversion can be done without significant loss of
content. For example, SMIL messages MAY be converted into content. For example, SMIL messages MAY be converted into
widely-supported multipart/related with multipart/html. widely-supported multipart/related with multipart/html. When such
conversion is done, the 'Content-Type:' header MUST be updated if it
is no longer correct.
Message class Message class
The 'X-Mms-Message-Class:' header MAY be retained. A 'Precedence: The 'X-Mms-Message-Class:' header MAY be retained. A 'Precedence:
bulk' header MAY be inserted for class=auto or class=advertisement. bulk' header MAY be inserted for class=auto or class=advertisement.
See 'Sender Address' above. (Class=personal and class=informational See 'Sender Address' above. (Class=personal and class=informational
do not require special handling.) do not require special handling.)
Gellens [Page 12] Expires April 2005
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 ESMTP envelope by using the DELIVER-BY extension, transmitted in the ESMTP envelope by using the DELIVER-BY extension,
as specified in [Deliver-By]. as specified in [Deliver-By].
Note that the ESMTP DELIVER-BY extension carries time remaining Note that the ESMTP 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
skipping to change at line 510 skipping to change at line 538
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, not message relay feature.
Gellens [Page 12] Expires January 2005
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 ESMTP envelope by using the DSN extension as transmitted in the ESMTP 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 the NOTIFY extension is used, the unaltered recipient address When the NOTIFY extension is used, the unaltered recipient address
SHOULD be transmitted as the ORCPT value, and the original message SHOULD be transmitted as the ORCPT value, and the original message
ID SHOULD be transmitted as the ENVID value. ID SHOULD be transmitted as the ENVID value.
skipping to change at line 537 skipping to change at line 564
be transmitted using an 'Importance:' header (although currently not be transmitted using an 'Importance:' header (although currently not
all Internet mail clients support this header). all Internet mail clients support this header).
An 'X-Priority:' header MAY be used in addition. Although not An 'X-Priority:' header MAY be used in addition. Although not
standardized, most email applications support the 'X-Priority:' standardized, most email applications support the 'X-Priority:'
header, and use an 'X-Priority' value of 3 for messages with header, and use an 'X-Priority' value of 3 for messages with
"normal" priority. More important messages have lower values and "normal" priority. More important messages have lower values and
less important message have higher values. In most cases, urgent less important message have higher values. In most cases, urgent
messages have an X-Priority value of 1. messages have an X-Priority value of 1.
Gellens [Page 13] Expires April 2005
Suggested mappings: Suggested mappings:
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'
skipping to change at line 561 skipping to change at line 589
2.1.3.2.2 Table 3: X-Priority Mappings (MMS to Internet Message) 2.1.3.2.2 Table 3: X-Priority Mappings (MMS to Internet Message)
---------------------------|---------------------- ---------------------------|----------------------
'X-Mms-Priority: High' |'X-Priority: 2 (high)' 'X-Mms-Priority: High' |'X-Priority: 2 (high)'
---------------------------|---------------------- ---------------------------|----------------------
'X-Mms-Priority: Normal |[omit] 'X-Mms-Priority: Normal |[omit]
---------------------------|---------------------- ---------------------------|----------------------
'X-Mms-Priority: Low |'X-Priority: 4 (low)' 'X-Mms-Priority: Low |'X-Priority: 4 (low)'
---------------------------|---------------------- ---------------------------|----------------------
Gellens [Page 13] Expires January 2005
Normal priority messages SHOULD omit the 'X-Priority:' header. Normal priority messages SHOULD omit the 'X-Priority:' 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
Requests for sender address hiding may be transmitted in the ESMTP Requests for sender address hiding may be transmitted in the ESMTP
envelope by using the X-ANONYMOUS extension. The request is made by envelope by using the X-ANONYMOUS extension. The request is made by
adding "X-ANONYMOUS" to the MAIL FROM command. Servers which adding "X-ANONYMOUS" to the MAIL FROM command. Servers which
support address hiding may advertise this by including X-ANONYMOUS support address hiding may advertise this by including X-ANONYMOUS
skipping to change at line 585 skipping to change at line 612
no technical guarantee that it will be properly honored; servers no technical guarantee that it will be properly honored; servers
MUST NOT trust other servers to support this without a basis which MUST NOT trust other servers to support this without a basis which
is beyond the scope of this specification (such as business is beyond the scope of this specification (such as business
relationships). relationships).
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
Gellens [Page 14] Expires April 2005
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 both user agent and server support. Misapplied reply requiring both user agent and server support. Misapplied reply
charging may cause incorrect billing. Until the security issues charging may cause incorrect billing. Until the security issues
skipping to change at line 611 skipping to change at line 639
('X-Mms-Reply-Charging-Id:' and 'X-Mms-Reply-Charging: accepted' or ('X-Mms-Reply-Charging-Id:' and 'X-Mms-Reply-Charging: accepted' or
'X-Mms-Reply-Charging: accepted (text only)' headers) SHOULD be 'X-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. Current Internet message
format requires that only 7-bit US-ASCII characters be present. format requires that only 7-bit US-ASCII characters be present.
Other characters must be encoded according to [Hdr-Enc]. Note that Other characters must be encoded according to [Hdr-Enc]. Note that
it would be possible to define an SMTP extension to permit it would be possible to define an SMTP extension to permit
Gellens [Page 14] Expires January 2005
transmission of unencoded 8-bit characters, but in the absence of transmission of unencoded 8-bit characters, but in the absence of
such an extension [Hdr-Enc] must be used. such an extension [Hdr-Enc] must be used.
Resending/Forwarding Resending/Forwarding
In MMS a message may be resent or forwarded, the difference being In MMS a message may be resent or forwarded, the difference being
that if the message has been downloaded then sending it to another that if the message has been downloaded then sending it to another
address is considered forwarding, while sending a message that has address is considered forwarding, while sending a message that has
not been downloaded is considered to be resending. not been downloaded is considered to be resending.
skipping to change at line 636 skipping to change at line 662
original message, either simply embedded within the text, or original message, either simply embedded within the text, or
delineated. Embedded messages generally have each original line delineated. Embedded messages generally have each original line
preceded by a quote symbol ('>'), surround the original text with a preceded by a quote symbol ('>'), surround the original text with a
preceding and trailing line which starts with hyphens as per preceding and trailing line which starts with hyphens as per
[Msg-Encap], such as '--- begin forwarded text' and '--- end [Msg-Encap], such as '--- begin forwarded text' and '--- end
forwarded text', or encapsulate the original message as a forwarded text', or encapsulate the original message as a
'message/rfc822' content type, perhaps within a 'multipart/mixed' 'message/rfc822' content type, perhaps within a 'multipart/mixed'
message. (This last method offers more robust delineation.) message. (This last method offers more robust delineation.)
Resending is when the original message is unaltered except for the Resending is when the original message is unaltered except for the
addition of 'Resent-' headers to explain the resending to the new addition of 'Resent-' headers to explain the resending to the new
Gellens [Page 15] Expires April 2005
recipient. recipient.
A message may be resent more than once; each time new 'Resent-' A message may be resent more than once; each time new 'Resent-'
headers SHOULD be added at the top of the message. Thus, if more headers SHOULD be added at the top of the message. Thus, if more
than one series of 'Resent-' headers are present, the original than one series of 'Resent-' headers are present, the original
series is the last; the most recent is the first. series is the last; the most recent is the first.
Forward counter Forward counter
The 'Resent-Count:' header MAY be used to track the number of times The 'Resent-Count:' header MAY be used to track the number of times
skipping to change at line 662 skipping to change at line 690
A 'Resent-From:' header MAY be added to indicate the address of the A 'Resent-From:' header MAY be added to indicate the address of the
user who directed the message to be resent. user who directed the message to be resent.
A 'Resent-Date:' header SHOULD be added to indicate the time and A 'Resent-Date:' header SHOULD be added to indicate the time and
date that the message was resent. date that the message was resent.
Any 'X-Mms-Previously-Sent-By:' and 'X-Mms-Previously-Sent-Date' Any 'X-Mms-Previously-Sent-By:' and 'X-Mms-Previously-Sent-Date'
headers, if present, SHOULD be removed. The information contained headers, if present, SHOULD be removed. The information contained
in them SHOULD be translated into 'From:', 'Resent-To:', in them SHOULD be translated into 'From:', 'Resent-To:',
'Resent-From:', 'Resent-Date:', and 'Resent-Count:' headers. The 'Resent-From:', 'Resent-Date:', and 'Resent-Count:' headers. The
Gellens [Page 15] Expires January 2005
original sender of the message SHOULD appear in the 'From:' header; original sender of the message SHOULD appear in the 'From:' header;
the original recipient(s) SHOULD appear in the 'To:' header; the the original recipient(s) SHOULD appear in the 'To:' header; the
time and date the message was originally sent SHOULD appear in the time and date the message was originally sent SHOULD appear in the
'Date:' header. The most recent sender SHOULD appear in the 'Date:' header. The most recent sender SHOULD appear in the
top-most 'Resent-From:' header; the most recent recipient(s) SHOULD top-most 'Resent-From:' header; the most recent recipient(s) SHOULD
appear in the top-most 'Resent-To:' header; the time and date the appear in the top-most 'Resent-To:' header; the time and date the
message was most recently sent SHOULD appear in the top-most message was most recently sent SHOULD appear in the top-most
'Resent-Date:' header. 'Resent-Date:' header.
'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.
Privacy
Note that MMS systems do not currently support the 'Privacy' header
field as described by [VPIM].
Gellens [Page 16] Expires April 2005
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 CR LF, thus message format requires that line-endings be encoded as CR LF, thus
charset encodings that do not have this property cannot be used in charset encodings that do not have this property cannot be used in
text/* body parts. (They MAY be used in other body parts, but only text/* body parts. (They MAY be used in other body parts, but only
when they are suitable encoded or when binary transmission has been when they are suitable encoded or when binary transmission has been
negotiated.) In particular, MMS allows UTF-16, while Internet negotiated.) In particular, MMS allows UTF-16, while Internet
message format does not. UTF-16 encoding MUST be transcoded to message format does not. UTF-16 encoding MUST be translated to
UTF-8 or another charset and encoding which is suitable for use in UTF-8 or another charset and encoding which is suitable for use in
Internet message format/protocols. 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-Mms-Version:' header SHOULD be added. An 'X-Mms-Mms-Version:' header SHOULD be added.
Message Type (of PDU) Message Type (of PDU)
skipping to change at line 710 skipping to change at line 742
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 specific MMS interface (e.g., MM1, MM4). the 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
Gellens [Page 16] Expires January 2005
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. If the 'Message-Id:' header does be created, with a unique value. If the 'Message-Id:' header does
not exist, but the SMTP envelop contains an ENVID value (as not exist, but the SMTP envelop contains an ENVID value (as
specified in [DSN-SMTP]), it MAY be used to construct the value. specified in [DSN-SMTP]), it MAY be used to construct the 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) MUST Each recipient contained in the SMTP envelope (RCPT TO values) MUST
be considered a recipient of the message. Recipients who appear in be considered a recipient of the message. Recipients who appear in
address headers but not the SMTP envelope MUST be ignored. address headers but not the SMTP envelope MUST be ignored.
Recipients who appear in the [SMTP] envelope but do not appear in Recipients who appear in the [SMTP] envelope but do not appear in
headers are considered "blind" (Bcc) recipients; such recipients headers are considered "blind" (Bcc) recipients; such recipients
MUST NOT be added to message headers (including address and trace MUST NOT be added to message headers (including address and trace
headers) unless there is only one recipient total. headers) unless there is only one recipient total.
Gellens [Page 17] Expires April 2005
Sender address Sender address
The 'From:' header MUST be retained. The 'From:' header MUST be retained.
If address hiding has been requested, the 'From:' header MAY contain If address hiding has been requested, the 'From:' header MAY contain
a comment to this effect, for example, 'From: (anonymous sender)'. a comment to this effect, for example, 'From: (anonymous sender)'.
Content type Content type
The complete 'Content-Type:' header (including any parameters) The complete 'Content-Type:' header (including any parameters)
skipping to change at line 760 skipping to change at line 792
a relative time to expiration in the DELIVER-BY extension, as a relative time to expiration in the DELIVER-BY extension, as
specified in [Deliver-By]. specified in [Deliver-By].
Earliest delivery time Earliest delivery time
An 'X-Mms-Delivery-Time:' header SHOULD NOT be created. If a An 'X-Mms-Delivery-Time:' header SHOULD NOT be created. If a
message arrives via ESMTP relay containing an earliest time of message arrives via ESMTP relay containing an earliest time of
delivery in the AFTER extension, it MAY be rejected. If a message delivery in the AFTER extension, it MAY be rejected. If a message
is submitted via Message Submission [Submission] containing an is submitted via Message Submission [Submission] containing an
earliest time of delivery in the AFTER extension, it MUST either be earliest time of delivery in the AFTER extension, it MUST either be
Gellens [Page 17] Expires January 2005
retained until the delivery time arrives, or it may be immediately retained until the delivery time arrives, or it may be immediately
rejected. It MUST NOT be delivered or further relayed prior to the rejected. It MUST NOT be delivered or further relayed prior to the
delivery time. delivery time.
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 which request 'success' or 'none' delivery status notification by
use of the DSN extension as specified in [DSN-SMTP]. Requests for use 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 and thus SHOULD be ignored. headers and thus SHOULD be ignored.
Priority Priority
Gellens [Page 18] Expires April 2005
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. Suggested mappings: replaced with an 'X-Mms-Priority:' header. Suggested mappings:
2.1.3.3.1 Table 4: Priority Mappings (Internet Message to MMS) 2.1.3.3.1 Table 4: 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'
-------------------------------|---------------------- -------------------------------|----------------------
skipping to change at line 810 skipping to change at line 841
Normal priority messages SHOULD omit the 'X-Mms-Priority:' header. Normal priority messages SHOULD omit the 'X-Mms-Priority:' header.
Sender visibility Sender visibility
Requests for sender address hiding MAY be received in the SMTP Requests for sender address hiding MAY be received in the SMTP
envelope by the X-ANONYMOUS extension. Servers which support envelope by the X-ANONYMOUS extension. Servers which support
address hiding MAY advertise this by including X-ANONYMOUS in their address hiding MAY advertise this by including X-ANONYMOUS in their
EHLO response. A message received which includes X-ANONYMOUS in the EHLO response. A message received which includes X-ANONYMOUS in the
MAIL FROM command has requested address hiding. MAIL FROM command has requested address hiding.
Gellens [Page 18] Expires January 2005
Note that even if servers claim to support address hiding, there is Note that even if servers claim to support address hiding, there is
no technical guarantee that it will be properly honored; servers no technical guarantee that it will be properly honored; servers
SHOULD NOT trust other servers to support this without a basis which SHOULD NOT trust other servers to support this without a basis which
is beyond the scope of this specification (such as business is beyond the scope of this specification (such as business
relationships). relationships).
Requests for sender address hiding MAY be reflected in the created Requests for sender address hiding MAY be reflected in the created
MM by adding an 'X-Mms-Sender-Visibility:' header. MM by adding an 'X-Mms-Sender-Visibility:' header.
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-To:' header as specified in [MDN] SHOULD 'Disposition-Notification-To:' header as specified in [MDN] SHOULD
be replaced with an 'X-Mms-Read-Reply:' header. be replaced with an 'X-Mms-Read-Reply:' header.
Gellens [Page 19] Expires April 2005
Subject Subject
The 'Subject:' header MUST be preserved. The 'Subject:' header MUST be preserved.
Resending/Forwarding Resending/Forwarding
One or more sets of 'Resent-' headers, if present, SHOULD be mapped One or more sets of 'Resent-' headers, if present, SHOULD be mapped
to 'To:', 'From:', 'Date:', and 'X-Mms-Previously-Sent-' headers. to 'To:', 'From:', 'Date:', and 'X-Mms-Previously-Sent-' headers.
'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
The 'Sensitivity:' header field (value = ”personal‘ or ”private‘)
[VPIM] indicates the desire of a voice message originator to send
the message contents to the original recipient list with assurance
that the message will not be forwarded further by either the
messaging system or the actual message recipient(s). Since
sensitivity is not an MMS feature, any messages which contain a
'Sensitivity:' header SHOULD NOT be sent to an MMS system. An
appropriate extended error response code [RESP] SHOULD be used in
the associated negative delivery status report.
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 (often called "read reports") as delivery and disposition reports (often called "read reports") as
specified in [Report-Fmt]. This format is a two- or three-part MIME specified in [Report-Fmt]. This format is a two- or three-part MIME
message; one part is a structured format describing the event being message; one part is a structured format describing the event being
reported in an easy-to-parse format. Specific reports have a format reported in an easy-to-parse format. Specific reports have a format
which is built on [Report-Fmt]. Delivery reports are specified in which is built on [Report-Fmt]. Delivery reports are specified in
[DSN-Msg]. Message disposition reports, which include read reports, [DSN-Msg]. Message disposition reports, which include read reports,
are specified in [MDN]. are specified in [MDN].
Gellens [Page 19] Expires January 2005
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.
Gellens [Page 20] Expires April 2005
An MMS Relay/Server supporting Internet Message exchange using MM3 An MMS Relay/Server supporting Internet Message exchange using MM3
MUST convert reports received from one side (MMS or Internet mail) MUST convert reports received from one side (MMS or Internet mail)
destined for the other. In addition, reports MUST be generated as destined for the other. In addition, reports MUST be generated as
appropriate for messages received from either side of the MM3 appropriate for messages received from either side of the MM3
interface. For example, if an MM to be sent via MM3 is not interface. For example, if an MM to be sent via MM3 is not
deliverable, a delivery status MM shall be generated. Likewise, if deliverable, a delivery status MM shall be generated. Likewise, if
an Internet message is received via MM3 that cannot be further an Internet message is received via MM3 that cannot be further
relayed or delivered, a delivery status report [DSN-Msg] MUST be relayed or delivered, a delivery status report [DSN-Msg] MUST be
generated. generated.
skipping to change at line 906 skipping to change at line 949
======================|============|=================================== ======================|============|===================================
ID of message whose |Message-Id: |'Original-Envelope-ID' field of ID of message whose |Message-Id: |'Original-Envelope-ID' field of
delivery status is | |per-message fields (use value of delivery status is | |per-message fields (use value of
being reported | |ENVID from ESMTP envelope if avail- being reported | |ENVID from ESMTP envelope if avail-
| |able, 'Message-ID:' otherwise). | |able, 'Message-ID:' otherwise).
----------------------|------------|----------------------------------- ----------------------|------------|-----------------------------------
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) | |
======================|============|===================================
Gellens [Page 20] Expires January 2005 Gellens [Page 21] Expires April 2005
======================|============|===================================
Information Element |MMS Delivery|[DSN-Msg] 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 [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 top- Date and time the |Date: |'Date:' header field value of top-
message was handled | |level message was handled | |level
skipping to change at line 953 skipping to change at line 1000
| | | |
| |* 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)
----------------------|------------|----------------------------------- ----------------------|------------|-----------------------------------
Gellens [Page 22] Expires April 2005
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:
Gellens [Page 21] Expires January 2005
* 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.
2.1.4.2 Delivery Report Mapping from Internet Message to MMS 2.1.4.2 Delivery Report Mapping from Internet Message to MMS
skipping to change at line 999 skipping to change at line 1046
| |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.
===================|==================|===================================
Gellens [Page 23] Expires April 2005
===================|==================|================================
Information Element|MMS Delivery |[DSN=Msg] Element
|Report Element |
===================|==================|================================
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
-------------------|------------------|-------------------------------- -------------------|------------------|--------------------------------
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
Gellens [Page 22] Expires January 2005
|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 1032 skipping to change at line 1084
|'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 24] Expires April 2005
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 The following table maps information elements from MMS read reports
to the format specified in [MDN]. to the format specified in [MDN].
2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet Message) 2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet Message)
======================|============|=================================== ======================|============|===================================
Information Element |MMS Delivery|[DSN-Msg] Element Information Element |MMS Delivery|[DSN-Msg] Element
|Report Elem | |Report Elem |
skipping to change at line 1055 skipping to change at line 1109
read report) | |if available, 'Message-ID:' read report) | |if available, 'Message-ID:'
| |otherwise). | |otherwise).
----------------------|------------|----------------------------------- ----------------------|------------|-----------------------------------
Recipient address of |From: |'Final-Recipient' field Recipient address of |From: |'Final-Recipient' field
the original message | | the original message | |
----------------------|------------|----------------------------------- ----------------------|------------|-----------------------------------
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-
Gellens [Page 23] Expires January 2005
| |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 MMS-Read-Status value 'read', | |For MMS-Read-Status value 'read',
skipping to change at line 1080 skipping to change at line 1132
| |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 ESMTP on MM3: received using ESMTP on MM3:
Gellens [Page 25] Expires April 2005
* 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 .
* 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 The following table maps information elements from a disposition
skipping to change at line 1105 skipping to change at line 1158
===================|==================|================================ ===================|==================|================================
Information Element|MMS Read Report |[DSN=Msg] Element Information Element|MMS Read Report |[DSN=Msg] Element
|Element | |Element |
===================|==================|================================ ===================|==================|================================
ID of the original |Message-Id: |'Original-Envelope-ID' field ID of the original |Message-Id: |'Original-Envelope-ID' field
message (object of | | message (object of | |
disposition report)| | disposition report)| |
-------------------|------------------|-------------------------------- -------------------|------------------|--------------------------------
Recipient address |From: |'Final-Recipient' field Recipient address |From: |'Final-Recipient' field
of the original | | of the original | |
Gellens [Page 24] Expires January 2005
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 26] Expires April 2005
===================|==================|================================
Information Element|MMS Read Report |[DSN=Msg] 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 |
skipping to change at line 1154 skipping to change at line 1210
2.1.5 Message Delivery 2.1.5 Message Delivery
Within Internet mail, when ESMTP is used and delivery reports are Within Internet mail, when ESMTP 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 ESMTP recipient. When an MMS Relay/Server receives a message using ESMTP
and a delivery report is requested, the MMS Relay/Server MAY and a delivery report is requested, the MMS Relay/Server MAY
consider the message delivered when it has been sent to the MMS User consider the message delivered when it has been sent to the MMS User
Agent. Agent.
Gellens [Page 25] Expires January 2005
3 Security Considerations 3 Security Considerations
Data contained within messages should not be automatically trusted. Data contained within messages should not be automatically trusted.
Even within a carrier's network, and certainly within the Internet, Even within a carrier's network, and certainly within the Internet,
various deliberate and accidental attacks or corruptions are various deliberate and accidental attacks or corruptions are
possible. For example, routers may contain vulnerabilities which possible. For example, routers may contain vulnerabilities which
may be exploited, IP traffic may be intercepted and/or modified, may be exploited, IP traffic may be intercepted and/or modified,
etc. etc.
Gellens [Page 27] Expires April 2005
The following messaging-related security threats can be identified: The following messaging-related security threats can be identified:
* Misidentification of message source. * Misidentification of message source.
* Message interception (unauthorized disclosure of contents). * Message interception (unauthorized disclosure of contents).
* Unauthorized disclosure of message sender or recipient. * Unauthorized disclosure of message sender or recipient.
* Message modification (by adversary). * Message modification (by adversary).
skipping to change at line 1205 skipping to change at line 1260
infrastructure is available, e.g., a certificate infrastructure is infrastructure is available, e.g., a certificate infrastructure is
necessary to support S/MIME, or user agent support for PGP is necessary to support S/MIME, or user agent support for PGP is
available. Enabling SMTP Authentication [Auth] and STARTTLS available. Enabling SMTP Authentication [Auth] and STARTTLS
[StartTLS] are easy measures to deploy and SHOULD be used. [StartTLS] are easy measures to deploy and SHOULD be used.
Since MMS does not include a clear separation between in-transit Since MMS does not include a clear separation between in-transit
envelope and message content, there are increased risks of envelope and message content, there are increased risks of
unauthorized disclosure of information, and additional challenges in unauthorized disclosure of information, and additional challenges in
protecting data. For example, Bcc recipients do not normally appear protecting data. For example, Bcc recipients do not normally appear
in the message content, only in the envelope; care MUST be taken in in the message content, only in the envelope; care MUST be taken in
Gellens [Page 26] Expires January 2005
the gateway function to ensure that Bcc recipients which do appear the gateway function to ensure that Bcc recipients which do appear
are deleted from the message content. are deleted from the message content.
Some MMS features contain inherently more risk than others. For Some MMS features contain inherently more risk than others. For
example, reply charging and sender address hiding. The reply example, reply charging and sender address hiding. The reply
charging mechanism requires a high degree of trust between entities charging mechanism requires a high degree of trust between entities
with little technical basis. Deliberate or accidental abuse of this with little technical basis. Deliberate or accidental abuse of this
trust can result in unexpected or unauthorized charges. For trust can result in unexpected or unauthorized charges. For
example, a sender may be charged for unauthorized replies, or a example, a sender may be charged for unauthorized replies, or a
Gellens [Page 28] Expires April 2005
sender may be charged for a reply which the author thought would be sender may be charged for a reply which the author thought would be
paid for by the recipient. A sender's identity may be disclosed in paid for by the recipient. A sender's identity may be disclosed in
violation of a request for this to be blocked. The identity of violation of a request for this to be blocked. The identity of
recipients may be disclosed to other recipients (or even recipients may be disclosed to other recipients (or even
non-recipients) for a message in which the sender intended for the non-recipients) for a message in which the sender intended for the
recipients not to be disclosed. recipients not to be disclosed.
It is possible to hide the sender's identity from non-recipients It is possible to hide the sender's identity from non-recipients
using anonymous remailers. It is hard to hide the sender's identity using anonymous remailers. It is hard to hide the sender's identity
from recipients when the mail is cryptographically signed. In view from recipients when the mail is cryptographically signed. In view
skipping to change at line 1253 skipping to change at line 1308
[DSN-SMTP] "SMTP Service Extension for Delivery Status [DSN-SMTP] "SMTP Service Extension for Delivery Status
Notifications", Moore, RFC 3461, January 2003. Notifications", Moore, RFC 3461, January 2003.
[Hdr-Enc] "MIME (Multipurpose Internet Mail Extensions) Part Three: [Hdr-Enc] "MIME (Multipurpose Internet Mail Extensions) Part Three:
Message Header Extensions for Non-ASCII Text", Moore, RFC 2047, Message Header Extensions for Non-ASCII Text", Moore, RFC 2047,
November 1996. November 1996.
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997. Requirement Levels", RFC 2119, Harvard University, March 1997.
Gellens [Page 27] Expires January 2005
[MDN] "An Extensible Message Format for Message Disposition [MDN] "An Extensible Message Format for Message Disposition
Notifications", Fajman, RFC 2298, March 1998. Notifications", Fajman, RFC 2298, March 1998.
[Msg-Fmt] ‘Internet Message Format’, Resnick, RFC 2822, April 2001. [Msg-Fmt] ”Internet Message Format‘, Resnick, RFC 2822, April 2001.
[Report-Fmt] ‘The Multipart/Report Content Type for the Reporting of [Report-Fmt] ”The Multipart/Report Content Type for the Reporting of
Mail System Administrative Messages’, Vaudreuil, RFC 3462, January Mail System Administrative Messages‘, Vaudreuil, RFC 3462, January
2003 2003
[SMTP] ‘Simple Mail Transfer Protocol’, Klensin, RFC 2821, April Gellens [Page 29] Expires April 2005
[RESP] Enhanced Mail System Status Codes, Vaudreuil, RFC 1893,
January 1996.
[SMTP] ”Simple Mail Transfer Protocol‘, Klensin, RFC 2821, April
2001. 2001.
5 Informative References 5 Informative References
IETF: IETF:
[Auth] "SMTP Service Extension for Authentication", Myers, RFC 2554, [Auth] "SMTP Service Extension for Authentication", Myers, RFC 2554,
March 1999 March 1999
[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", [Codes] "SMTP Service Extension for Returning Enhanced Error Codes",
Freed, RFC 2034, October 1996. Freed, RFC 2034, October 1996.
[Deliver-By] "Deliver By SMTP Service Extension", Newman, RFC 2852, [Deliver-By] "Deliver By SMTP Service Extension", Newman, RFC 2852,
June 2000. June 2000.
[Msg-Encap] "Proposed Standard for Message Encapsulation", Rose, [Msg-Encap] "Proposed Standard for Message Encapsulation", Rose,
Stefferud, RFC 934, January 1985. Stefferud, RFC 934, January 1985.
[Hdrs] "Common Internet Message Headers", J. Palme, RFC 2076, [Hdrs] "Common Internet Message Headers", J. Palme, RFC 2076,
skipping to change at line 1297 skipping to change at line 1358
[PGP] "MIME Security with OpenPGP", Elkins, Del Torto, Levien, [PGP] "MIME Security with OpenPGP", Elkins, Del Torto, Levien,
Roessler, RFC 3156, August 2001 Roessler, RFC 3156, August 2001
[SMIME] "S/MIME Version 3 Message Specification", Ramsdell, RFC [SMIME] "S/MIME Version 3 Message Specification", Ramsdell, RFC
2633, June 1999 2633, June 1999
[StartTLS] "SMTP Service Extension for Secure SMTP over Transport [StartTLS] "SMTP Service Extension for Secure SMTP over Transport
Layer Security", Hoffman, RFC 3207, February 2002 Layer Security", Hoffman, RFC 3207, February 2002
[Submission] ‘Message Submission’, Gellens, Klensin, RFC 2476, [Submission] ”Message Submission‘, Gellens, Klensin, RFC 2476,
December 1998. December 1998.
Gellens [Page 28] Expires January 2005 [VPIM] ”Voice Profile Internet Mail Ō- Version 2‘, Vaudreuil,
Parsons, RFC 2421, September 1998.
Gellens [Page 30] Expires April 2005
OMA: OMA:
OMA specifications are available at the OMA web site 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 and 3GPP:
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 specifications are available at the 3GPP (Third Generation
Partnership Project) web site <http://www.3gpp.org> Partnership Project) web site <http://www.3gpp.org>
[Stage_3] "MMS MM1 Stage 3 using OMA/WAP", TIA-934-310, X.S0016-310 [Stage_3] "MMS MM1 Stage 3 using OMA/WAP", X.S0016-310
"MMS MM4 Stage 3 Inter-Carrier Interworking", TIA-934-340, "MMS MM4 Stage 3 Inter-Carrier Interworking", X.S0016-340
X.S0016-340
‘Multimedia Messaging Service: Functional description; Stage 2’, TS ”Multimedia Messaging Service: Functional description; Stage 2‘, TS
23.140 Release 5. 23.140 Release 5.
[Formats] "MMS Media Formats and Codecs’, C.P0045, (pending) [Formats] "Multimedia Messaging Service (MMS) Media Format and
Codecs for cdma2000 Spread Spectrum Systems‘, C.S0045
[Overview] "Multimedia Messaging Services (MMS) Overview", [Overview] "Multimedia Messaging Services (MMS) Overview",
X.S0016-000-B, PN-3-0085-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", Functional
Specification, April 2003, X.S0016-200/TIA-934-200. Specification, April 2003, X.S0016-200.
"Multimedia Messaging Service; Media formats and codecs", "Multimedia Messaging Service; Media formats and codecs",
TS26.140Release 5. TS26.140Release 5.
6 Author's Address 6 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
USA USA
randy@qualcomm.com randy@qualcomm.com
Gellens [Page 29] Expires January 2005 Gellens [Page 31] Expires April 2005
Intellectual Property Statement Intellectual Property Statement
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 or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
skipping to change at line 1390 skipping to change at line 1454
Disclaimer Disclaimer
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Gellens [Page 30] Expires January 2005 Gellens [Page 32] Expires April 2005
 End of changes. 

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