RFC 4356
Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail
RFC 4356 🎀 Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail
Okay bestie, so this is RFC 4356 💖, and it's all about how the MMS world and the Internet mail world talk to each other ✨. It was written by R. Gellens of Qualcomm 🌸, it's on the Standards Track 👑, and it's dated January 2006 🦋. This copy's title block doesn't list any "Obsoletes" or "Updates" entries, so there's nothing it replaces or changes 🧚.
Status of This Memo 📜
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💅. If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔥. Distribution of this memo is unlimited 🌈.
Copyright Notice ✨
Copyright (C) The Internet Society (2006) 💜.
Abstract 🦋
The cellular telephone industry came up with a service called the Multimedia Messaging Service (MMS) 📱. It uses formats and protocols that are similar to Internet mail, but it's different in key ways 🫶.
One big difference is that MMS uses headers that start with "X-Mms-" to carry all kinds of user agent- and server-related information elements 🧚.
This document explains how to exchange messages between these two services 💌. That includes mapping the information elements used in MMS X-Mms-* headers, plus delivery and disposition reports, to and from what's used in SMTP and Internet message headers 🔥.
Table of Contents 🗂️
1. Introduction ....................................................2
1.1. Scope ......................................................2
1.2. Conventions Used in This Document ..........................3
1.3. Definitions ................................................3
1.4. Abbreviations ..............................................4
1.5. Assumptions ................................................4
2. Mapping Between MMS and Internet Mail ...........................4
2.1. Mapping Specification ......................................5
2.1.1. MMS to Internet Mail ................................5
2.1.2. Internet Mail to MMS ................................5
2.1.3. MMS Information Element Mappings ....................6
2.1.4. Report Generation and Conversion ...................20
2.1.5. Message Delivery ...................................27
3. Security Considerations ........................................27
4. IANA Considerations ............................................27
5. Acknowledgements ...............................................27
6. Normative References ...........................................27
7. Informative References .........................................291. Introduction ✨
1.1. Scope 🌸
Okay so this section sets the scene 💅. It describes how to exchange messages between Multimedia Messaging Service (MMS) systems (as defined by [3GPP][3GPP2][OMA]) and Internet mail systems, meaning [SMTP] and [Msg-Fmt] 💌. That covers translating message formats, message header elements, message delivery reports [DSN-Msg], and message disposition reports [MDN] 🧚.
The MMS architecture [Stage_2] and specifications [Stage_3] talk about 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 ✨. This spec can be used for message exchange between any system that uses Internet message formats and protocols and an MMS system, and from the MMS system's point of view, reference point MM3 is the one that gets used 🦋.
This document also supports voice messages, as specified by the Voice Profile for Internet Mail [VPIM] 🎧. That profile lets voice messages go between voice mail systems using the Internet mail format [Msg-Fmt], carried over [SMTP] 💜. So the MMS MM3 interface can exchange voice messages between an MMS system and a voice mail system 🌈. Just note that this is different from voice media being part of a message that a user composed themselves 🙈.
MM3 can also be used to work with "external" (non-MMS) systems that aren't Internet mail, like Short Messaging Service (SMS) and access to external mail stores (such as a voice mail system) 📱. This specification doesn't cover those other uses or the sub-interfaces of MM3 🍓. It's only about Internet mail interworking and, specifically, exchanging messages 💖.
All MM3 Stage 2 [Stage_2] functions are supported except for reply charging and sender address hiding 👑.
1.2. Conventions Used in This Document 🫶
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be read as described in "Key Words for Use in RFCs to Indicate Requirement Levels" [KEYWORDS] 🔥.
1.3. Definitions 📚
These are the terms the doc uses, so you know exactly what everyone means 💅.
--------------------|----------------------------------------------
Body |The portion of an [SMTP] message's Content
|following the Header (that is, following the
|first blank line). The Body may contain
|structured parts and sub-parts, each of which
|may have its own Header and Body. The Body
|contains information intended for the message
|recipient (human or software).
--------------------|----------------------------------------------
Content |The portion of an SMTP message that is
|delivered. The Content consists of a Header
|and a Body.
--------------------|----------------------------------------------
Disposition Report |Feedback information to an originator User
Message Disposition |Agent by a recipient User Agent about
Notification |handling of an original message. This may
|include notification that the message was or
|was not read, was deleted unread, etc.
--------------------|----------------------------------------------
Envelope |The portion of an SMTP message not included in
|the Content, that is, not in the Header or in
|the Body. While some of it may be copied into
|the Content on delivery, envelope information
|exists only while the message is in transit,
|and contains information used by SMTP agents
|(Mail Transfer Agents (MTAs)).
--------------------|----------------------------------------------
Gateway |See [SMTP], Section 2.3.8.
--------------------|----------------------------------------------
--------------------|----------------------------------------------
Header |The first part of an SMTP message's Content.
|The Header is separated from the Body by a
|blank line. The Header consists of Fields
|(such as "To:"), also known as Header Fields
|or Headers. The message Header contains
|information used by User Agents.
--------------------|----------------------------------------------
Relay/Server |An MMS server. See [Stage_2]. For purposes
|of this document, an MMS Relay/Server acts as
|a gateway when it receives or sends messages
|via Internet mail.
--------------------|----------------------------------------------
User Agent |An MMS or email user agent.
--------------------|----------------------------------------------1.4. Abbreviations 🔤
--------|----------------------------------------------------------
MSA |Message Submission Agent. A server that accepts messages
|from User Agents and processes them, either delivering
|them locally or relaying to an MTA. See [Submission].
--------|----------------------------------------------------------
MTA |Mail Transfer Agent. A server that implements [SMTP].
--------|----------------------------------------------------------1.5. Assumptions 🧠
The doc assumes you already know the 3GPP2 MMS Specification Overview [Overview], MMS Stage 1 (requirements) [Stage_1], Stage 2 (architecture and abstract messages) [Stage_2], and the 3GPP/3GPP2 Stage 3 (protocols) [Stage_3] documents 📖. It also assumes you're comfortable with Internet mail, especially RFC 2821 [SMTP] and RFC 2822 [Msg-Fmt] 💜.
2. Mapping Between MMS and Internet Mail 🦋
This section defines how MMS Relay/Servers and External Servers work together using native [SMTP] 💖. Information elements get exchanged using standard Internet message [Msg-Fmt] header fields, such as the ones in [Hdrs], plus standard [SMTP] elements 🌸.
SMTP and Internet mail extensions handle features like delivery reports, message expiration, and discovering whether a server supports optional features 🔥.
2.1. Mapping Specification 🗺️
2.1.1. MMS to Internet Mail 📤
When sending a message to an Internet mail system, the MMS Relay/Server MUST convert the MM if required, and MUST comply with the requirements of [SMTP] 💅.
The MMS Relay/Server SHOULD use the information elements associated with the MM to define the control information (Internet message header fields and SMTP envelope values) needed for the transfer protocol ✨.
Section 2.1.3 lists the mappings between X-Mms-* headers and Internet message header fields and SMTP values 🧚.
Delivery and read report MMs SHOULD be converted to standard Internet message report format (multipart/report) 📨. On top of converting Internet Message reports, the MMS Relay/Server MUST generate delivery and read report MMs for received messages as appropriate 🫶. See Section 2.1.4 for more information 💌.
2.1.2. Internet Mail to MMS 📥
When receiving a message from an Internet mail system, the MMS Relay/Server converts incoming messages to the MM format used within the receiving system 🌈.
The MMS Relay/Server also converts control information received from the Internet mail server into appropriate information elements of an MM 🧚.
Section 2.1.3 lists the mappings between X-Mms-* headers and Internet message header fields and SMTP values 🍓.
Standard Internet message report format (multipart/report) messages MAY be converted to delivery or read report MMs, as appropriate 🔥. Besides converting report MMs, implementations conforming to this document MUST generate standard Internet message delivery and disposition reports for received Internet messages as appropriate 💖. See Section 2.1.4 for more information 👑.
2.1.3. MMS Information Element Mappings 🔁
The mappings between MMS elements and SMTP/Internet message elements ([SMTP] parameters, [Msg-Fmt] headers, and [DSN-Msg] fields) are summarized in table 1 below, and detailed in the sections that follow 📊. The "MMS Headers" come from [OMA-MMS] 💜. Only the information elements that need mapping are listed in there 🙈. [Msg-Fmt] headers that aren't listed in that table SHOULD be passed through unaltered ✨.
2.1.3.1. Table 1: Information Element Mappings
Okay bestie, this is the big cheat sheet 📋💖 It shows which MMS info element lines up with which SMTP thing and which Internet Mail header. Lots of boxes say N/A or "not currently supported," so don't panic 😭
=================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|==============
3GPP MMS Version |N/A |N/A |X-Mms-3GPP-MMS
| | | -Version:
_________________|_________________|________________|______________
Message Type |N/A |N/A |X-Mms-Message-
(of PDU) | | | Type:
_________________|_________________|________________|______________
Transaction ID |N/A |N/A |X-Mms-Transact
| | | ion-Id:
_________________|_________________|________________|______________
Message ID |N/A |Message-ID: |Message-ID:
_________________|_________________|________________|______________
Recipient |RCPT TO |To:, Cc:, or |To:, Cc:, Bcc:
address(es) |address(es) |omitted (Bcc) |
_________________|_________________|________________|______________
Sender's address |MAIL FROM |From: |From:
|address if | |
|user-originated; | |
|MUST set MAIL | |
|FROM to null | |
|("<>") for all | |
|automatically- | |
|generated MMs | |
_________________|_________________|________________|______________
Content type |N/A |Content-Type: |Content-type:
| | |
| |For voice mes- |
| |sages compliant |
| |to [VPIM], see |
| |Note 2 |
_________________|_________________|________________|______________
=================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|==============
Message class |Class=auto: |MAY set 'Prece |X-Mms-Message-
|MUST set MAIL | dence: bulk' | Class:
|FROM to null |on class=auto |
|("<>"). | |
_________________|_________________|________________|______________
Date and time |N/A |Date: |Date:
of submission | | |
_________________|_________________|________________|______________
Time of expiry |DELIVER-BY |N/A |X-Mms-Expiry:
|[Deliver-By] | |
_________________|_________________|________________|______________
Earliest deliv- |(only for submis-|N/A |X-Mms-Delivery
ery time |sion; not relay) | | -Time:
_________________|_________________|________________|______________
Delivery report |DSN [DSN-SMTP] |N/A |X-Mms-Delivery
request |SHOULD also | | -Report:
|specify recip- | |
|ient address as | |
|ORCPT; SHOULD | |
|also specify | |
|ENVID | |
_________________|_________________|________________|______________
Importance (a/k/a|N/A |Importance: |X-Mms-
"priority") | | | Priority:
| | |
| | |
_________________|_________________|________________|______________
Sender visib- |(not currently |(not currently |X-Mms-Sender-
ility |supported) |supported) | Visibility:
_________________|_________________|________________|______________
Read reply |N/A |Disposition- |X-Mms-Read-
request | | Notification | Reply:
| | -To: [MDN] |
_________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging:
_________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging-
deadline | | | Deadline:
_________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging-
limitation | | | Size:
_________________|_________________|________________|______________
=================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|==============
Reply charging |(not currently |(not currently |X-Mms-Reply-
usage request |supported) |supported) | Charging-
| | | Id:
_________________|_________________|________________|______________
Reply charging |(not currently |(not currently |X-Mms-Reply-
usage reference |supported) |supported) | Charging:
_________________|_________________|________________|______________
Subject |N/A |Subject: |Subject:
_________________|_________________|________________|______________
Previously-sent |N/A |Resent-From: |X-Mms-Previous
by | | | ly-Sent-By:
_________________|_________________|________________|______________
Previously-sent |N/A |Resent-Date: |X-Mms-
date | | | Previously-
| | | Sent-Date-
| | | and-Time:
_________________|_________________|________________|______________
Hop/host trace |N/A |Received: |(Not sup-
| | |ported)
_________________|_________________|________________|______________
Sensitivity |N/A |Sensitivity: see|N/A
| |Note 1 |
_________________|_________________|________________|______________
Content |N/A |<message body> |<message body>
=================|=================|================|==============Okay so now the notes 🫶
Note 1 💅 The [VPIM] 'Sensitivity' header element is how the originator says how private they want the message to be (it's either "personal" or "private" 🙈). Per [VPIM], a message recipient MUST NOT forward a message with a 'Sensitivity' header. Absolutely not 💀. And since sensitivity isn't an MMS feature, any message with a 'Sensitivity:' header SHOULD NOT be sent to an MMS system 🚫
Note 2 🌈 [VPIM] is the one that spells out how conforming messages get identified, so that's where you go for the details 🧚
2.1.3.2. Conversion of Messages from MMS to Internet Format
okay bestie, this is where we translate an MMS message into Internet format 🎀 we're going field by field, so grab a snack 🍓
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. bye bye 👋
Transaction ID
The X-Mms-Transaction-Id: header, if present, SHOULD be removed. gone, no cap 💀
Message ID
The Message-Id: header MUST be retained. If not present, it MUST be created, with a unique value, per [Msg-Fmt]. this one is non-negotiable 🫶
To facilitate the case where an MMS message traverses the Internet prior to returning to an MMS system, implementations might wish to retain the X-Mms-Message-Id: header. Such systems should be aware that headers that begin with "X-" might be removed during transit through Internet MTAs. ✨
Recipient(s) address
The address of each recipient MUST be transmitted in the [SMTP] envelope as a RCPT TO value. All disclosed recipients SHOULD also appear in a To: or Cc: header. At least one To:, Cc:, or Bcc: header MUST be present. If none are present, a To: header SHOULD be created using empty group syntax whose name gives an indication to a human reader, for example, 'To: undisclosed-recipients:;'. 💖
The To: header SHOULD NOT appear more than once. The Cc: header SHOULD NOT appear more than once. 🙈
Each recipient address MUST obey the length restrictions per [SMTP].
Current Internet Message format requires that only 7-bit US-ASCII characters be present in headers. Non-7-bit characters in an address domain must be encoded with [IDN]. If there are any non-7-bit characters in the local part of an address, the message MUST be rejected. Non-7-bit characters elsewhere in a header MUST be encoded according to [Hdr-Enc]. the rules are strict, but they're giving clarity 💅
All recipient addresses in the [SMTP] envelope must be fully-qualified in accordance with [SMTP]. In particular, messages MUST NOT be sent to an Internet mail system with an unqualified E.164 number (i.e., a number with no domain) instead of a fully-qualified domain name.
All addresses in To:, Cc:, and Bcc: headers MUST be in the form of fully-qualified domains. Unqualified E.164 numbers MUST NOT be used.
Sender address
The address of the message sender SHOULD appear in the From: header.
The address of the message sender for all user-generated messages (X-Mms-Message-Class: Personal) SHOULD be transmitted in the [SMTP] envelope as the MAIL FROM value.
The return addresses in the [SMTP] envelope must be fully-qualified in accordance with [SMTP]. In particular, messages MUST NOT be sent to an Internet mail system with an E.164 number instead of a fully-qualified domain name. Note that qualified E.164 numbers, that is, those that contain an E.164 number as the local-part of an address that also includes a domain, are acceptable. ✅
The address(es) in the From: header SHOULD be in the form of fully-qualified domains. Unqualified E.164 numbers SHOULD NOT be used.
Because of the risk of mail loops, it is critical that theMAIL FROMbe set to null ("<>") for all automatically-generated MMs (such asX-Mms-Message-Class: Auto). TheMAIL FROMvalue MUST be set to null for all automatically-generated messages. This includes reports, "out-of-office" replies, etc. 🚨 mail loops are a whole disaster, so this part is serious
Current Internet message format requires that only 7-bit US-ASCII characters be present in headers. Non-7-bit characters in an address domain must be encoded with [IDN]. If there are any Non-7-bit characters in the local part of an address, the message MUST be rejected. Non-7-bit characters elsewhere in a header MUST be encoded according to [Hdr-Enc]. Note that it would be possible to define an [SMTP] extension to permit transmission of unencoded 8-bit characters, but in the absence of such an extension [Hdr-Enc] MUST be used. 🧠
The sender address MUST obey the length restrictions of [SMTP].
Content type
The Content-Type: header SHOULD be preserved. ✨
Message class
The X-Mms-Message-Class: header MAY be retained in order to provide information on the source of the message. A Precedence: bulk header MAY be inserted for class=auto or class=advertisement. See 'Sender Address' above. (Class=personal and class=informational do not require special handling.) 🌈
Time of Expiry
The X-Mms-Expiry: header, if present, SHOULD be removed.
The remaining time until the message is considered expired SHOULD be transmitted in the [SMTP] envelope by using the DELIVER-BY extension with a by-mode of "R", as specified in [Deliver-By]. ⏳
Note that the [SMTP] DELIVER-BY extension carries time remaining until expiration; each server decrements the value by the amount of time it has possessed the message. The X-Mms-Expiry: header may contain either the absolute time at which the message is considered expired or the relative time until the message is considered expired. 🦋
Earliest delivery time
The X-Mms-Delivery-Time: header, if present, SHOULD be removed.
Future delivery is a message submission (e.g., [Submission]), not message relay feature. 🧚
Delivery report request
Requests for delivery status notifications (DSNs) SHOULD be transmitted in the [SMTP] envelope by using the DSN extension as specified in [DSN-SMTP] to request "success" or "none" notification (depending on the value of the X-Mms-Delivery-Report header). When the NOTIFY extension is used, the unaltered recipient address SHOULD be transmitted as the ORCPT value.
The X-Mms-Delivery-Report: header, if present, SHOULD be removed. 📬
Importance
The message sender's importance value (also called "priority", although this can be confused with class-of-service values) SHOULD be transmitted using an Importance: header. 👑
Suggested mappings are shown in Table 2:
2.1.3.2.1. Table 2: Importance Mappings (MMS to Internet Message) 💅
Okay so this little table is the importance glow-up 🎀 X-Mms-Priority: High becomes Importance: High, X-Mms-Priority: Low becomes Importance: Low, and normal ones get dropped entirely (see the [omit]) 🙈
---------------------------|------------------
'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. 🚫 Not me being dramatic, this is the rule.
The X-Mms-Sender-Visibility: header, if present, SHOULD be removed. ✨
Read reply request
A request for a read reply SHOULD be transmitted using a Disposition-Notification-To: header as specified in [MDN]. 📬
The X-Mms-Read-Reply: header, if present, SHOULD be removed. 🧼
Reply charging
Reply charging permission and acceptance are complex issues requiring both user agent and server support. Misapplied reply charging may cause incorrect billing. Until the security issues have been properly addressed, reply charging SHOULD NOT be honored when using this interface. 💀 This one is serious bestie, no cap.
The X-Mms-Reply-Charging:, X-Mms-Reply-Charging-Deadline:, X-Mms-Reply-Charging-Size:, and X-Mms-Reply-Charging-Id: headers MAY be removed. Messages containing a reply-charging usage request (X-Mms-Reply-Charging-Id: and X-Mms-Reply-Charging: accepted or X-Mms-Reply-Charging: accepted (text only) headers) SHOULD be rejected. 🙅♀️
Subject
The Subject: header MUST be preserved. 💖 The current Internet message format requires that only 7-bit US-ASCII characters be present. Other characters MUST be encoded according to [Hdr-Enc]. Note that it is possible for an [SMTP] extension to be defined that would permit transmission of unencoded 8-bit characters, but in the absence of such an extension, [Hdr-Enc] MUST be used. 🌸
Resending
A message may be resent to one or more new recipients. It may be resent more than once, each time new Resent- headers are added at the top of the existing headers. Thus, if more than one series of Resent- headers are present, the original series is the last; the most recent is the first. 🧚 Reverse-chronological energy, iykyk.
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. 📜 The whole timeline, honestly iconic.
Any X-Mms-Previously-Sent-By:, X-Mms-Previously-Sent-Date-and-Time:, and X-Mms-Forward-Counter: headers, if present, SHOULD be removed. The information contained in them SHOULD be translated into [Msg-Fmt] headers as follows: 🧹✨
The X-Mms-Previously-Sent-Date-and-Time: header whose value starts with "0" SHOULD be used to create a Date: header, converting the date and time from HTTP-date [HTTP] to date-time [Msg-Fmt]. The X-Mms-Previously-Sent-By: header whose value starts with "0" SHOULD be used to create a From: header. 🦋
A To: header SHOULD be created using list syntax with a value of "unrecoverable-recipients" and no mailboxes. 🙈
A Message-ID: header SHOULD be created. 🎀
Any X-Mms-Previously-Sent-Date-and-Time: headers whose value starts with "1" or a larger value are mapped to Resent-Date: headers. Any X-Mms-Previously-Sent-By: headers whose value starts with "1" or a larger value are mapped to Resent-By: headers. 🌈
The From:, To:, Date:, and Message-ID: headers are mapped to Resent-From:, Resent-To:, Resent-Date:, and Resent-Message-ID: headers in the top-most block of Resent-* headers. 👑
Example
The MMS message:
X-Mms-Forward-Counter: 2
X-Mms-Previously-Sent-Date-and-Time: 0, Fri, 01 Apr 2005 06:02:03 GMT
X-Mms-Previously-Sent-By: 0, General Failure <mfail@example.mil>
X-Mms-Previously-Sent-Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT
X-Mms-Previously-Sent-By: 1, Colonel Corn <gcorn@example.mil>
Date: Fri, 1 Apr 2005 18:02:03 -0800
From: L. Eva Message <lem@example.org>
To: b1ff@mms.example.com
Message-ID: <99887766.112233@mail.example.org>is mapped to an Internet mail message:
Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800
Resent-From: L. Eva Message <lem@example.org>
Resent-To: b1ff@mms.example.com
Resent-Message-ID: <99887766.112233@mail.example.org>
Resent-Date: Fri, 1 Apr 2005 08:02:03 +0000
Resent-From: Colonel Corn <gcorn@example.mil>
Date: Fri, 1 Apr 2005 06:02:03 +0000
From: General Failure <mfail@example.mil>
To: Colonel Corn <gcorn@example.mil>
Message-ID: <000.000.000@gateway.example.org>'Received:' Headers
When a message is gatewayed from MMS to Internet mail, a Received: header MUST be added as per [SMTP]. The "with" clause should specify "MMS". 📨
A message MAY be rejected if the number of Received: headers exceeds a locally-defined maximum, which MUST conform to [SMTP] Section 6.2 and SHOULD be no less than 100. 🛑
Privacy
Note that MMS systems do not currently support the Privacy header field as described by [VPIM]. 🙈
Content
The message content appears in the message body. Note that Internet message format requires that line endings be encoded as US-ASCII CR LF octets; thus, charset encodings that do not have this property cannot be used in text/* body parts. (They may be used in other body parts, but only when they are suitably encoded or when binary transmission has been negotiated, e.g., [BINARY].) In particular, MMS allows UTF-16, whereas the Internet message format does not. UTF-16 encoding MUST be translated to UTF-8 or another charset and encoding that is suitable for use in Internet message format/protocols. 🍓
2.1.3.3. Conversion of Messages from Internet to MMS Format 🧚
3GPP MMS Version
An X-Mms-3GPP-MMS-Version: header SHOULD be added. 🌸
Message Type (of PDU)
An X-Mms-Message-Type: header SHOULD be used in accordance with the specific MMS interface (e.g., MM1, MM4). 💅
Transaction ID
An X-Mms-Transaction-Id: header SHOULD be used in accordance with the specific MMS interface (e.g., MM1, MM4). ✨
Message ID
The Message-Id: header MUST be retained. If not present, it MUST be created, with a unique value. 🔑
Recipient(s) address
To: and Cc: headers MUST be retained. 👯
Each recipient contained in the [SMTP] envelope (RCPT TO values) MUST be considered a recipient of the message. Recipients who appear in address headers but not the [SMTP] envelope MUST be ignored. Recipients who appear in the [SMTP] envelope but do not appear in headers are considered "blind" (Bcc) recipients; such recipients MUST NOT be added to message headers (including address and trace headers) unless there is only one recipient total. 🕵️♀️ Bcc secrets stay secret, periodt.
Sender address
The From: header MUST be retained. 💌
Content type
The complete Content-Type: header (including any parameters) SHOULD be preserved. 🎀
Message class
An X-Mms-Message-Class: personal header MAY be created for all received messages with a non-null return path (MAIL FROM value in the SMTP envelope). An X-Mms-Message-Class: auto header MAY be created for messages with a null return path. 🏷️
Time of Expiry
An X-Mms-Expiry: header SHOULD be created if the message contains a relative time to expiration in the DELIVER-BY extension with a by-mode of "R", as specified in [Deliver-By].
If the by-mode is "N", a "relayed" DSN MUST be issued per [Deliver-By] and an X-Mms-Expiry: header SHOULD NOT be created. ⏰
Delivery report request
An X-Mms-Delivery-Report: header SHOULD be created for messages that request 'success' or 'none' delivery status notification by use of the DSN extension as specified in [DSN-SMTP]. Requests for 'delay' notifications or non-default actions, such as that only the message headers should be returned, cannot be mapped onto MMS headers and thus SHOULD be ignored. 📦
Importance
The message sender's importance value (also called "priority", although this can be confused with class-of-service values) is expressed with an Importance: header. Historically, some clients used the older and non-standard X-Priority: header for this purpose. As a result, some clients generate both. 🔥
An X-Priority: or Importance: header, if present, SHOULD be replaced with an X-Mms-Priority: header. If both headers are present, Importance: SHOULD be used. Suggested mappings are shown in Table 3: 🧁
2.1.3.3.1. Table 3: Priority Mappings (Internet Message to MMS) 🔥
-------------------------------|----------------------
'X-Priority: 1 (highest)' |'X-Mms-Priority: High'
-------------------------------|----------------------
'X-Priority: 2 (high)' |'X-Mms-Priority: High'
-------------------------------|----------------------
'Importance: High' |'X-Mms-Priority: High'
-------------------------------|----------------------
'X-Priority: 3 (normal)' | [omitted]
-------------------------------|----------------------
'Importance: Normal' | [omitted]
-------------------------------|----------------------
'X-Priority: 4 (low)' |'X-Mms-Priority: Low'
-------------------------------|----------------------
'Importance: Low' |'X-Mms-Priority: Low'
-------------------------------|----------------------
'X-Priority: 5 (lowest)' |'X-Mms-Priority: Low'
-------------------------------|----------------------Okay so bestie, normal importance messages SHOULD omit the X-Mms-Priority: header. Normal is the default vibe, so no need to flex it 💅
Sender visibility
Support for sender address hiding is not currently supported. So no hiding your address on this one, sorry bestie 🫣
Read reply request
A request for a read reply that's sitting in a Disposition-Notification-To: header (the one defined in [MDN]) SHOULD be replaced with an X-Mms-Read-Reply: header. Glow-up energy ✨
Subject
The Subject: header MUST be preserved. No exceptions, no cap 💖
Resending
Mapping from Resent- headers and other [Msg-Fmt] headers over to X-Mms-Previously-Sent- headers SHOULD be done like this 🦋
The original From: header gets mapped to an X-Mms-Previously-Sent-By: header with a leading "0" value. The value of the top-most Resent-From: header gets mapped to the From: header. Then the value of each subsequent Resent-From: header gets mapped to an X-Mms-Previously-Sent-By: header with the next larger leading value. Main character energy 👑
The original Date: header gets mapped to an X-Mms-Previously-Sent-Date-and-Time: header with a leading "0" value. The value gets converted from date-time syntax [Msg-Fmt] to HTTP-date syntax [HTTP] too, so keep an eye out for that 👀 The value of the top-most Resent-Date: header gets mapped to the Date: header. The value of each subsequent Date: header gets 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. It's a whole counting situation 🔢
Example
Okay so here's 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>Then Colonel Corn resends it to L. Eva Message, like a whole chain of drama 🍿
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>And then L. Eva resends it to her MMS device 📱
Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800
Resent-From: L. Eva Message <lem@example.org>
Resent-To: b1ff@mms.example.com
Resent-Message-ID: <99887766.112233@mail.example.org>
Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800
Resent-From: Colonel Corn <gcorn@example.mil>
Resent-To: L. Eva Message <lem@example.org>
Resent-Message-ID: <msg234@mail.example.mil>
Date: Fri, 1 Apr 2005 14:02:03 -0800
From: General Failure <mfail@example.mil>
To: Colonel Corn <gcorn@example.mil>
Message-ID: <msg123@mail.example.mil>This would get mapped to an MMS message like this:
X-Mms-Forward-Counter: 2
X-Mms-Previously-Sent-Date-and-Time: 0, Fri, 01 Apr 2005 06:02:03 GMT
X-Mms-Previously-Sent-By: 0, General Failure <mfail@example.mil>
X-Mms-Previously-Sent-Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT
X-Mms-Previously-Sent-By: 1, Colonel Corn <gcorn@example.mil>
Date: Fri, 1 Apr 2005 18:02:03 -0800
From: L. Eva Message <lem@example.org>
To: b1ff@mms.example.com
Message-ID: <99887766.112233@mail.example.org>Note that the original From: and Date: values got 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 got moved to a second set of X-Mms-Previously-Sent- headers, with a leading "1" value. The third set of Resent- headers went to the Date:, To:, and From: headers. Sorted 🧠
Note also that the format of the date and time is different between the Date: / Resent-Date: headers and the X-Mms-Previously-Sent-Date-and-Time: headers. The latter use HTTP-date [HTTP] instead of date-time [Msg-Fmt], so they're literally not the same vibe 🙃
Received: Headers
Each system that processes a message SHOULD add a Received: header as per [SMTP]. A message MAY be rejected if the number of Received: headers goes over a locally-defined maximum. That maximum MUST conform to [SMTP] Section 6.2 and SHOULD be no less than 100. Lowkey a lot of hops, but we respect it 🚀
Sensitivity
The Sensitivity: header field (value = "personal" or "private") [VPIM] shows that a voice message originator wants the message contents to go to the original recipient list with assurance that the message won't be forwarded any further, not by the messaging system and not by the actual recipient(s). Secret-keeper vibes 🤫 Since sensitivity is not an MMS feature, any messages that contain a Sensitivity: header MUST NOT be sent to an MMS system. The associated negative delivery status report MUST include the extended status code [RESP] 5.6.0 as specified in [VPIM] ("Other or undefined protocol status"), which indicates that privacy could not be ensured. It's giving "we tried, we really did" 😭
Content
The message content appears in the message body. Simple and iconic 🌸
2.1.4. Report Generation and Conversion 🎀
Internet message systems use the multipart/report MIME type for delivery and disposition reports, as specified in [Report-Fmt]. This format is a two- or three-part MIME message. One part is a structured format describing the event being reported, in an easy-to-parse format. Specific reports have a format that's built on [Report-Fmt]. Delivery reports are specified in [DSN-Msg]. Message disposition reports, which include read reports, are specified in [MDN].
By contrast, MMS reports are plain text with no defined structure specified. That makes it hard to convert from an MMS report into a standard Internet report 😩
An implementation conforming to this specification MUST convert reports received from one side (MMS or Internet mail) that are destined for the other side. In addition, reports MUST be generated as appropriate for messages received from either side. For example, if an MM to be sent via Internet mail is not deliverable, a delivery status MM shall be generated. Likewise, if an Internet message is received that cannot be further relayed or delivered, a delivery status report [DSN-Msg] MUST be generated. Reports really gotta show up for everyone 💅
When creating delivery or disposition reports from MMS reports, the MMS report should be parsed to figure out the reported event and time, the status, and the headers of the referenced (original) message. Once those elements are determined, they're used to fill in the subparts of the delivery or disposition report. The first subpart is of type text/plain and contains a human-readable explanation of the event. This text may include a statement that the report was synthesized based on an MMS report. The second subpart is of type report/delivery-status (for delivery reports) or report/disposition-notification (for disposition reports). This second part contains a structured itemization of the event. The optional third subpart is of type message/rfc822 and includes the headers and optionally the body of the referenced (original) message. Note that, per [DSN-Msg], the DSN-Gateway: field in delivery reports MUST be created. Don't forget that field, bestie 🫶
2.1.4.1. Delivery Report Mapping from MMS to Internet Message 📬
Below, Table 4 maps information elements from MMS delivery reports to the format specified in [DSN-Msg].
2.1.4.1.1. Table 4: Delivery Report Mappings (MMS to Internet Message) 🧾
======================|============|===================================
Information Element |MMS Delivery|[DSN-Msg] Element
|Report Elem |
======================|============|===================================
ID of message whose |Message-Id: |'Message-ID:' preserved in third
delivery status is | |subpart of delivery report.
being reported | |
----------------------|------------|-----------------------------------
Recipient address of |From: |'Final-Recipient' field of the
the original message | |per-recipient section.
(object of delivery | |
report) | |
----------------------|------------|-----------------------------------
Destination address of|To: |'To:' header field value of top-
report | |level.
----------------------|------------|-----------------------------------
Date and time the |Date: |'Date:' header field value of top-
message was handled | |level.
----------------------|------------|-----------------------------------
======================|============|===================================
Information Element |MMS Delivery|[DSN-Msg] Element
|Report Elem |
======================|============|===================================
Delivery status of |X-Mms- |Action and Status fields of
original message to | Status: |per-recipient section.
each recipient | |
| |The 'Action' field indicates if the
| |message was delivered.
| |
| |For failed delivery, an appropriate
| |'Status' value shall be included
| |per [DSN-Msg].
| |
| |The Action field is set to one of
| |the following values:
| |
| |* delivered (used for MMS status
| |values 'retrieved' and 'rejected',
| |depending on 'Status' code).
| |
| |* failed (used for MMS status
| |values 'expired' and 'unreachable')
| |
| |* delayed MAY be used for MMS
| |status value 'deferred'
| |
| |* relayed (used for MMS status
| |value 'indeterminate')
| |
| |* expanded (SHOULD NOT be used)
----------------------|------------|-----------------------------------
Status Text | |Text in first part (human-readable
| |part).When an MMS Relay/Server makes a [DSN-Msg] in response to a message it got over [SMTP] on MM3, here's how the headers should look 💌:
- Top-level header field 'To:' SHOULD be the [SMTP] return-path of the message whose status is being reported.
- Top-level header field 'From:' SHOULD be the address of the recipient that the delivery-report concerns.
- The first part of the [DSN-Msg] SHOULD include the MM Status Text field that would have been generated for an MM1 delivery-report.
2.1.4.2. Delivery Report Mapping from Internet Message to MMS ✉️
Okay, flipping it around now 🔄. Table 5 maps the info elements from a delivery report defined in [DSN-Msg] onto the format of an MMS delivery report. Heads up: one DSN that reports on multiple recipients turns into several MMS delivery reports, so don't be surprised when you get a whole stack of them 📚.
2.1.4.2.1. Table 5: Delivery Report Mappings (Internet Message to MMS) 🗂️
===================|==================|================================
Information Element|MMS Delivery |[DSN-Msg] Element
|Report Element |
===================|==================|================================
ID of the original |Message-Id: |'Message-ID:' header preserved
message (object of | |in third sub-part of report.
delivery report) | |
-------------------|------------------|--------------------------------
Recipient address |From: |If available, the 'Original
of the original | |-Recipient' field of the per-
message (object of | |recipient section should be
delivery report) | |used; otherwise, the 'Final-
| |Recipient' field of the per-
| |recipient section is used.
-------------------|------------------|--------------------------------
Destination address|To: |'To:' header field value of
of report | |top-level.
| |
| |Value taken from [SMTP] envelope
| |return-path of message being
| |reported, not its 'From:' header
| |field.
-------------------|------------------|--------------------------------
Date and time the |Date: |'Date:' header field value of
message was handled| |top-level.
-------------------|------------------|--------------------------------
===================|==================|================================
Information Element|MMS Delivery |[DSN-Msg] Element
|Report Element |
===================|==================|================================
Delivery status of |X-Mms-Status: |'Action' and 'Status' fields of
original message | |per-recipient section.
|Set to one of the |
|following values: |
| |
|'retrieved' (used |
|for 'Action' value|
|'delivered'). |
| |
|'unreachable' |
|(used for 'Action'|
|value 'failed') |
| |
|'forwarded' (used |
|for 'Action' value|
|'relayed') |
| |
|'deferred' MUST |
|NOT be used |
|(ignore DSNs with |
|'Action' value |
|'delayed') |
-------------------|------------------|--------------------------------
Status Text | |Text in first part (human-
| |readable part).
===================|==================|================================2.1.4.3. Read Report Mapping from MMS to Internet Message 👀
Next up, Table 6 maps the info elements from MMS read reports to the format specified in [MDN]. It's giving organised 🗃️.
2.1.4.3.1. Table 6: Read Report Mappings (MMS to Internet Message) 💜
======================|============|===================================
Information Element |MMS Delivery|[MDN] Element
|Report Elem |
======================|============|===================================
ID of the original |Message-Id: |'Message-ID:' header preserved in
message (object of | |third part of report.
read report) | |
----------------------|------------|-----------------------------------
Recipient address of |From: |'Final-Recipient' field.
the original message | |
======================|============|===================================
Information Element |MMS Delivery|[MDN] Element
|Report Elem |
======================|============|===================================
Destination address of|To: |'To:' header field value of top-
report | |level.
| |
| |Value taken from 'Disposition-
| |Notification-To:' header field of
| |message being reported, not its
| |'From:' header field.
----------------------|------------|-----------------------------------
Date and time the |Date: |'Date:' header field value of top-
message was handled | |level.
----------------------|------------|-----------------------------------
Disposition of message|X-Mms-Read- |Disposition-field
being reported | Status: |
| |For X-MMS-Read-Status value 'read',
| |use 'disposition-type' value
| |'displayed'; for X-MMS-Read-Status
| |value 'Deleted without being read',
| |use 'disposition-type' value
| |'deleted').
----------------------|------------|-----------------------------------
Status Text | |Text in first part (human-readable
| |part).
======================|============|===================================When an MMS Relay/Server generates an [MDN] in response to a message it received over [SMTP] on MM3, keep these two in mind 🧠:
- Top-level header field 'To:' SHOULD be the value of the 'Disposition-Notification-To:' header field of the message whose disposition is being reported.
- Top-level header field 'From:' SHOULD be the address of the recipient that the read report concerns.
2.1.4.4. Disposition Report Mapping from Internet Message to MMS 🔁
Last mapping in this section! Table 7 maps the info elements from a disposition report defined in [MDN] onto the format of an MMS read report 🎀.
2.1.4.4.1. Table 7: Disposition Report Mappings (Internet Message to MMS) 🦋
===================|==================|================================
Information Element|MMS Read Report |[MDN] Element
|Element |
===================|==================|================================
ID of the original |Message-Id: |'Message-ID:' header preserved
message (object of | |in third subpart of report.
disposition report)| |
-------------------|------------------|--------------------------------
Recipient address |From: |'Final-Recipient' field.
of the original | |
message | |
-------------------|------------------|--------------------------------
Destination address|To: |'To:' header field value of
of report | |top-level.
| |
| |Value taken from 'Disposition-
| |Notification-To:' header field
| |of message being reported, not
| |its 'From:' header field.
-------------------|------------------|--------------------------------
Date and time the |Date: |'Date:' header field value of
message was handled| |top-level.
-------------------|------------------|--------------------------------
Disposition of |X-Mms-Read-Status:|disposition-field.
message being | |
reported |Set to one of the |
|following values: |
| |
|'read' (used for |
|disposition-type |
|value 'displayed')|
| |
|'Deleted without |
|being read' (used |
|for disposition- |
|types 'deleted', |
|'denied' and |
|'failed' when |
|action-mode is |
|'automatic- |
|action') |
-------------------|------------------|--------------------------------
Status Text | |Text in first part (human-
| |readable part).
===================|==================|================================2.1.5. Message Delivery 📬
Inside Internet mail, when [SMTP] is used and delivery reports are requested [DSN-SMTP], "delivered" means the final server (the one closest to the recipient) has accepted the message 🎯. When an MMS Relay/Server gets a message over [SMTP] and a delivery report has been requested, it MAY count the message as delivered once it has been sent to the MMS User Agent ✨.
3. Security Considerations 🔐
Both MMS and Internet mail come with their own set of security risks 😬. This document only describes how messages move between these two environments, so it only covers the risks specific to that job, not the ones already baked into either environment on its own 💅.
When a message uses end-to-end security mechanisms such as [PGP] or S/MIME [SMIME], servers MUST be careful not to accidently destroy the integrity of the protected content 🚨. For example, they must not alter any text inside the region covered by a signature while mapping between MMS and email 😱. [Mime-Sec-gw] talks about the issues these mechanisms cause in gateways 🧐.
Some MMS features are way riskier than others, like reply charging and sender address hiding 💀. Support for those mechanisms is not included in this document, so no need to worry about them here 🙅♀️.
4. IANA Considerations 🗂️
IANA has added "MMS" as one of the "WITH protocol types" under its "MAIL Parameters" registry 🎉. The description is "Multimedia Messaging Service", and the reference points to this document 📖.
5. Acknowledgements 🫶
A bunch of people helped make this document happen, especially the members of the IETF Lemonade working group, including Greg Vaudreuil 🌸. John Klensin did a super thorough and helpful review 👑. Greg White caught a huge pile of nits 🔍. Ted Hardie was very helpful 💖. Alexey Melnikov and Chris Newman sent really useful and detailed comments 🙌.
6. Normative References ✨
okay bestie, these are the must-reads 📚💅 the stuff this spec leans on so hard it can't function without it. Every one is a real citation, so here they all are:
[DSN-Msg]Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.[DSN-SMTP]Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.[Hdr-Enc]Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, November 1996.[HTTP]Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.[IDN]Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.[KEYWORDS]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[MDN]Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.[Msg-Fmt]Resnick, P., "Internet Message Format", RFC 2822, April 2001.[Report-Fmt]Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.[RESP]Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.[SMTP]Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.[OMA]OMA specifications are available at the OMA web site <http://www.openmobilealliance.org>.[OMA-MMS]OMA-WAP-MMS-ENC-V1_2-20040323-C[3GPP2]3GPP2 specifications are available at the 3GPP2 (Third Generation Partnership Project 2) web site <http://www.3gpp2.org>.[3GPP]3GPP specifications are available at the 3GPP (Third Generation Partnership Project) web site <http://www.3gpp.org>[Stage_3]"MMS MM1 Stage 3 using OMA/WAP", X.S0016-310 "MMS MM4 Stage 3 Inter-Carrier Interworking", X.S0016-340 "Multimedia Messaging Service: Functional description; Stage 2", TS 23.140 Release 5.
7. Informative References 🧚
these ones are the bonus reading 🎀 not strictly required, but super helpful for getting the full picture. Here's the whole list:
[BINARY]Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.[Deliver-By]Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.[Hdrs]Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.[Mime-Sec-gw]Freed, N., "Gateways and MIME Security Multiparts", RFC 2480, January 1999.[PGP]Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.[SMIME]Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.[Submission]Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.[VPIM]Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.[Overview]"Multimedia Messaging Services (MMS) Overview", X.S0016-000[Stage_1]"Multimedia Messaging Services (MMS); Stage 1", Requirements, October 2002, S.R0064-0.[Stage_2]"Multimedia Messaging Service (MMS); Stage 2", Functional Specification, April 2003, X.S0016-200. "Multimedia Messaging Service; Media formats and codecs", TS26.140Release 5.
Author's Address 💌
here's where to find the author, Randall Gellens, at QUALCOMM 🦋
Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121
EMail: randy@qualcomm.comFull Copyright Statement ⭐
the legal bit, and it matters 🫶 The copyright belongs to The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Here's the disclaimer, word for word, all caps and everything 😭
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 doesn't take a side on whether any patents or rights might apply to the tech in here, or whether you could get a license for them. It also doesn't claim it went hunting for any of them. If you want the rules on rights in RFC documents, check BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses, or the result of an attempt to get a general license or permission for implementers or users to use the proprietary rights, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💜
Acknowledgement 🍓
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Thank you, IASA, you keep the lights on 💖
📦 where this page comes from
- ietf: rfc4356 2006-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms