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