idnits 2.17.1 draft-ietf-lemonade-mms-mapping-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1502. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1486. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1490), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 33. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2005) is 6762 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Dsn-Msg' is mentioned on line 989, but not defined == Missing Reference: 'Auth' is mentioned on line 1432, but not defined == Missing Reference: 'IPSec' is mentioned on line 1432, but not defined == Missing Reference: 'StartTLS' is mentioned on line 1432, but not defined == Unused Reference: 'BINARY' is defined on line 1365, but no explicit reference was found in the text == Unused Reference: 'Codes' is defined on line 1368, but no explicit reference was found in the text == Unused Reference: 'Hdrs' is defined on line 1374, but no explicit reference was found in the text == Unused Reference: 'Submission' is defined on line 1386, but no explicit reference was found in the text == Unused Reference: 'Formats' is defined on line 1392, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3490 (ref. 'IDN') (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3798 (ref. 'MDN') (Obsoleted by RFC 8098) ** Obsolete normative reference: RFC 2822 (ref. 'Msg-Fmt') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3462 (ref. 'Report-Fmt') (Obsoleted by RFC 6522) ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) -- Possible downref: Non-RFC (?) normative reference: ref. 'OMA-MMS' -- Obsolete informational reference (is this intentional?): RFC 2633 (ref. 'SMIME') (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 2476 (ref. 'Submission') (Obsoleted by RFC 4409) Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: Mapping Between MMS and Internet Mail R. Gellens 3 Document: draft-ietf-lemonade-mms-mapping-06.txt Qualcomm 4 Expires: April 2006 October 2005 6 Mapping Between the Multimedia Messaging Service (MMS) 7 and Internet Mail 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt The list of 28 Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2005). All Rights Reserved. 35 Abstract 37 The cellular telephone industry has defined a service known as the 38 Multimedia Messaging Service (MMS). This service uses formats and 39 protocols which are similar to, but differ in key ways from, those 40 used in Internet mail. 42 One important difference between MMS and Internet Mail is that MMS 43 uses headers which start with "X-Mms-" to carry a variety of user 44 agent and server related information elements. 46 Gellens [Page 1] Expires April 2006 47 This document specifies how to exchange messages between these two 48 services, including mapping information elements as used in MMS 49 X-Mms-* headers as well as delivery and disposition reports, to and 50 from that used in SMTP and Internet message headers. 52 Gellens [Page 2] Expires April 2006 53 Table of Contents 55 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 Conventions Used in this Document . . . . . . . . . . . . 3 57 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.4 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 60 1.5 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 61 2 Mapping Between MMS and Internet Mail . . . . . . . . . . . . 6 62 2.1 Mapping Specification . . . . . . . . . . . . . . . . . . 6 63 2.1.1 MMS to Internet Mail . . . . . . . . . . . . . . . . . 6 64 2.1.2 Internet Mail to MMS . . . . . . . . . . . . . . . . 7 65 2.1.3 MMS Information Element Mappings . . . . . . . . . . . 7 66 2.1.3.1 Table 1: Information Element Mappings . . . . . . 8 67 2.1.3.2 Conversion of messages from MMS to Internet format 10 68 2.1.3.2.1 Table 2: Importance Mappings (MMS to Internet 13 69 2.1.3.3 Conversion of messages from Internet to MMS format 17 70 2.1.3.3.1 Table 4: Priority Mappings (Internet Message t 19 71 2.1.4 Report Generation and Conversion . . . . . . . . . . . 22 72 2.1.4.1 Delivery Report Mapping from MMS to Internet Messa 22 73 2.1.4.1.1 Table 5: Delivery Report Mappings (MMS to Inte 23 74 2.1.4.2 Delivery Report Mapping from Internet Message to M 24 75 2.1.4.2.1 Table 6: Delivery Report Mappings (Internet Me 25 76 2.1.4.3 Read Report Mapping from MMS to Internet Message 26 77 2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet 27 78 2.1.4.4 Disposition Report Mapping from Internet Message t 28 79 2.1.4.4.1 Table 8: Disposition Report Mappings (Internet 28 80 2.1.5 Message Delivery . . . . . . . . . . . . . . . . . . 29 81 3 Security Considerations . . . . . . . . . . . . . . . . . . . 29 82 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 83 5 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 84 6 Normative References . . . . . . . . . . . . . . . . . . . . 30 85 7 Informative References . . . . . . . . . . . . . . . . . . . . 31 86 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . 32 87 Appendix A: Changes Since Last Version . . . . . . . . . . . . 33 88 Intellectual Property Statement . . . . . . . . . . . . . . . 34 89 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 34 91 1 Introduction 93 1.1 Conventions Used in this Document 95 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 96 NOT", and "MAY" in this document are to be interpreted as described 97 in "Key words for use in RFCs to Indicate Requirement Levels" 98 [KEYWORDS]. 100 Gellens [Page 3] Expires April 2006 101 1.2 Scope 103 This document describes how to exchange messages between MMS systems 104 (as defined by 3GPP/3GPP2/OMA) and Internet mail systems (that is, 105 [SMTP] and [Msg-Fmt]). This includes the translation of message 106 formats, message header elements, message delivery reports and 107 message disposition reports ([DSN-Msg] and [MDN]). 109 The MMS architecture [Stage_2] and specifications [Stage_3] refer to 110 interfaces as reference points named MMx. For example, MM1 is the 111 client-server interface, MM4 is the server-server interface, and MM3 112 is an interface to "external" or non-MMS systems. The specification 113 in this document can be used for message exchange between any system 114 which uses Internet Message formats and protocols and an MMS system; 115 from the perspective of the MMS system, reference point MM3 is used. 117 This document includes support for voice messages specified by the 118 Voice Profile for Internet Mail [VPIM]. The VPIM specification 119 allows voice messages to be exchanged between voice mail systems 120 using Internet mail format [Msg-Fmt] and transported via [SMTP]. 121 Thus, the MMS MM3 interface supports the ability to exchange voice 122 messages between an MMS system and a voice mail system. Note that 123 such use is distinct from voice media being part of a user-composed 124 multimedia message. 126 Note that MM3 can also be used for interworking with "external" 127 (non-MMS) systems other than Internet mail, such as Short Messaging 128 Service (SMS) and access to external mail stores (such as a voice 129 mail system). This specification does not address these other uses 130 or sub-interfaces of MM3; it is only concerned with Internet mail 131 interworking and specifically exchange of messages. 133 All MM3 Stage 2 [Stage_2] functions are supported except for reply 134 charging and sender address hiding. 136 1.3 Definitions 138 --------------------|---------------------------------------------- 139 Body |The portion of an [SMTP] message's Content 140 |following the Header (that is, following the 141 |first blank line). The Body may contain 142 |structured parts and sub-parts, each of which 143 |may have their own Header and Body. The Body 144 |contains information intended for the message 145 |recipient (human or software). 146 --------------------|---------------------------------------------- 148 Gellens [Page 4] Expires April 2006 149 --------------------|---------------------------------------------- 150 Content |The portion of an SMTP message that is 151 |delivered. The Content consists of a Header 152 |and a Body. 153 --------------------|---------------------------------------------- 154 Disposition Report |Feedback information to an originator User 155 |Agent by a recipient User Agent about 156 Message Disposition |handling of an original message. This may 157 Notification |include notification that the message was or 158 |was not read, was deleted unread, etc. 159 --------------------|---------------------------------------------- 160 Envelope |The portion of an SMTP message not included in 161 |the Content; that is, not in the Header nor in 162 |the Body. While some of it may be copied into 163 |the Content on delivery, envelope information 164 |only exists while the message is in transit, 165 |and contains information used by SMTP agents 166 |(MTAs). 167 --------------------|---------------------------------------------- 168 Gateway |See [SMTP], Section 2.3.8. 169 --------------------|---------------------------------------------- 170 Header |The first part of an SMTP message's Content. 171 |The Header is separated from the Body by a 172 |blank line. The Header consists of Fields 173 |(such as "To:"), also known as Header Fields 174 |or Headers. The message Header contains 175 |information used by User Agents. 176 --------------------|---------------------------------------------- 177 Relay/Server |An MMS server. See [Stage_2]. For purposes 178 |of this document, an MMS Relay/Server acts as 179 |a gateway when it receives or sends messages 180 |via Internet mail. 181 --------------------|---------------------------------------------- 182 User Agent |An MMS or Email user agent 183 --------------------|---------------------------------------------- 185 Gellens [Page 5] Expires April 2006 186 1.4 Abbreviations 188 --------|---------------------------------------------------------- 189 MSA |Message Submission Agent. A server which accepts messages 190 |from User Agents and processes them; either delivering 191 |them locally or relaying to an MTA. 192 --------|---------------------------------------------------------- 193 MTA |Mail Transfer Agent. A server which implements [SMTP]. 194 --------|---------------------------------------------------------- 196 1.5 Assumptions 198 It is assumed that the reader is already familiar with the contents 199 of the 3GPP2 MMS Specification Overview [Overview], MMS Stage 1 200 (requirements) [Stage_1] and Stage 2 (architecture and abstract 201 messages) [Stage_2], and 3GPP/3GPP2 Stage 3 (protocols) [Stage_3] 202 documents. It is also assumed that the reader is familiar with 203 Internet mail, especially RFC 2821 [SMTP] and RFC 2822 [Msg-Fmt]. 205 2 Mapping Between MMS and Internet Mail 207 This section defines the interworking between MMS Relay/Servers and 208 External Servers using native [SMTP]. That is, information elements 209 are exchanged using standard Internet Message [Msg-Fmt] header 210 fields and standard [SMTP] elements. 212 SMTP and Internet mail extensions are used for features such as 213 delivery reports, message expiration, discovery of server support 214 for optional features, etc. 216 2.1 Mapping Specification 218 2.1.1 MMS to Internet Mail 220 When sending a message to an Internet mail system the MMS 221 Relay/Server MUST convert the MM if required, and MUST comply with 222 the requirements of [SMTP]. 224 The MMS Relay/Server SHOULD use the information elements associated 225 with the MM to define the control information (Internet Message 226 header fields and SMTP envelope values) needed for the transfer 227 protocol. 229 Gellens [Page 6] Expires April 2006 230 Section 2.1.3 lists the mappings between X-Mms-* headers and 231 Internet Message header fields and SMTP values. 233 Delivery and read report MMs SHOULD be converted to standard 234 Internet Message report format (multipart/report). In addition to 235 converting Internet Message reports, the MMS Relay/Server MUST 236 generate delivery and read report MMs for received messages as 237 appropriate. See section 2.1.4 for more information. 239 2.1.2 Internet Mail to MMS 241 When receiving a message from an Internet mail system the MMS 242 Relay/Server converts incoming messages to the MM format used within 243 the receiving system. 245 The MMS Relay/Server converts control information received from the 246 Internet mail server into appropriate information elements of an MM. 248 Section 2.1.3 lists the mappings between X-Mms-* headers and 249 Internet Message header fields and SMTP values. 251 Standard Internet Message report format (multipart/report) messages 252 MAY be converted to delivery or read report MMs, as appropriate. In 253 addition to converting report MMs, implementations conforming to 254 this document MUST generate standard Internet Message delivery and 255 disposition reports for received Internet messages as appropriate. 256 See section 2.1.4 for more information. 258 Gellens [Page 7] Expires April 2006 259 2.1.3 MMS Information Element Mappings 261 The mappings between MMS elements and SMTP/Internet Message elements 262 ([SMTP] parameters, [Msg-Fmt] headers, and [Dsn-Msg] fields) are 263 summarized in the table below, and detailed in subsequent sections. 264 The "MMS Headers" are from [OMA-MMS]. Note that only information 265 elements which need to be mapped are listed. [Msg-Fmt] headers not 266 listed here SHOULD be passed unaltered 268 2.1.3.1 Table 1: Information Element Mappings 270 =================|=================|================|============== 271 Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header 272 =================|=================|================|============== 273 3GPP MMS Version |N/A |N/A |X-Mms-3GPP-MMS 274 | | | -Version: 275 _________________|_________________|________________|______________ 276 Message Type |N/A |N/A |X-Mms-Message- 277 (of PDU) | | | Type: 278 _________________|_________________|________________|______________ 279 Transaction ID |N/A |N/A |X-Mms-Transact 280 | | | ion-Id: 281 _________________|_________________|________________|______________ 282 Message ID |N/A |Message-ID: |Message-ID: 283 _________________|_________________|________________|______________ 284 Recipient |RCPT TO |To:, Cc:, or |To:, Cc:, Bcc: 285 address(es) |address(es) |omitted (Bcc) | 286 _________________|_________________|________________|______________ 287 Sender's address |MAIL FROM |From: |From: 288 |address if | | 289 |user-originated; | | 290 |MUST set MAIL | | 291 |FROM to null | | 292 |("<>") for all | | 293 |automatically- | | 294 |generated MMs | | 295 _________________|_________________|________________|______________ 296 Content type |N/A |Content-Type: |Content-type: 297 | | | 298 | |For voice mes- | 299 | |sages compliant | 300 | |to [VPIM], see | 301 | |Note 2 | 302 =================|=================|================|============== 304 Gellens [Page 8] Expires April 2006 305 =================|=================|================|============== 306 Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header 307 =================|=================|================|============== 308 Message class |Class=auto: |MAY set 'Prece |X-Mms-Message- 309 |MUST set MAIL | dence: bulk' | Class: 310 |FROM to null |on class=auto | 311 |("<>"). | | 312 _________________|_________________|________________|______________ 313 Date and time |N/A |Date: |Date: 314 of submission | | | 315 _________________|_________________|________________|______________ 316 Time of expiry |DELIVER-BY |N/A |X-Mms-Expiry: 317 |[Deliver-By] | | 318 _________________|_________________|________________|______________ 319 Earliest deliv- |(only for submis-|N/A |X-Mms-Delivery 320 ery time |sion; not relay) | | -Time: 321 _________________|_________________|________________|______________ 322 Delivery report |DSN [DSN-SMTP] |N/A |X-Mms-Delivery 323 request |SHOULD also | | -Report: 324 |specify recip- | | 325 |ient address as | | 326 |ORCPT; SHOULD | | 327 |also specify | | 328 |ENVID | | 329 _________________|_________________|________________|______________ 330 Importance (a/k/a|N/A |Importance: |X-Mms- 331 "priority") | | | Priority: 332 | | | 333 | | | 334 _________________|_________________|________________|______________ 335 Sender visib- |(not currently |(not currently |X-Mms-Sender- 336 ility |supported) |supported) | Visibility: 337 _________________|_________________|________________|______________ 338 Read reply |N/A |Disposition- |X-Mms-Read- 339 request | | Notification | Reply: 340 | | -To: [MDN] | 341 _________________|_________________|________________|______________ 342 Reply-charging |(not currently |(not currently |X-Mms-Reply- 343 permission |supported) |supported) | Charging: 344 _________________|_________________|________________|______________ 345 Reply-charging |(not currently |(not currently |X-Mms-Reply- 346 permission |supported) |supported) | Charging- 347 deadline | | | Deadline: 348 _________________|_________________|________________|______________ 349 Reply-charging |(not currently |(not currently |X-Mms-Reply- 350 permission |supported) |supported) | Charging- 351 limitation | | | Size: 352 =================|=================|================|============== 354 Gellens [Page 9] Expires April 2006 355 =================|=================|================|============== 356 Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header 357 =================|=================|================|============== 358 Reply charging |(not currently |(not currently |X-Mms-Reply- 359 usage request |supported) |supported) | Charging- 360 | | | Id: 361 _________________|_________________|________________|______________ 362 Reply charging |(not currently |(not currently |X-Mms-Reply- 363 usage reference |supported) |supported) | Charging: 364 _________________|_________________|________________|______________ 365 Subject |N/A |Subject: |Subject: 366 _________________|_________________|________________|______________ 367 Previously-sent |N/A |Resent-From: |X-Mms-Previous 368 by | | | ly-Sent-By: 369 _________________|_________________|________________|______________ 370 Previously-sent |N/A |Resent-Date: |X-Mms- 371 date | | | Previously- 372 | | | Sent-Date- 373 | | | and-Time: 374 _________________|_________________|________________|______________ 375 Hop/host trace |N/A |Received: |(Not sup- 376 | | |ported) 377 _________________|_________________|________________|______________ 378 Sensitivity |N/A |Sensitivity: see|N/A 379 | |Note 1 | 380 _________________|_________________|________________|______________ 381 Content |N/A | | 382 =================|=================|================|============== 384 Note 1: The [VPIM] 'Sensitivity' header element indicates the 385 privacy requested by the message originator (values are "personal" 386 or "private"); per [VPIM], a message recipient MUST NOT forward a 387 message with a 'Sensitivity' header. Since sensitivity is not an 388 MMS feature, any messages which contain a 'Sensitivity:' header 389 SHOULD NOT be sent to an MMS system. 391 Note 2: [VPIM] specifies how conforming messages are identified. 393 2.1.3.2 Conversion of messages from MMS to Internet format 395 3GPP MMS Version 397 The 'X-Mms-3GPP-MMS-Version:' header, if present, SHOULD be removed. 399 Message Type (of PDU) 401 Gellens [Page 10] Expires April 2006 402 The 'X-Mms-Message-Type:' header, if present, SHOULD be removed. 404 Transaction ID 406 The 'X-Mms-Transaction-Id:' header, if present, SHOULD be removed. 408 Message ID 410 The 'Message-Id:' header MUST be retained. If not present it MUST 411 be created, with a unique value, per [Msg-Fmt]. 413 To facilitate the case where an MMS message traverses the Internet 414 prior to returning to an MMS system, implementations might wish to 415 retain the 'X-Mms-Message-Id:' header. Such systems should be aware 416 that headers which begin with "X-" might be removed during transit 417 through Internet MTAs. 419 Recipient(s) address 421 The address of each recipient MUST be transmitted in the [SMTP] 422 envelope as a RCPT TO value. All disclosed recipients SHOULD also 423 appear in a 'To:' or 'Cc:' header. At least one 'To:', 'Cc:', or 424 'Bcc:' header MUST be present. If none are present, a 'To:' header 425 SHOULD be created using empty group syntax whose name gives an 426 indication to a human reader, for example 'To: 427 undisclosed-recipients:;'. 429 The 'To:' header SHOULD NOT appear more than once. The 'Cc:' header 430 SHOULD NOT appear more than once. 432 Each recipient address MUST obey the length restrictions per [SMTP]. 434 Current Internet message format requires that only 7-bit US-ASCII 435 characters be present in headers. Non-7-bit characters in an 436 address domain must be encoded with [IDN]. If there are any 437 Non-7-bit characters in the local part of an address, the message 438 MUST be rejected. Non-7-bit characters elsewhere in a header MUST 439 be encoded according to [Hdr-Enc]. 441 All recipient addresses in the [SMTP] envelope must be 442 fully-qualified in accordance with [SMTP]. In particular, messages 443 MUST NOT be sent to an Internet mail system with an unqualified 444 E.164 number (i.e., a number with no domain) instead of a 445 fully-qualified domain name. 447 All addresses in 'To:', 'Cc:', and 'Bcc:' headers MUST be in the 448 form of fully-qualified domains. Unqualified E.164 numbers MUST NOT 449 be used. 451 Gellens [Page 11] Expires April 2006 452 Sender address 454 The address of the message sender SHOULD appear in the 'From:' 455 header. 457 The address of the message sender for all user-generated messages 458 ('X-Mms-Message-Class: Personal') SHOULD be transmitted in the 459 [SMTP] envelope as the MAIL FROM value. 461 The return addresses in the [SMTP] envelope must be fully-qualified 462 in accordance with [SMTP]. In particular, messages MUST NOT be sent 463 to an Internet mail system with an E.164 number instead of a 464 fully-qualified domain name. Note that qualified E.164 numbers, 465 that is, those that contain an E.164 number as the local-part of an 466 address that also includes a domain, are acceptable. 468 The address(es) in the 'From:' header SHOULD be in the form of 469 fully-qualified domains. Unqualified E.164 numbers SHOULD NOT be 470 used. 472 Because of the risk of mail loops, it is critical that the MAIL FROM 473 be set to null ("<>") for all automatically-generated MMs (such as 474 'X-Mms-Message-Class: Auto'). The MAIL FROM value MUST be set to 475 null for all automatically-generated messages. This includes 476 reports, "out-of-office" replies, etc. 478 Current Internet message format requires that only 7-bit US-ASCII 479 characters be present in headers. Non-7-bit characters in an 480 address domain must be encoded with [IDN]. If there are any 481 Non-7-bit characters in the local part of an address, the message 482 MUST be rejected. Non-7-bit characters elsewhere in a header MUST 483 be encoded according to [Hdr-Enc]. Note that it would be possible 484 to define an [SMTP] extension to permit transmission of unencoded 485 8-bit characters, but in the absence of such an extension [Hdr-Enc] 486 MUST be used. 488 The sender address MUST obey the length restrictions of [SMTP]. 490 Content type 492 The 'Content-Type:' header SHOULD be preserved. 494 Message class 496 The 'X-Mms-Message-Class:' header MAY be retained in order to 497 provide information on the source of the message. A 'Precedence: 498 bulk' header MAY be inserted for class=auto or class=advertisement. 499 See 'Sender Address' above. (Class=personal and class=informational 500 do not require special handling.) 502 Gellens [Page 12] Expires April 2006 503 Time of Expiry 505 The 'X-Mms-Expiry:' header, if present, SHOULD be removed. 507 The remaining time until the message is considered expired SHOULD be 508 transmitted in the [SMTP] envelope by using the DELIVER-BY extension 509 with a by-mode of "R", as specified in [Deliver-By]. 511 Note that the [SMTP] DELIVER-BY extension carries time remaining 512 until expiration; each server decrements the value by the amount of 513 time it has possessed the message. The 'X-Mms-Expiry:' header may 514 contain either the absolute time at which the message is considered 515 expired or the relative time until the message is considered 516 expired. 518 Earliest delivery time 520 The 'X-Mms-Delivery-Time:' header, if present, SHOULD be removed. 522 Future delivery is a message submission, not message relay feature. 524 Delivery report request 526 Requests for delivery status notifications (DSNs) SHOULD be 527 transmitted in the [SMTP] envelope by using the DSN extension as 528 specified in [DSN-SMTP] to request "success" or "none" notification 529 (depending on the value of the 'X-Mms-Delivery-Report' header). 530 When the NOTIFY extension is used, the unaltered recipient address 531 SHOULD be transmitted as the ORCPT value. 533 The 'X-Mms-Delivery-Report:' header, if present, SHOULD be removed. 535 Importance 537 The message sender's importance value (also called "priority", 538 although this can be confused with class-of-service values) SHOULD 539 be transmitted using an 'Importance:' header. 541 Suggested mappings: 543 2.1.3.2.1 Table 2: Importance Mappings (MMS to Internet Message) 545 ---------------------------|------------------ 546 'X-Mms-Priority: High' |'Importance: High' 547 ---------------------------|------------------ 548 'X-Mms-Priority: Normal' |[omit] 549 ---------------------------|------------------ 550 'X-Mms-Priority: Low' |'Importance: Low' 551 ---------------------------|------------------ 553 Gellens [Page 13] Expires April 2006 554 Normal importance messages should omit the 'Importance:' header. 556 The 'X-Mms-Priority:' header, if present, SHOULD be removed. 558 Sender visibility 560 Support for sender address hiding is not currently supported. 562 A message that contains an 'X-Mms-Sender-Visibility:' header with a 563 value of 'Hide' SHOULD be rejected. 565 The 'X-Mms-Sender-Visibility:' header, if present, SHOULD be 566 removed. 568 Read reply request 570 A request for a read reply SHOULD be transmitted using a 571 'Disposition-Notification-To:' header as specified in [MDN]. 573 The 'X-Mms-Read-Reply:' header, if present, SHOULD be removed. 575 Reply-charging 577 Reply charging permission and acceptance are complex issues 578 requiring both user agent and server support. Misapplied reply 579 charging may cause incorrect billing. Until the security issues 580 have been properly addressed, reply charging SHOULD NOT be honored 581 when using this interface. 583 The 'X-Mms-Reply-Charging:', 'X-Mms-Reply-Charging-Deadline:', 584 'X-Mms-Reply-Charging-Size:', and 'X-Mms-Reply-Charging-Id:' headers 585 MAY be removed. Messages containing a reply-charging usage request 586 ('X-Mms-Reply-Charging-Id:' and 'X-Mms-Reply-Charging: accepted' or 587 'X-Mms-Reply-Charging: accepted (text only)' headers) SHOULD be 588 rejected. 590 Subject 592 The 'Subject:' header MUST be preserved. Current Internet message 593 format requires that only 7-bit US-ASCII characters be present. 594 Other characters MUST be encoded according to [Hdr-Enc]. Note that 595 it is possible for an [SMTP] extension to be defined which would 596 permit transmission of unencoded 8-bit characters, but in the 597 absence of such an extension [Hdr-Enc] MUST be used. 599 Resending 601 Gellens [Page 14] Expires April 2006 602 A message may be resent to one or more new recipients; it may be 603 resent more than once; each time new 'Resent-' headers are added at 604 the top of the existing headers. Thus, if more than one series of 605 'Resent-' headers are present, the original series is the last; the 606 most recent is the first. 608 Forward counter 610 An 'X-Mms-Forward-Counter:' header, if present, SHOULD be removed. 611 The 'Resent-Count:' header is NOT RECOMMENDED. Loop control is 612 usually done by counting 'Received' headers, which are more general 613 than 'Resent-' headers. 615 Previously-Sent Information 617 MMS lists the resending history of a message in two headers: 618 'X-Mms-Previously-Sent-By:' and 619 'X-Mms-Previously-Sent-Date-and-Time:'. 'X-Mms-Previously-Sent-By:' 620 contains a number followed by one or more addresses. 621 'X-Mms-Previously-Sent-Date-and-Time:' contains a number followed by 622 a date-time. With both headers, the number "0" is used for the 623 entry that corresponds to the original submission of the message, 624 with higher values being used for each subsequent resending. The 625 final (most recent) resending information is in the 'From:' and 626 'Date:' headers. There is also an 'X-Mms-Forward-Counter:' that 627 indicates how many times the message has been resent. 629 Any 'X-Mms-Previously-Sent-By:', 630 'X-Mms-Previously-Sent-Date-and-Time:', and 'X-Mms-Forward-Counter:' 631 headers, if present, SHOULD be removed. The information contained 632 in them SHOULD be translated into [Msg-Fmt] headers as follows: 634 The 'X-Mms-Previously-Sent-Date-and-Time:' header whose value starts 635 with "0" SHOULD be used to create a 'Date:' header, converting the 636 date and time from HTTP-date [HTTP] to date-time [Msg-Fmt]. The 637 'X-Mms-Previously-Sent-By:' header whose value starts with "0" 638 SHOULD be used to create a 'From:' header. 640 A 'To:' header SHOULD be created using list syntax with a value of 641 "unrecoverable-recipients" and no mailboxes. 643 A 'Message-ID:' header SHOULD be created. 645 Any 'X-Mms-Previously-Sent-Date-and-Time:' headers whose value 646 starts with "1" or a larger value are mapped to 'Resent-Date:' 647 headers. Any 'X-Mms-Previously-Sent-By:' headers whose value starts 648 with "1" or a larger value are mapped to 'Resent-By:' headers. 650 Gellens [Page 15] Expires April 2006 651 The 'From:', 'To:', 'Date:', and 'Message-ID:' headers are mapped to 652 'Resent-From:', 'Resent-To:', 'Resent-Date:', and 653 'Resent-Message-ID:' headers in the top-most block of 'Resent-*' 654 headers. 656 Example: 658 The MMS message: 660 X-Mms-Forward-Counter: 2 661 X-Mms-Previously-Sent-Date-and-Time: 0, Fri, 01 Apr 2005 06:02:03 GMT 662 X-Mms-Previously-Sent-By: 0, General Failure 663 X-Mms-Previously-Sent-Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT 664 X-Mms-Previously-Sent-By: 1, Colonel Corn 665 Date: Fri, 1 Apr 2005 18:02:03 -0800 666 From: L. Eva Message 667 To: b1ff@mms.example.com 668 Message-ID: <99887766.112233@mail.example.org> 670 is mapped to an Internet mail message: 672 Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800 673 Resent-From: L. Eva Message 674 Resent-To: b1ff@mms.example.com 675 Resent-Message-ID: <99887766.112233@mail.example.org> 676 Resent-Date: Fri, 1 Apr 2005 08:02:03 +0000 677 Resent-From: Colonel Corn 678 Date: Fri, 1 Apr 2005 06:02:03 +0000 679 From: General Failure 680 To: Colonel Corn 681 Message-ID: <000.000.000@gateway.example.org> 683 'Received:' Headers 685 When a message is gatewayed from MMS to Internet mail, a 'Received:' 686 header MUST be added as per [SMTP]. The "with" clause should 687 specify "MMS". 689 A message MAY be rejected if the number of 'Received:' headers 690 exceeds a locally-defined maximum, which MUST conform to [SMTP] 691 section 6.2 and SHOULD be no less than 100. 693 Privacy 695 Note that MMS systems do not currently support the 'Privacy' header 696 field as described by [VPIM]. 698 Gellens [Page 16] Expires April 2006 699 Content 701 The message content appears in the message body. Note that Internet 702 message format requires that line-endings be encoded as US-ASCII CR 703 LF octets, thus charset encodings that do not have this property 704 cannot be used in text/* body parts. (They may be used in other body 705 parts, but only when they are suitably encoded or when binary 706 transmission has been negotiated.) In particular, MMS allows UTF-16, 707 while Internet message format does not. UTF-16 encoding MUST be 708 translated to UTF-8 or another charset and encoding which is 709 suitable for use in Internet message format/protocols. 711 2.1.3.3 Conversion of messages from Internet to MMS format 713 3GPP MMS Version 715 An 'X-Mms-3GPP-MMS-Version:' header SHOULD be added. 717 Message Type (of PDU) 719 An 'X-Mms-Message-Type:' header SHOULD be used in accordance with 720 the specific MMS interface (e.g., MM1, MM4). 722 Transaction ID 724 An 'X-Mms-Transaction-Id:' header SHOULD be used in accordance with 725 the specific MMS interface (e.g., MM1, MM4). 727 Message ID 729 The 'Message-Id:' header MUST be retained. If not present it MUST 730 be created, with a unique value. 732 Recipient(s) address 734 'To:' and 'Cc:' headers MUST be retained. 736 Each recipient contained in the [SMTP] envelope (RCPT TO values) 737 MUST be considered a recipient of the message. Recipients who 738 appear in address headers but not the [SMTP] envelope MUST be 739 ignored. Recipients who appear in the [SMTP] envelope but do not 740 appear in headers are considered "blind" (Bcc) recipients; such 741 recipients MUST NOT be added to message headers (including address 742 and trace headers) unless there is only one recipient total. 744 Gellens [Page 17] Expires April 2006 745 Sender address 747 The 'From:' header MUST be retained. 749 Content type 751 The complete 'Content-Type:' header (including any parameters) 752 SHOULD be preserved. 754 Message class 756 An 'X-Mms-Message-Class: personal' header MAY be created for all 757 received messages with a non-null return path (MAIL FROM value in 758 the SMTP envelope). An 'X-Mms-Message-Class: auto' header MAY be 759 created for messages with a null return path. 761 Time of Expiry 763 An 'X-Mms-Expiry:' header SHOULD be created if the message contains 764 a relative time to expiration in the DELIVER-BY extension with a 765 by-mode of "R", as specified in [Deliver-By]. 767 If the by-mode is "N", a "relayed" DSN MUST be issued per 768 [Deliver-By] and an 'X-Mms-Expiry:' header SHOULD NOT be created. 770 Earliest delivery time 772 An 'X-Mms-Delivery-Time:' header SHOULD NOT be created. 774 Delivery report request 776 An 'X-Mms-Delivery-Report:' header SHOULD be created for messages 777 which request 'success' or 'none' delivery status notification by 778 use of the DSN extension as specified in [DSN-SMTP]. Requests for 779 'delay' notifications or non-default actions, such as that only the 780 message headers should be returned, cannot be mapped onto MMS 781 headers and thus SHOULD be ignored. 783 Importance 785 The message sender's importance value (also called "priority", 786 although this can be confused with class-of-service values) is 787 expressed with an 'Importance:' header. Historically, some clients 788 used the older and non-standard 'X-Priority:' header for this 789 purpose. As a result, some clients generate both. 791 Gellens [Page 18] Expires April 2006 792 An 'X-Priority:' or 'Importance:' header, if present, SHOULD be 793 replaced with an 'X-Mms-Priority:' header. If both headers are 794 present, 'Importance:' SHOULD be used. Suggested mappings: 796 2.1.3.3.1 Table 4: Priority Mappings (Internet Message to MMS) 798 -------------------------------|---------------------- 799 'X-Priority: 1 (highest)' |'X-Mms-Priority: High' 800 -------------------------------|---------------------- 801 'X-Priority: 2 (high)' |'X-Mms-Priority: High' 802 -------------------------------|---------------------- 803 'Importance: High' |'X-Mms-Priority: High' 804 -------------------------------|---------------------- 805 'X-Priority: 3 (normal)' | [omitted] 806 -------------------------------|---------------------- 807 'Importance: Normal' | [omitted] 808 -------------------------------|---------------------- 809 'X-Priority: 4 (low)' |'X-Mms-Priority: Low' 810 -------------------------------|---------------------- 811 'Importance: Low' |'X-Mms-Priority: Low' 812 -------------------------------|---------------------- 813 'X-Priority: 5 (lowest)' |'X-Mms-Priority: Low' 814 -------------------------------|---------------------- 816 Normal importance messages SHOULD omit the 'X-Mms-Priority:' header. 818 Sender visibility 820 Support for sender address hiding is not currently supported. 822 Read reply request 824 A request for a read reply contained in a 825 'Disposition-Notification-To:' header as specified in [MDN] SHOULD 826 be replaced with an 'X-Mms-Read-Reply:' header. 828 Subject 830 The 'Subject:' header MUST be preserved. 832 Resending 834 Mapping from 'Resent-' and other [Msg-Fmt] headers to 835 'X-Mms-Previously-Sent-' headers SHOULD be done as follows: 837 The original 'From:' header is mapped to an 838 'X-Mms-Previously-Sent-By:' header with a leading "0" value. The 839 value of the top-most 'Resent-From:' header is mapped to the 'From:' 840 header. The value of each subsequent 'Resent-From:' header is 842 Gellens [Page 19] Expires April 2006 843 mapped to an 'X-Mms-Previously-Sent-By:' header with the next larger 844 leading value. 846 The original 'Date:' header is mapped to 847 'X-Mms-Previously-Sent-Date-and-Time:' header with a leading "0" 848 value. Note that the value is also converted from date-time syntax 849 [Msg-Fmt] to HTTP-date syntax [HTTP]. The value of the top-most 850 'Resent-Date:' header is mapped to the 'Date:' header. The value of 851 each subsequent 'Date:' header is mapped to an 852 'X-Mms-Previously-Sent-Date-and-Time:' header with the next larger 853 leading value. 855 If one or more 'Resent-Message-ID:' headers are present, the 856 top-most one SHOULD be mapped to 'Message-ID:'; otherwise the 857 'Message-ID:' header should be retained. 859 An 'X-Mms-Forward-Counter:' header SHOULD be created when 'Resent-' 860 headers have been mapped to 'X-Mms-Previously-Sent-' headers. Its 861 value SHOULD be the number of 'Resent-' blocks that existed prior to 862 mapping. 864 Example: 866 The original message: 868 Date: Fri, 1 Apr 2005 14:02:03 -0800 869 From: General Failure 870 To: Colonel Corn 871 Message-ID: 873 Is resent by Colonel Corn to L. Eva Message: 875 Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800 876 Resent-From: Colonel Corn 877 Resent-To: L. Eva Message 878 Resent-Message-ID: 879 Date: Fri, 1 Apr 2005 14:02:03 -0800 880 From: General Failure 881 To: Colonel Corn 882 Message-ID: 884 L. Eva then resends to her MMS device: 886 Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800 887 Resent-From: L. Eva Message 888 Resent-To: b1ff@mms.example.com 889 Resent-Message-ID: <99887766.112233@mail.example.org> 890 Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800 891 Resent-From: Colonel Corn 893 Gellens [Page 20] Expires April 2006 894 Resent-To: L. Eva Message 895 Resent-Message-ID: 896 Date: Fri, 1 Apr 2005 14:02:03 -0800 897 From: General Failure 898 To: Colonel Corn 899 Message-ID: 901 This would be mapped to an MMS message as: 903 X-Mms-Forward-Counter: 2 904 X-Mms-Previously-Sent-Date-and-Time: 0, Fri, 01 Apr 2005 06:02:03 GMT 905 X-Mms-Previously-Sent-By: 0, General Failure 906 X-Mms-Previously-Sent-Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT 907 X-Mms-Previously-Sent-By: 1, Colonel Corn 908 Date: Fri, 1 Apr 2005 18:02:03 -0800 909 From: L. Eva Message 910 To: b1ff@mms.example.com 911 Message-ID: <99887766.112233@mail.example.org> 913 Note that the original 'From:' and 'Date:' values were moved to 914 'X-Mms-Previously-Sent-By:' and 915 'X-Mms-Previously-Sent-Date-and-Time:' headers with a leading "0" 916 value. The first 'Resent-From:' and 'Resent-Date:' values were 917 moved to a second set of 'X-Mms-Previously-Sent-' headers, with a 918 leading "1" value. The third set of 'Resent-' headers were moved to 919 the 'Date:', 'To:', and 'From:' headers. 921 Note also that the format of the date and time differs between the 922 'Date:' / 'Resent-Date:' and the 923 'X-Mms-Previously-Sent-Date-and-Time:' headers, in that the latter 924 use HTTP-date [HTTP] instead of date-time [Msg-Fmt]. 926 'Received:' Headers 928 Each system that processes a message SHOULD add a 'Received:' header 929 as per [SMTP]. A message MAY be rejected if the number of 930 'Received:' headers exceeds a locally-defined maximum, which MUST 931 conform to [SMTP] section 6.2 and SHOULD be no less than 100. 933 Sensitivity 935 The 'Sensitivity:' header field (value = "personal" or "private") 936 [VPIM] indicates the desire of a voice message originator to send 937 the message contents to the original recipient list with assurance 938 that the message will not be forwarded further by either the 939 messaging system or the actual message recipient(s). Since 940 sensitivity is not an MMS feature, any messages which contain a 941 'Sensitivity:' header MUST NOT be sent to an MMS system. The 942 associated negative delivery status report MUST include the extended 944 Gellens [Page 21] Expires April 2006 945 status code [RESP] 5.6.0 as specified in [VPIM] ("Other or undefined 946 protocol status") indicating that privacy could not be assured. 948 Content 950 The message content appears in the message body. 952 2.1.4 Report Generation and Conversion 954 Internet Message systems use the multipart/report MIME type for 955 delivery and disposition reports as specified in [Report-Fmt]. This 956 format is a two- or three-part MIME message; one part is a 957 structured format describing the event being reported in an 958 easy-to-parse format. Specific reports have a format which is built 959 on [Report-Fmt]. Delivery reports are specified in [DSN-Msg]. 960 Message disposition reports, which include read reports, are 961 specified in [MDN]. 963 By contrast, MMS reports are plain text, with no defined structure 964 specified. This makes it difficult to convert from an MMS report to 965 a standard Internet report. 967 An implementation conforming to this specification MUST convert 968 reports received from one side (MMS or Internet mail) destined for 969 the other. In addition, reports MUST be generated as appropriate 970 for messages received from either side. For example, if an MM to be 971 sent via Internet mail is not deliverable, a delivery status MM 972 shall be generated. Likewise, if an Internet message is received 973 that cannot be further relayed or delivered, a delivery status 974 report [DSN-Msg] MUST be generated. 976 When creating delivery or disposition reports from MMS reports, the 977 MMS report should be parsed to determine the reported event and 978 time, status, and the headers of the referenced (original) message. 979 These elements, once determined, are used to populate the subparts 980 of the delivery or disposition report. The first subpart is of type 981 text/plain, and contains a human-readable explanation of the event. 982 This text may include a statement that the report was synthesized 983 based on an MMS report. The second subpart is of type 984 report/delivery-status (for delivery reports) or 985 report/disposition-notification (for disposition reports). This 986 second part contains a structured itemization of the event. The 987 optional third subpart is of type message/rfc822 and includes the 988 headers and optionally the body of the referenced (original) 989 message. Note that, per [Dsn-Msg], the 'DSN-Gateway:' field in 990 delivery reports MUST be created. 992 Gellens [Page 22] Expires April 2006 993 2.1.4.1 Delivery Report Mapping from MMS to Internet Message 995 The following table maps information elements from MMS delivery 996 reports to the format specified in [DSN-Msg]. 998 2.1.4.1.1 Table 5: Delivery Report Mappings (MMS to Internet Message) 1000 ======================|============|=================================== 1001 Information Element |MMS Delivery|[DSN-Msg] Element 1002 |Report Elem | 1003 ======================|============|=================================== 1004 ID of message whose |Message-Id: |'Message-ID:' preserved in third 1005 delivery status is | |subpart of delivery report. 1006 being reported | | 1007 ----------------------|------------|----------------------------------- 1008 Recipient address of |From: |'Final-Recipient' field of the 1009 the original message | |per-recipient section. 1010 (object of delivery | | 1011 report) | | 1012 ----------------------|------------|----------------------------------- 1013 Destination address of|To: |'To:' header field value of top- 1014 report | |level. 1015 ----------------------|------------|----------------------------------- 1016 Date and time the |Date: |'Date:' header field value of top- 1017 message was handled | |level 1018 ======================|============|=================================== 1020 Gellens [Page 23] Expires April 2006 1021 ======================|============|=================================== 1022 Information Element |MMS Delivery|[DSN-Msg] Element 1023 |Report Elem | 1024 ======================|============|=================================== 1025 Delivery status of |X-Mms- |Action and Status fields of 1026 original message to | Status: |per-recipient section. 1027 each recipient | | 1028 | |The 'Action' field indicates if the 1029 | |message was delivered. 1030 | | 1031 | |For failed delivery an appropriate 1032 | |'Status' value shall be included 1033 | |per [DSN-Msg]. 1034 | | 1035 | |The Action field is set to one of 1036 | |the following values: 1037 | | 1038 | |* delivered (used for MMS status 1039 | |values 'retrieved' and 'rejected', 1040 | |depending on 'Status' code). 1041 | | 1042 | |* failed (used for MMS status 1043 | |values 'expired' and 'unreachable') 1044 | | 1045 | |* delayed MAY be used for MMS 1046 | |status value 'deferred' 1047 | | 1048 | |* relayed (used for MMS status 1049 | |value 'indeterminate') 1050 | | 1051 | |* expanded (SHOULD NOT be used) 1052 ----------------------|------------|----------------------------------- 1053 Status Text | |Text in first part (human-readable 1054 | |part) 1055 ----------------------|------------|----------------------------------- 1057 When an MMS Relay/Server generates a [DSN-Msg] in response to a 1058 message received using [SMTP] on MM3: 1060 * Top-level header field 'To:' SHOULD be the [SMTP] return-path of 1061 the message whose status is being reported. 1063 * Top-level header field 'From:' SHOULD be the address of the 1064 recipient that the delivery-report concerns. 1066 * The first part of the [DSN-Msg] SHOULD include the MM Status Text 1067 field that would have been generated for an MM1 delivery-report. 1069 Gellens [Page 24] Expires April 2006 1070 2.1.4.2 Delivery Report Mapping from Internet Message to MMS 1072 The following table maps information elements from a delivery report 1073 as specified in [DSN-Msg] to the format of an MMS delivery report. 1074 Note that a single DSN which reports multiple recipients will result 1075 in several MMS delivery reports. 1077 2.1.4.2.1 Table 6: Delivery Report Mappings (Internet Message to MMS) 1079 ===================|==================|================================ 1080 Information Element|MMS Delivery |[DSN-Msg] Element 1081 |Report Element | 1082 ===================|==================|================================ 1083 ID of the original |Message-Id: |'Message-ID:' header preserved 1084 message (object of | |in third sub-part of report. 1085 delivery report) | | 1086 -------------------|------------------|-------------------------------- 1087 Recipient address |From: |If available, the 'Original 1088 of the original | |-Recipient' field of the per- 1089 message (object of | |recipient section should be 1090 delivery report) | |used; otherwise the 'Final- 1091 | |Recipient' field of the per- 1092 | |recipient section is used 1093 -------------------|------------------|-------------------------------- 1094 Destination address|To: |'To:' header field value of 1095 of report | |top-level. 1096 | | 1097 | |Value taken from [SMTP] envelope 1098 | |return-path of message being 1099 | |reported, not its 'From:' header 1100 | |field. 1101 ===================|==================|================================ 1103 Gellens [Page 25] Expires April 2006 1104 ===================|==================|================================ 1105 Information Element|MMS Delivery |[DSN-Msg] Element 1106 |Report Element | 1107 ===================|==================|================================ 1108 Date and time the |Date: |'Date:' header field value of 1109 message was handled| |top-level 1110 -------------------|------------------|-------------------------------- 1111 Delivery status of |X-Mms-Status: |'Action' and 'Status' fields of 1112 original message | |per-recipient section 1113 |Set to one of the | 1114 |following values: | 1115 | | 1116 |'retrieved' (used | 1117 |for 'Action' value| 1118 |'delivered'). | 1119 | | 1120 |'unreachable' | 1121 |(used for 'Action'| 1122 |value 'failed') | 1123 | | 1124 |'forwarded' (used | 1125 |for 'Action' value| 1126 |'relayed') | 1127 | | 1128 |'deferred' MUST | 1129 |NOT be used | 1130 |(ignore DSNs with | 1131 |'Action' value | 1132 |'delayed') | 1133 -------------------|------------------|-------------------------------- 1134 Status Text | |Text in first part (human- 1135 | |readable part) 1136 ===================|==================|================================ 1138 Gellens [Page 26] Expires April 2006 1139 2.1.4.3 Read Report Mapping from MMS to Internet Message 1141 The following table maps information elements from MMS read reports 1142 to the format specified in [MDN]. 1144 2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet Message) 1146 ======================|============|=================================== 1147 Information Element |MMS Delivery|[MDN] Element 1148 |Report Elem | 1149 ======================|============|=================================== 1150 ID of the original |Message-Id: |'Message-ID:' header preserved in 1151 message (object of | |third part of report. 1152 read report) | | 1153 ----------------------|------------|----------------------------------- 1154 Recipient address of |From: |'Final-Recipient' field 1155 the original message | | 1156 ----------------------|------------|----------------------------------- 1157 Destination address of|To: |'To:' header field value of top- 1158 report | |level. 1159 | | 1160 | |Value taken from 'Disposition- 1161 | |Notification-To:' header field of 1162 | |message being reported, not its 1163 | |'From:' header field. 1164 ----------------------|------------|----------------------------------- 1165 Date and time the |Date: |'Date:' header field value of top- 1166 message was handled | |level 1167 ----------------------|------------|----------------------------------- 1168 Disposition of message|X-Mms-Read- |Disposition-field 1169 being reported | Status: | 1170 | |For X-MMS-Read-Status value 'read', 1171 | |use 'disposition-type' value 1172 | |'displayed'; for X-MMS-Read-Status 1173 | |value 'Deleted without being read', 1174 | |use 'disposition-type' value 1175 | |'deleted') 1176 ----------------------|------------|----------------------------------- 1177 Status Text | |Text in first part (human-readable 1178 | |part) 1179 ======================|============|=================================== 1181 When an MMS Relay/Server generates an [MDN] in response to a message 1182 received using [SMTP] on MM3: 1184 * Top-level header field 'To:' SHOULD be the value of the 1185 'Disposition-Notification-To:' header field of the message whose 1186 disposition is being reported . 1188 Gellens [Page 27] Expires April 2006 1189 * Top-level header field 'From:' SHOULD be the address of the 1190 recipient that the read report concerns. 1192 2.1.4.4 Disposition Report Mapping from Internet Message to MMS 1194 The following table maps information elements from a disposition 1195 report as specified in [MDN] to the format of an MMS read report. 1197 2.1.4.4.1 Table 8: Disposition Report Mappings (Internet Message to 1198 MMS) 1200 ===================|==================|================================ 1201 Information Element|MMS Read Report |[MDN] Element 1202 |Element | 1203 ===================|==================|================================ 1204 ID of the original |Message-Id: |'Message-ID:' header preserved 1205 message (object of | |in third subpart of report. 1206 disposition report)| | 1207 -------------------|------------------|-------------------------------- 1208 Recipient address |From: |'Final-Recipient' field 1209 of the original | | 1210 message | | 1211 -------------------|------------------|-------------------------------- 1212 Destination address|To: |'To:' header field value of 1213 of report | |top-level. 1214 | | 1215 | |Value taken from 'Disposition- 1216 | |Notification-To:' header field 1217 | |of message being reported, not 1218 | |its 'From:' header field. 1219 -------------------|------------------|-------------------------------- 1220 Date and time the |Date: |'Date:' header field value of 1221 message was handled| |top-level 1222 ===================|==================|================================ 1224 Gellens [Page 28] Expires April 2006 1225 ===================|==================|================================ 1226 Information Element|MMS Read Report |[MDN] Element 1227 |Element | 1228 ===================|==================|================================ 1229 Disposition of |X-Mms-Read-Status:|disposition-field 1230 message being | | 1231 reported |Set to one of the | 1232 |following values: | 1233 | | 1234 |'read' (used for | 1235 |disposition-type | 1236 |value 'displayed')| 1237 | | 1238 |'Deleted without | 1239 |being read' (used | 1240 |for disposition- | 1241 |types 'deleted', | 1242 |'denied' and | 1243 |'failed' when | 1244 |action-mode is | 1245 |'automatic- | 1246 |action') | 1247 -------------------|------------------|-------------------------------- 1248 Status Text | |Text in first part (human- 1249 | |readable part) 1250 ===================|==================|================================ 1252 2.1.5 Message Delivery 1254 Within Internet mail, when [SMTP] is used and delivery reports are 1255 requested [DSN-SMTP], delivery is considered to be acceptance of a 1256 message by the final server, that is, the server closest to the 1257 recipient. When an MMS Relay/Server receives a message using [SMTP] 1258 and a delivery report is requested, the MMS Relay/Server MAY 1259 consider the message delivered when it has been sent to the MMS User 1260 Agent. 1262 3 Security Considerations 1264 Both MMS and Internet mail have their own set of security risks and 1265 considerations. This document specifies how to exchange messages 1266 between these two environments, so it is only appropriate to discuss 1267 considerations specific to this functionality, not those inherent in 1268 either environment. 1270 Gellens [Page 29] Expires April 2006 1271 When a message uses end-to-end security mechanisms such as [PGP] or 1272 S/MIME [SMIME], servers MUST be careful not to accidently destroy 1273 the integrity of the protected content (for example, by altering any 1274 text within the region covered by a signature while mapping between 1275 MMS and email). [Mime-Sec-gw] discusses issues with use of such 1276 mechanisms in gateways. 1278 Some MMS features contain inherently more risk than others, 1279 including reply charging and sender address hiding. Support for 1280 these mechanisms are not included in this document. 1282 4 IANA Considerations 1284 IANA is requested to add "MMS" as a "WITH protocol types" under its 1285 "MAIL Parameters" registry. The description is "Multimedia 1286 Messaging Service"; the reference is to this document. 1288 5 Acknowledgments 1290 A number of people contributed to this document, especially the 1291 members of the IETF Lemonade group, including Greg Vaudreuil. John 1292 Klensin did a very thorough and helpful review. Greg White caught a 1293 large number of nits. Ted Hardie was very helpful. Alexey Melnikov 1294 and Chris Newman sent very useful and detailed comments. 1296 6 Normative References 1298 IETF: 1300 [DSN-Msg] "An Extensible Message Format for Delivery Status 1301 Notifications", Moore, Vaudreuil, RFC 3464, January 2003. 1303 [DSN-SMTP] "SMTP Service Extension for Delivery Status 1304 Notifications", Moore, RFC 3461, January 2003. 1306 [Hdr-Enc] "MIME (Multipurpose Internet Mail Extensions) Part Three: 1307 Message Header Extensions for Non-ASCII Text", Moore, RFC 2047, 1308 November 1996. 1310 [HTTP] "Hypertext Transfer Protocol -- HTTP/1.1", Fielding et al, 1311 RFC 2616, June 1999. 1313 [IDN] "Internationalizing Domain Names in Applications (IDNA)", 1314 Faltstrom, Hoffman, Costello, RFC 3490, March 2003. 1316 Gellens [Page 30] Expires April 2006 1318 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 1319 Requirement Levels", RFC 2119, Harvard University, March 1997. 1321 [MDN] "Message Disposition Notification", Hansen, Vaudreuil, RFC 1322 3798, May 2004. 1324 [Msg-Fmt] "Internet Message Format", Resnick, RFC 2822, April 2001. 1326 [Report-Fmt] "The Multipart/Report Content Type for the Reporting of 1327 Mail System Administrative Messages", Vaudreuil, RFC 3462, January 1328 2003 1330 [RESP] "Enhanced Mail System Status Codes", Vaudreuil, RFC 3463, 1331 January 2003. 1333 [SMTP] "Simple Mail Transfer Protocol", Klensin, RFC 2821, April 1334 2001. 1336 OMA: 1338 OMA specifications are available at the OMA web site 1339 . 1341 [OMA-MMS] OMA-WAP-MMS-ENC-V1_2-20040323-C 1343 3GPP2 and 3GPP: 1345 3GPP2 specifications are available at the 3GPP2 (Third 1346 Generation Partnership Project 2) web site 1347 . 1349 3GPP specifications are available at the 3GPP (Third Generation 1350 Partnership Project) web site 1352 [Stage_3] "MMS MM1 Stage 3 using OMA/WAP", X.S0016-310 1354 "MMS MM4 Stage 3 Inter-Carrier Interworking", X.S0016-340 1356 "Multimedia Messaging Service: Functional description; Stage 2", TS 1357 23.140 Release 5. 1359 7 Informative References 1361 IETF: 1363 Gellens [Page 31] Expires April 2006 1365 [BINARY] SMTP Service Extensions for Transmission of Large and 1366 Binary MIME Messages", Vaudreuil, Parsons, RFC 3030, December 2000. 1368 [Codes] "SMTP Service Extension for Returning Enhanced Error Codes", 1369 Freed, RFC 2034, October 1996. 1371 [Deliver-By] "Deliver By SMTP Service Extension", Newman, RFC 2852, 1372 June 2000. 1374 [Hdrs] "Common Internet Message Headers", J. Palme, RFC 2076, 1375 February 1997. 1377 [Mime-Sec-gw] "Gateways and MIME Security Multiparts", N. Freed, RFC 1378 2480, January 1999. 1380 [PGP] "MIME Security with OpenPGP", Elkins, Del Torto, Levien, 1381 Roessler, RFC 3156, August 2001 1383 [SMIME] "S/MIME Version 3 Message Specification", Ramsdell, RFC 1384 2633, June 1999 1386 [Submission] "Message Submission", Gellens, Klensin, RFC 2476, 1387 December 1998. 1389 [VPIM] "Voice Profile for Internet Mail - version 2 (VPIMv2)", 1390 Vaudreuil, Parsons, RFC 3801, June 2004. 1392 [Formats] "Multimedia Messaging Service (MMS) Media Format and 1393 Codecs for cdma2000 Spread Spectrum Systems", C.S0045 1395 [Overview] "Multimedia Messaging Services (MMS) Overview", 1396 X.S0016-000 1398 [Stage_1] "Multimedia Messaging Services (MMS); Stage 1", 1399 Requirements, October 2002, S.R0064-0. 1401 [Stage_2] "Multimedia Messaging Service (MMS); Stage 2", Functional 1402 Specification, April 2003, X.S0016-200. 1404 "Multimedia Messaging Service; Media formats and codecs", 1405 TS26.140Release 5. 1407 8 Author's Address 1409 Randall Gellens 1410 QUALCOMM Incorporated 1411 5775 Morehouse Drive 1412 San Diego, CA 92121 1414 Gellens [Page 32] Expires April 2006 1415 randy@qualcomm.com 1417 Appendix A: Changes Since Last Version 1419 [ This section to be deleted upon publication ] 1421 Changes from -05 to -06: 1422 o Editorial cleanups 1423 o Clarified that X-Priority is an older, non-standard header. 1424 Clarified that if both X-Priority and Importance appear, 1425 Importance SHOULD be used. 1426 o Clarified text regarding E.164 numbers 1427 o Changed SHOULD NOT to MUST NOT on unqualified E.164 numbers in 1428 address headers (otherwise messages are non-replyable) 1429 o Deleted X-Priority mapping table from MMS to Internet Mail 1430 o Deleted wording (accidently pasted) in table on Delivery Report 1431 Mappings (MMS to Internet Message) 1432 o Deleted unused [Auth], [IPSec], and [StartTLS] references 1433 o Rewrote text on mapping between Resent- and 1434 X-Mms-Previously-Sent- headers. 1435 o Corrected text that confused Envelope-ID and Message-ID. 1437 Changes from -04 to -05: 1438 o Abstract now mentions use of X-MMS-* headers in MMS. 1439 o Deleted "(MAY set to locally-generated value to hide sender 1440 identity)" from Table 1. 1441 o Deleted X-Priority from Table 1. 1442 o Replaced comment with empty group syntax' header in section 1443 2.1.3.2. 1444 o Added Acknowledgements section. 1445 o Removed distinction between SMTP/821 and ESMTP/2821. 1446 o Removed discussion of sender address hiding. 1447 o Removed content transformation. 1448 o Replaced "Gateway" with reference to RFC 2821 Section 2.3.8. 1449 o Deleted 'Resent-Count:' 1450 o Deleted background information on resending/forwarding. 1451 o Changed 'Received:' headder generation to MUST on MMS->Internet. 1452 o Specified response code for "sensitivity" as per [VPIM]. 1453 o Changed "sensitivity" response code from SHOULD to MUST. 1454 o Removed reference to RFC 934. 1455 o Removed definition and mentions of anonymous remailer. 1456 o Rewrote and greatly simplified Security Considerations. 1457 o Added "MMS" as a "WITH protocol type" and requested IANA to 1458 register this in its "MAIL Parameters" registry. 1459 o Moved MMS references from Informative to Normative. 1460 o Removed hand-waving about Message-ID. 1461 o Attempted to clarify responsibility for report generation. 1463 Gellens [Page 33] Expires April 2006 1464 Intellectual Property Statement 1466 The IETF takes no position regarding the validity or scope of any 1467 Intellectual Property Rights or other rights that might be claimed 1468 to pertain to the implementation or use of the technology described 1469 in this document or the extent to which any license under such 1470 rights might or might not be available; nor does it represent that 1471 it has made any independent effort to identify any such rights. 1472 Information on the procedures with respect to rights in RFC 1473 documents can be found in BCP 78 and BCP 79. 1475 Copies of IPR disclosures made to the IETF Secretariat and any 1476 assurances of licenses to be made available, or the result of an 1477 attempt made to obtain a general license or permission for the use 1478 of such proprietary rights by implementers or users of this 1479 specification can be obtained from the IETF on-line IPR repository 1480 at http://www.ietf.org/ipr. 1482 The IETF invites any interested party to bring to its attention any 1483 copyrights, patents or patent applications, or other proprietary 1484 rights that may cover technology that may be required to implement 1485 this standard. Please address the information to the IETF at 1486 ietf-ipr@ietf.org. 1488 Full Copyright Statement 1490 Copyright (C) The Internet Society (2005). 1492 This document is subject to the rights, licenses and restrictions 1493 contained in BCP 78, and except as set forth therein, the authors 1494 retain all their rights. 1496 This document and the information contained herein are provided on 1497 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1498 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1499 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1500 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1501 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1502 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1504 Gellens [Page 34] Expires April 2006