idnits 2.17.1 draft-ietf-lemonade-mms-mapping-05.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 1353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1337. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1341), 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. 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 (September 2005) is 6798 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) == Unused Reference: 'Auth' is defined on line 1221, but no explicit reference was found in the text == Unused Reference: 'BINARY' is defined on line 1224, but no explicit reference was found in the text == Unused Reference: 'Codes' is defined on line 1229, but no explicit reference was found in the text == Unused Reference: 'Hdrs' is defined on line 1235, but no explicit reference was found in the text == Unused Reference: 'IPSec' is defined on line 1238, but no explicit reference was found in the text == Unused Reference: 'StartTLS' is defined on line 1250, but no explicit reference was found in the text == Unused Reference: 'Formats' is defined on line 1259, but no explicit reference was found in the text ** 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 2554 (ref. 'Auth') (Obsoleted by RFC 4954) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPSec') (Obsoleted by RFC 4301) -- 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 (~~), 10 warnings (==), 12 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-05.txt Qualcomm 4 Expires: March 2006 September 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 Gellens [Page 1] Expires March 2006 43 One important difference between MMS and Internet Mail is that MMS 44 uses headers which start with "X-Mms-" to carry a variety of user 45 agent and server related information elements. 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 March 2006 53 Table of Contents 55 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 Conventions Used in this Document . . . . . . . . . . . . 3 57 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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: MM3 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.2.2 Table 3: X-Priority Mappings (MMS to Internet 14 70 2.1.3.3 Conversion of messages from Internet to MMS format 16 71 2.1.3.3.1 Table 4: Priority Mappings (Internet Message t 18 72 2.1.4 Report Generation and Conversion . . . . . . . . . . 19 73 2.1.4.1 Delivery Report Mapping from MMS to Internet Messa 20 74 2.1.4.1.1 Table 5: Delivery Report Mappings (MMS to Inte 20 75 2.1.4.2 Delivery Report Mapping from Internet Message to M 21 76 2.1.4.2.1 Table 6: Delivery Report Mappings (Internet Me 22 77 2.1.4.3 Read Report Mapping from MMS to Internet Message . 23 78 2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet 24 79 2.1.4.4 Disposition Report Mapping from Internet Message t 25 80 2.1.4.4.1 Table 8: Disposition Report Mappings (Internet 25 81 2.1.5 Message Delivery . . . . . . . . . . . . . . . . . . . 26 82 3 Security Considerations . . . . . . . . . . . . . . . . . . . 26 83 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 84 5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 85 6 Normative References . . . . . . . . . . . . . . . . . . . . . 27 86 7 Informative References . . . . . . . . . . . . . . . . . . . 28 87 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 29 88 Appendix A: Changes Since Last Version . . . . . . . . . . . . 30 89 Intellectual Property Statement . . . . . . . . . . . . . . . . 30 90 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 31 92 1 Introduction 94 1.1 Conventions Used in this Document 96 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 97 NOT", and "MAY" in this document are to be interpreted as described 98 in "Key words for use in RFCs to Indicate Requirement Levels" 99 [KEYWORDS]. 101 Gellens [Page 3] Expires March 2006 102 1.2 Scope 104 This document describes how to exchange messages between MMS systems 105 (as defined by 3GPP/3GPP2/OMA) and Internet mail systems (that is, 106 [SMTP] and [Msg-Fmt]). This includes the translation of message 107 formats, message header elements, message delivery reports and 108 message disposition reports ([DSN-Msg] and [MDN]). 110 The MMS architecture [Stage_2] and specifications [Stage_3] refer to 111 interfaces as reference points named MMx. For example, MM1 is the 112 client-server interface, MM4 is the server-server interface, and MM3 113 is an interface to "external" or non-MMS systems. The specification 114 in this document can be used for message exchange between any system 115 which uses Internet Message formats and protocols and an MMS system; 116 from the perspective of the MMS system, reference point MM3 is used. 118 This document includes support for voice messages specified by the 119 Voice Profile for Internet Mail [VPIM]. The VPIM specification 120 allows voice messages to be exchanged between voice mail systems 121 using Internet mail format [Msg-Fmt] and transported via [SMTP]. 122 Thus, the MMS MM3 interface supports the ability to exchange voice 123 messages between an MMS system and a voice mail system. Note that 124 such use is distinct from voice media being part of a user-composed 125 multimedia message. 127 Note that MM3 can also be used for interworking with "external" 128 (non-MMS) systems other than Internet mail, such as Short Messaging 129 Service (SMS) and access to external mail stores (such as a voice 130 mail system). This specification does not address these other uses 131 or sub-interfaces of MM3; it is only concerned with Internet mail 132 interworking and specifically exchange of messages. 134 All MM3 Stage 2 [Stage_2] functions are supported except for reply 135 charging and sender address hiding. 137 1.3 Definitions 139 --------------------|---------------------------------------------- 140 Body |The portion of an [SMTP] message's Content 141 |following the Header (that is, following the 142 |first blank line). The Body may contain 143 |structured parts and sub-parts, each of which 144 |may have their own Header and Body. The Body 145 |contains information intended for the message 146 |recipient (human or software). 147 --------------------|---------------------------------------------- 148 Content |The portion of an SMTP message that is 149 |delivered. The Content consists of a Header 151 Gellens [Page 4] Expires March 2006 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. Envelope information only exists 163 |while the message is in transit, and contains 164 |information used by SMTP agents (MTAs). 165 --------------------|---------------------------------------------- 166 Header |The first part of an SMTP message's Content. 167 |The Header is separated from the Body by a 168 |blank line. The Header consists of Fields 169 |(such as "To:"), also known as Header Fields 170 |or Headers. The message Header contains 171 |information used by User Agents. 172 --------------------|---------------------------------------------- 173 Gateway |See [SMTP], Section 2.3.8. 174 --------------------|---------------------------------------------- 175 User Agent |An MMS or Email user agent 176 --------------------|---------------------------------------------- 178 Gellens [Page 5] Expires March 2006 179 1.4 Abbreviations 181 --------|---------------------------------------------------------- 182 MSA |Message Submission Agent. A server which accepts messages 183 |from User Agents and processes them; either delivering 184 |them locally or relaying to an MTA. 185 --------|---------------------------------------------------------- 186 MTA |Mail Transfer Agent. A server which implements [SMTP]. 187 --------|---------------------------------------------------------- 189 1.5 Assumptions 191 It is assumed that the reader is already familiar with the contents 192 of the 3GPP2 MMS Specification Overview [Overview], MMS Stage 1 193 (requirements) [Stage_1] and Stage 2 (architecture and abstract 194 messages) [Stage_2], and 3GPP/3GPP2 Stage 3 (protocols) [Stage_3] 195 documents. It is also assumed that the reader is familiar with 196 Internet mail, especially RFC 2821 [SMTP] and RFC 2822 [Msg-Fmt]. 198 2 Mapping Between MMS and Internet Mail 200 This section defines the interworking between MMS Relay/Servers and 201 External Servers using native [SMTP]. That is, information elements 202 are exchanged using standard Internet Message [Msg-Fmt] header 203 fields and standard [SMTP] elements. 205 SMTP and Internet mail extensions are used for features such as 206 delivery reports, message expiration, discovery of server support 207 for optional features, etc. 209 2.1 Mapping Specification 211 2.1.1 MMS to Internet Mail 213 When sending a message to an Internet mail system the MMS 214 Relay/Server MUST convert the MM if required, and MUST comply with 215 the requirements of [SMTP]. 217 The MMS Relay/Server SHOULD use the information elements associated 218 with the MM to define the control information (Internet Message 219 header fields and SMTP envelope values) needed for the transfer 220 protocol. 222 Gellens [Page 6] Expires March 2006 223 Section 2.1.3 lists the mappings between X-Mms-* headers and 224 Internet Message header fields and SMTP values. 226 Delivery and read report MMs SHOULD be converted to standard 227 Internet Message report format (multipart/report). In addition to 228 converting Internet Message reports, the MMS Relay/Server MUST 229 generate delivery and read report MMs for received messages as 230 appropriate. See section 2.1.4 for more information. 232 2.1.2 Internet Mail to MMS 234 When receiving a message from an Internet mail system the MMS 235 Relay/Server MAY convert incoming messages to the MM format used 236 within the receiving system. 238 The MMS Relay/Server MAY convert control information received from 239 the Internet mail server into appropriate information elements of an 240 MM. 242 Section 2.1.3 lists the mappings between X-Mms-* headers and 243 Internet Message header fields and SMTP values. 245 Standard Internet Message report format (multipart/report) messages 246 MAY be converted to delivery or read report MMs, as appropriate. In 247 addition to converting report MMs, implementations conforming to 248 this document MUST generate standard Internet Message delivery and 249 disposition reports for received Internet messages as appropriate. 250 See section 2.1.4 for more information. 252 Gellens [Page 7] Expires March 2006 253 2.1.3 MMS Information Element Mappings 255 The mappings between MMS elements and SMTP/Internet Message elements 256 (either [SMTP] parameters, [Msg-Fmt] headers, or both) are 257 summarized in the table below, and detailed in subsequent sections. 258 The "MMS Headers" are from [OMA-MMS]. Note that only information 259 elements which need to be mapped are listed. [Msg-Fmt] headers not 260 listed here SHOULD be passed unaltered 262 2.1.3.1 Table 1: MM3 Mappings 264 =================|=================|================|============== 265 Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header 266 =================|=================|================|============== 267 3GPP MMS Version |N/A |N/A |X-Mms-3GPP-MMS 268 | | | -Version: 269 _________________|_________________|________________|______________ 270 Message Type |N/A |N/A |X-Mms-Message- 271 (of PDU) | | | Type: 272 _________________|_________________|________________|______________ 273 Transaction ID |N/A |N/A |X-Mms-Transact 274 | | | ion-Id: 275 _________________|_________________|________________|______________ 276 Message ID |ENVID [DSN-SMTP] |Message-ID: |Message-ID: 277 _________________|_________________|________________|______________ 278 Recipient |RCPT TO |To:, Cc:, or |To:, Cc:, Bcc: 279 address(es) |address(es) |omitted (Bcc) | 280 _________________|_________________|________________|______________ 281 Sender's address |MAIL FROM |From: |From: 282 |address if | | 283 |user-originated; | | 284 |MUST set MAIL | | 285 |FROM to null | | 286 |("<>") for all | | 287 |automatically- | | 288 |generated MMs | | 289 _________________|_________________|________________|______________ 290 Content type |N/A |Content-Type: |Content-type: 291 | | | 292 | |For voice mes- | 293 | |sages compliant | 294 | |to [VPIM], see | 295 | |Note 2 | 296 =================|=================|================|============== 298 Gellens [Page 8] Expires March 2006 299 =================|=================|================|============== 300 Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header 301 =================|=================|================|============== 302 Message class |Class=auto: |MAY set 'Prece |X-Mms-Message- 303 |MUST set MAIL | dence: bulk' | Class: 304 |FROM to null |on class=auto | 305 |("<>"). | | 306 _________________|_________________|________________|______________ 307 Date and time |N/A |Date: |Date: 308 of submission | | | 309 _________________|_________________|________________|______________ 310 Time of expiry |DELIVER-BY |N/A |X-Mms-Expiry: 311 |[Deliver-By] | | 312 _________________|_________________|________________|______________ 313 Earliest deliv- |(only for submis-|N/A |X-Mms-Delivery 314 ery time |sion; not relay) | | -Time: 315 _________________|_________________|________________|______________ 316 Delivery report |DSN [DSN-SMTP] |N/A |X-Mms-Delivery 317 request |SHOULD also | | -Report: 318 |specify recip- | | 319 |ient address as | | 320 |ORCPT; SHOULD | | 321 |also specify | | 322 |ENVID | | 323 _________________|_________________|________________|______________ 324 Importance (a/k/a|N/A |Importance: |X-Mms- 325 "priority") | | | Priority: 326 | | | 327 | | | 328 _________________|_________________|________________|______________ 329 Sender visib- |(not currently |(not currently |X-Mms-Sender- 330 ility |supported) |supported) | Visibility: 331 _________________|_________________|________________|______________ 332 Read reply |N/A |Disposition- |X-Mms-Read- 333 request | | Notification | Reply: 334 | | -To: [MDN] | 335 _________________|_________________|________________|______________ 336 Reply-charging |(not currently |(not currently |X-Mms-Reply- 337 permission |supported) |supported) | Charging: 338 _________________|_________________|________________|______________ 339 Reply-charging |(not currently |(not currently |X-Mms-Reply- 340 permission |supported) |supported) | Charging- 341 deadline | | | Deadline: 342 _________________|_________________|________________|______________ 343 Reply-charging |(not currently |(not currently |X-Mms-Reply- 344 permission |supported) |supported) | Charging- 345 limitation | | | Size: 346 =================|=================|================|============== 348 Gellens [Page 9] Expires March 2006 349 =================|=================|================|============== 350 Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header 351 =================|=================|================|============== 352 Reply-charging |(not currently |(not currently |X-Mms-Reply- 353 usage request |supported) |supported) | Charging- 354 | | | Id: 355 _________________|_________________|________________|______________ 356 Reply-charging |(not currently |(not currently |X-Mms-Reply- 357 usage reference |supported) |supported) | Charging: 358 _________________|_________________|________________|______________ 359 Subject |N/A |Subject: |Subject: 360 _________________|_________________|________________|______________ 361 Previously-sent- |N/A |Resent-From: |X-Mms-Previous 362 by | | | ly-Sent-By: 363 _________________|_________________|________________|______________ 364 Previously-sent- |N/A |Resent-Date: |X-Mms- 365 date and-time | | | Previously- 366 | | | Sent-Date: 367 _________________|_________________|________________|______________ 368 Hop/host trace |N/A |Received: |(Not sup- 369 | | |ported) 370 _________________|_________________|________________|______________ 371 Sensitivity |N/A |Sensitivity: see|N/A 372 | |Note 1 | 373 _________________|_________________|________________|______________ 374 Content |N/A | | 375 =================|=================|================|============== 377 Note 1: The [VPIM] 'Sensitivity' header element indicates the 378 privacy requested by the message originator (values are "personal" 379 or "private"); per [VPIM], a message recipient MUST NOT forward a 380 message with a 'Sensitivity' header. Since sensitivity is not an 381 MMS feature, any messages which contain a 'Sensitivity:' header 382 SHOULD NOT be sent to an MMS system. 384 Note 2: [VPIM] specifies how conforming messages are identified. 386 2.1.3.2 Conversion of messages from MMS to Internet format 388 3GPP MMS Version 390 The 'X-Mms-3GPP-MMS-Version:' header, if present, SHOULD be removed. 392 Message Type (of PDU) 394 Gellens [Page 10] Expires March 2006 395 The 'X-Mms-Message-Type:' header, if present, SHOULD be removed. 397 Transaction ID 399 The 'X-Mms-Transaction-Id:' header, if present, SHOULD be removed. 401 Message ID 403 The 'Message-Id:' header MUST be retained. If not present it MUST 404 be created, with a unique value, per [Msg-Fmt]. 406 The message ID SHOULD be transmitted in the [SMTP] envelope as the 407 ENVID parameter, as specified in [DSN-SMTP]. 409 To facilitate the case where an MMS message traverses the Internet 410 prior to returning to an MMS system, implementations might wish to 411 retain the 'X-Mms-Message-Id:' header. Such systems should be aware 412 that headers which begin with "X-" might be removed during transit 413 through Internet MTAs. 415 Recipient(s) address 417 The address of each recipient MUST be transmitted in the [SMTP] 418 envelope as a RCPT TO value. All disclosed recipients SHOULD also 419 appear in a 'To:' or 'Cc:' header. At least one 'To:', 'Cc:', or 420 'Bcc:' header MUST be present. If all recipients are undisclosed, a 421 'To:' header SHOULD be created using empty group syntax whose name 422 gives an indication to a human reader, for example 'To: 423 undisclosed-recipients:;'. 425 The 'To:' header SHOULD NOT appear more than once. The 'Cc:' header 426 SHOULD NOT appear more than once. 428 Each recipient address MUST obey the length restrictions per [SMTP]. 430 Current Internet message format requires that only 7-bit US-ASCII 431 characters be present in addresses. Other characters (for example, 432 non-7-bit characters in a phrase part of an address header) MUST be 433 encoded according to [Hdr-Enc]. 435 All recipient addresses in the [SMTP] envelope must be 436 fully-qualified in accordance with [SMTP]. In particular, messages 437 MUST NOT be sent to an Internet mail system with an E.164 numbers 438 instead of a fully-qualified domain name. 440 All addresses in 'To:', 'Cc:', and 'Bcc:' headers SHOULD be in the 441 form of fully-qualified domains. Unqualified E.164 numbers SHOULD 442 NOT be used. 444 Gellens [Page 11] Expires March 2006 445 Sender address 447 The address of the message sender SHOULD appear in the 'From:' 448 header. 450 The address of the message sender for all user-generated messages 451 ('X-Mms-Message-Class: Personal') SHOULD be transmitted in the 452 [SMTP] envelope as the MAIL FROM value. 454 The return addresses in the [SMTP] envelope must be fully-qualified 455 in accordance with [SMTP]. In particular, messages MUST NOT be sent 456 to an Internet mail system with an E.164 numbers instead of a 457 fully-qualified domain name. 459 The address(es) in the 'From:' header SHOULD be in the form of 460 fully-qualified domains. Unqualified E.164 numbers SHOULD NOT be 461 used. 463 Because of the risk of mail loops, it is critical that the MAIL FROM 464 be set to null ("<>") for all automatically-generated MMs (such as 465 'X-Mms-Message-Class: Auto'). The MAIL FROM value MUST be set to 466 null for all automatically-generated messages. This includes 467 reports, "out-of-office" replies, etc. 469 Current Internet message format requires that only 7-bit US-ASCII 470 characters be present in addresses. Other characters (for example, 471 non-7-bit characters in a phrase part of an address header) MUST be 472 encoded according to [Hdr-Enc]. Note that it would be possible to 473 define an [SMTP] extension to permit transmission of unencoded 8-bit 474 characters, but in the absence of such an extension [Hdr-Enc] MUST 475 be used. 477 The sender address MUST obey the length restrictions of [SMTP]. 479 Content type 481 The 'Content-Type:' header SHOULD be preserved. 483 Message class 485 The 'X-Mms-Message-Class:' header MAY be retained in order to 486 provide information on the source of the message. A 'Precedence: 487 bulk' header MAY be inserted for class=auto or class=advertisement. 488 See 'Sender Address' above. (Class=personal and class=informational 489 do not require special handling.) 491 Gellens [Page 12] Expires March 2006 492 Time of Expiry 494 The 'X-Mms-Expiry:' header, if present, SHOULD be removed. 496 The remaining time until the message is considered expired SHOULD be 497 transmitted in the [SMTP] envelope by using the DELIVER-BY 498 extension, as specified in [Deliver-By]. 500 Note that the [SMTP] DELIVER-BY extension carries time remaining 501 until expiration; each server decrements the value by the amount of 502 time it has possessed the message. The 'X-Mms-Expiry:' header may 503 contain either the absolute time at which the message is considered 504 expired or the relative time until the message is considered 505 expired. 507 Earliest delivery time 509 The 'X-Mms-Delivery-Time:' header, if present, SHOULD be removed. 511 Future delivery is a message submission, not message relay feature. 513 Delivery report request 515 Requests for delivery status notifications (DSNs) SHOULD be 516 transmitted in the [SMTP] envelope by using the DSN extension as 517 specified in [DSN-SMTP] to request "success" or "none" notification 518 (depending on the value of the 'X-Mms-Delivery-Report' header). 519 When the NOTIFY extension is used, the unaltered recipient address 520 SHOULD be transmitted as the ORCPT value, and the original message 521 ID SHOULD be transmitted as the ENVID value. 523 The 'X-Mms-Delivery-Report:' header, if present, SHOULD be removed. 525 Importance 527 The message sender's importance value (also called "priority", 528 although this can be confused with class-of-service values) SHOULD 529 be transmitted using an 'Importance:' header. 531 Suggested mappings: 533 2.1.3.2.1 Table 2: Importance Mappings (MMS to Internet Message) 535 ---------------------------|------------------ 536 'X-Mms-Priority: High' |'Importance: High' 537 ---------------------------|------------------ 538 'X-Mms-Priority: Normal' |[omit] 539 ---------------------------|------------------ 540 'X-Mms-Priority: Low' |'Importance: Low' 542 Gellens [Page 13] Expires March 2006 543 ---------------------------|------------------ 545 Normal priority messages should omit the 'Importance:' header. 547 2.1.3.2.2 Table 3: X-Priority Mappings (MMS to Internet Message) 549 ---------------------------|---------------------- 550 'X-Mms-Priority: High' |'X-Priority: 2 (high)' 551 ---------------------------|---------------------- 552 'X-Mms-Priority: Normal |[omit] 553 ---------------------------|---------------------- 554 'X-Mms-Priority: Low |'X-Priority: 4 (low)' 555 ---------------------------|---------------------- 557 Normal priority messages SHOULD omit the 'X-Priority:' header. 559 The 'X-Mms-Priority:' header, if present, SHOULD be removed. 561 Sender visibility 563 Support for sender address hiding is not currently supported. 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 Gellens [Page 14] Expires March 2006 591 Subject 593 The 'Subject:' header MUST be preserved. Current Internet message 594 format requires that only 7-bit US-ASCII characters be present. 595 Other characters must be encoded according to [Hdr-Enc]. Note that 596 it is possible for an [SMTP] extension to be defined which would 597 permit transmission of unencoded 8-bit characters, but in the 598 absence of such an extension [Hdr-Enc] must be used. 600 Resending 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 SHOULD be 604 added at the top of the message. 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 The 'Resent-Count:' header is NOT RECOMMENDED. Loop control is 611 usually done by counting 'Received' headers, which are more general 612 than 'Resent-' headers. 614 Previously-sent Information 616 A 'Resent-From:' header MAY be added to indicate the address of the 617 user who directed the message to be resent. 619 A 'Resent-Date:' header SHOULD be added to indicate the time and 620 date that the message was resent. 622 Any 'X-Mms-Previously-Sent-By:' and 'X-Mms-Previously-Sent-Date' 623 headers, if present, SHOULD be removed. The information contained 624 in them SHOULD be translated into 'From:', 'Resent-To:', 625 'Resent-From:', and 'Resent-Date:' headers. The original sender of 626 the message SHOULD appear in the 'From:' header; the original 627 recipient(s) SHOULD appear in the 'To:' header; the time and date 628 the message was originally sent SHOULD appear in the 'Date:' header. 629 The most recent sender SHOULD appear in the top-most 'Resent-From:' 630 header; the most recent recipient(s) SHOULD appear in the top-most 631 'Resent-To:' header; the time and date the message was most recently 632 sent SHOULD appear in the top-most 'Resent-Date:' header. 634 'Received:' Headers 636 When a message is gatewayed from MMS to Internet mail, a 'Received:' 637 header MUST be added as per [SMTP]. The "with" clause should 638 specify "MMS". 640 Gellens [Page 15] Expires March 2006 641 A message MAY be rejected if the number of 'Received:' headers 642 exceeds a locally-defined maximum, which MUST conform to [SMTP] 643 section 6.2 and SHOULD be no less than 100. 645 Privacy 647 Note that MMS systems do not currently support the 'Privacy' header 648 field as described by [VPIM]. 650 Content 652 The message content appears in the message body. Note that Internet 653 message format requires that line-endings be encoded as CR LF, thus 654 charset encodings that do not have this property cannot be used in 655 text/* body parts. (They may be used in other body parts, but only 656 when they are suitable encoded or when binary transmission has been 657 negotiated.) In particular, MMS allows UTF-16, while Internet 658 message format does not. UTF-16 encoding MUST be translated to 659 UTF-8 or another charset and encoding which is suitable for use in 660 Internet message format/protocols. 662 2.1.3.3 Conversion of messages from Internet to MMS format 664 3GPP MMS Version 666 An 'X-Mms-3GPP-MMS-Version:' header SHOULD be added. 668 Message Type (of PDU) 670 An 'X-Mms-Message-Type:' header SHOULD be used in accordance with 671 the specific MMS interface (e.g., MM1, MM4). 673 Transaction ID 675 An 'X-Mms-Transaction-Id:' header SHOULD be used in accordance with 676 the specific MMS interface (e.g., MM1, MM4). 678 Message ID 680 The 'Message-Id:' header MUST be retained. If not present it MUST 681 be created, with a unique value. 683 Recipient(s) address 685 'To:' and 'Cc:' headers MUST be retained. 687 Gellens [Page 16] Expires March 2006 688 Each recipient contained in the [SMTP] envelope (RCPT TO values) 689 MUST be considered a recipient of the message. Recipients who 690 appear in address headers but not the [SMTP] envelope MUST be 691 ignored. Recipients who appear in the [SMTP] envelope but do not 692 appear in headers are considered "blind" (Bcc) recipients; such 693 recipients MUST NOT be added to message headers (including address 694 and trace headers) unless there is only one recipient total. 696 Sender address 698 The 'From:' header MUST be retained. 700 Content type 702 The complete 'Content-Type:' header (including any parameters) 703 SHOULD be preserved. 705 Message class 707 An 'X-Mms-Message-Class: personal' header MAY be created for all 708 received messages with a non-null return path (MAIL FROM value in 709 the SMTP envelope). An 'X-Mms-Message-Class: auto' header MAY be 710 created for messages with a null return path. 712 Time of Expiry 714 An 'X-Mms-Expiry:' header SHOULD be created if the message contains 715 a relative time to expiration in the DELIVER-BY extension, as 716 specified in [Deliver-By]. 718 Earliest delivery time 720 An 'X-Mms-Delivery-Time:' header SHOULD NOT be created. If a 721 message arrives via [SMTP] relay containing an earliest time of 722 delivery in the AFTER extension, it MAY be rejected. If a message 723 is submitted via Message Submission [Submission] containing an 724 earliest time of delivery in the AFTER extension, it MUST either be 725 retained until the delivery time arrives, or it may be immediately 726 rejected. It MUST NOT be delivered or further relayed prior to the 727 delivery time. 729 Delivery report request 731 An 'X-Mms-Delivery-Report:' header SHOULD be created for messages 732 which request 'success' or 'none' delivery status notification by 733 use of the DSN extension as specified in [DSN-SMTP]. Requests for 734 'delay' notifications or non-default actions, such as that only the 735 message headers should be returned, cannot be mapped onto MMS 736 headers and thus SHOULD be ignored. 738 Gellens [Page 17] Expires March 2006 739 Priority 741 An 'X-Priority:' or 'Importance:' header, if present, SHOULD be 742 replaced with an 'X-Mms-Priority:' header. Suggested mappings: 744 2.1.3.3.1 Table 4: Priority Mappings (Internet Message to MMS) 746 -------------------------------|---------------------- 747 'X-Priority: 1 (highest)' |'X-Mms-Priority: High' 748 -------------------------------|---------------------- 749 'X-Priority: 2 (high)' |'X-Mms-Priority: High' 750 -------------------------------|---------------------- 751 'Importance: High' |'X-Mms-Priority: High' 752 -------------------------------|---------------------- 753 'X-Priority: 3 (normal)' | [omitted] 754 -------------------------------|---------------------- 755 'Importance: Normal' | [omitted] 756 -------------------------------|---------------------- 757 'X-Priority: 4 (low)' |'X-Mms-Priority: Low' 758 -------------------------------|---------------------- 759 'Importance: Low' |'X-Mms-Priority: Low' 760 -------------------------------|---------------------- 761 'X-Priority: 5 (lowest)' |'X-Mms-Priority: Low' 762 -------------------------------|---------------------- 764 Normal priority messages SHOULD omit the 'X-Mms-Priority:' header. 766 Sender visibility 768 Support for sender address hiding is not currently supported. 770 Read reply request 772 A request for a read reply contained in a 773 'Disposition-Notification-To:' header as specified in [MDN] SHOULD 774 be replaced with an 'X-Mms-Read-Reply:' header. 776 Subject 778 The 'Subject:' header MUST be preserved. 780 Resending 782 One or more sets of 'Resent-' headers, if present, SHOULD be mapped 783 to 'To:', 'From:', 'Date:', and 'X-Mms-Previously-Sent-' headers. 785 Gellens [Page 18] Expires March 2006 786 'Received:' Headers 788 Each system that processes a message SHOULD add a 'Received:' header 789 as per [SMTP]. A message MAY be rejected if the number of 790 'Received:' headers exceeds a locally-defined maximum, which MUST 791 conform to [SMTP] section 6.2 and SHOULD be no less than 100. 793 Sensitivity 795 The 'Sensitivity:' header field (value = "personal" or "private") 796 [VPIM] indicates the desire of a voice message originator to send 797 the message contents to the original recipient list with assurance 798 that the message will not be forwarded further by either the 799 messaging system or the actual message recipient(s). Since 800 sensitivity is not an MMS feature, any messages which contain a 801 'Sensitivity:' header MUST NOT be sent to an MMS system. The 802 associated negative delivery status report MUST include the extended 803 status code [RESP] 5.6.0 as specified in [VPIM] ("Other or undefined 804 protocol status") indicating that privacy could not be assured. 806 Content 808 The message content appears in the message body. 810 2.1.4 Report Generation and Conversion 812 Internet Message systems use the multipart/report MIME type for 813 delivery and disposition reports as specified in [Report-Fmt]. This 814 format is a two- or three-part MIME message; one part is a 815 structured format describing the event being reported in an 816 easy-to-parse format. Specific reports have a format which is built 817 on [Report-Fmt]. Delivery reports are specified in [DSN-Msg]. 818 Message disposition reports, which include read reports, are 819 specified in [MDN]. 821 By contrast, MMS reports are plain text, with no defined structure 822 specified. This makes it difficult to convert from an MMS report to 823 a standard Internet report. 825 An implementation conforming to this specification MUST convert 826 reports received from one side (MMS or Internet mail) destined for 827 the other. In addition, reports MUST be generated as appropriate 828 for messages received from either side. For example, if an MM to be 829 sent via Internet mail is not deliverable, a delivery status MM 830 shall be generated. Likewise, if an Internet message is received 831 that cannot be further relayed or delivered, a delivery status 832 report [DSN-Msg] MUST be generated. 834 Gellens [Page 19] Expires March 2006 835 When creating delivery or disposition reports from MMS reports, the 836 MMS report should be parsed to determine the reported event and 837 time, status, and the headers of the referenced (original) message. 838 These elements, once determined, are used to populate the subparts 839 of the delivery or disposition report. The first subpart is of type 840 text/plain, and contains a human-readable explanation of the event. 841 This text may include a statement that the report was synthesized 842 based on an MMS report. The second subpart is of type 843 report/delivery-status (for delivery reports) or 844 report/disposition-notification (for disposition reports). This 845 second part contains a structured itemization of the event. The 846 third subpart is of type message/rfc822 and includes the headers and 847 optionally the body of the referenced (original) message. 849 2.1.4.1 Delivery Report Mapping from MMS to Internet Message 851 The following table maps information elements from MMS delivery 852 reports to the format specified in [DSN-Msg]. 854 2.1.4.1.1 Table 5: Delivery Report Mappings (MMS to Internet Message) 856 ======================|============|=================================== 857 Information Element |MMS Delivery|[DSN-Msg] Element 858 |Report Elem | 859 ======================|============|=================================== 860 ID of message whose |Message-Id: |'Original-Envelope-ID' field of 861 delivery status is | |per-message fields (use value of 862 being reported | |ENVID from SMTP envelope if avail- 863 | |able, 'Message-ID:' otherwise). 864 ----------------------|------------|----------------------------------- 865 Recipient address of |From: |'Final-Recipient' field of the 866 the original message | |per-recipient section 867 (object of delivery | | 868 report) | | 869 ----------------------|------------|----------------------------------- 870 Destination address of|To: |'To:' header field value of top- 871 report | |level. 872 | | 873 | |Value taken from [SMTP] envelope 874 | |return-path of message being 875 | |reported, not its 'From:' header 876 | |field. 877 ----------------------|------------|----------------------------------- 878 Date and time the |Date: |'Date:' header field value of top- 879 message was handled | |level 880 ======================|============|=================================== 882 Gellens [Page 20] Expires March 2006 883 ======================|============|=================================== 884 Information Element |MMS Delivery|[DSN-Msg] Element 885 |Report Elem | 886 ======================|============|=================================== 887 Delivery status of |X-Mms- |Action and Status fields of 888 original message to | Status: |per-recipient section. 889 each recipient | | 890 | |The 'Action' field indicates if the 891 | |message was delivered. 892 | | 893 | |For failed delivery an appropriate 894 | |'Status' value shall be included 895 | |per [DSN-Msg]. 896 | | 897 | |The Action field is set to one of 898 | |the following values: 899 | | 900 | |* delivered (used for MMS status 901 | |values 'retrieved' and 'rejected', 902 | |depending on 'Status' code). 903 | | 904 | |* failed (used for MMS status 905 | |values 'expired' and 'unreachable') 906 | | 907 | |* delayed MAY be used for MMS 908 | |status value 'deferred' 909 | | 910 | |* relayed (used for MMS status 911 | |value 'indeterminate') 912 | | 913 | |* expanded (SHOULD NOT be used) 914 ----------------------|------------|----------------------------------- 915 Status Text | |Text in first part (human-readable 916 | |part) 917 ----------------------|------------|----------------------------------- 919 When an MMS Relay/Server generates a [DSN-Msg] in response to a 920 message received using [SMTP] on MM3: 922 * Top-level header field 'To:' SHOULD be the [SMTP] return-path of 923 the message whose status is being reported. 925 * Top-level header field 'From:' SHOULD be the address of the 926 recipient that the delivery-report concerns. 928 * The first part of the [DSN-Msg] SHOULD include the MM Status Text 929 field that would have been generated for an MM1 delivery-report. 931 Gellens [Page 21] Expires March 2006 932 2.1.4.2 Delivery Report Mapping from Internet Message to MMS 934 The following table maps information elements from a delivery report 935 as specified in [DSN-Msg] to the format of an MMS delivery report. 937 2.1.4.2.1 Table 6: Delivery Report Mappings (Internet Message to MMS) 939 ===================|==================|================================ 940 Information Element|MMS Delivery |[DSN-Msg] Element 941 |Report Element | 942 ===================|==================|================================ 943 ID of the original |Message-Id: |'Original-Envelope-ID' field of 944 message (object of | |per-message fields. If not 945 delivery report) | |available, the 'Message-ID' 946 | |header field of the message 947 | |being reported, if included in 948 | |the third part, may be 949 | |substituted. 950 -------------------|------------------|-------------------------------- 951 Recipient address |From: |If available, the 'Original 952 of the original | |-Recipient' field of the per- 953 message (object of | |recipient section should be 954 delivery report) | |used; otherwise the 'Final- 955 | |Recipient' field of the per- 956 | |recipient section is used 957 -------------------|------------------|-------------------------------- 958 Destination address|To: |'To:' header field value of 959 of report | |top-level. 960 | | 961 | |Value taken from [SMTP] envelope 962 | |return-path of message being 963 | |reported, not its 'From:' header 964 | |field. 965 ===================|==================|================================ 967 Gellens [Page 22] Expires March 2006 968 ===================|==================|================================ 969 Information Element|MMS Delivery |[DSN-Msg] Element 970 |Report Element | 971 ===================|==================|================================ 972 Date and time the |Date: |'Date:' header field value of 973 message was handled| |top-level 974 -------------------|------------------|-------------------------------- 975 Delivery status of |X-Mms-Status: |'Action' and 'Status' fields of 976 original message | |per-recipient section 977 |Set to one of the | 978 |following values: | 979 | | 980 |'retrieved' (used | 981 |for 'Action' value| 982 |'delivered'). | 983 | | 984 |'unreachable' | 985 |(used for 'Action'| 986 |value 'failed') | 987 | | 988 |'forwarded' (used | 989 |for 'Action' value| 990 |'relayed') | 991 | | 992 |'deferred' MUST | 993 |NOT be used | 994 |(ignore DSNs with | 995 |'Action' value | 996 |'delayed') | 997 -------------------|------------------|-------------------------------- 998 Status Text | |Text in first part (human- 999 | |readable part) 1000 ===================|==================|================================ 1002 Gellens [Page 23] Expires March 2006 1003 2.1.4.3 Read Report Mapping from MMS to Internet Message 1005 The following table maps information elements from MMS read reports 1006 to the format specified in [MDN]. 1008 2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet Message) 1010 ======================|============|=================================== 1011 Information Element |MMS Delivery|[MDN] Element 1012 |Report Elem | 1013 ======================|============|=================================== 1014 ID of the original |Message-Id: |'Original-Envelope-ID' field (use 1015 message (object of | |value of ENVID from [SMTP] envelope 1016 read report) | |if available, 'Message-ID:' 1017 | |otherwise). 1018 ----------------------|------------|----------------------------------- 1019 Recipient address of |From: |'Final-Recipient' field 1020 the original message | | 1021 ----------------------|------------|----------------------------------- 1022 Destination address of|To: |'To:' header field value of top- 1023 report | |level. 1024 | | 1025 | |Value taken from 'Disposition- 1026 | |Notification-To:' header field of 1027 | |message being reported, not its 1028 | |'From:' header field. 1029 ----------------------|------------|----------------------------------- 1030 Date and time the |Date: |'Date:' header field value of top- 1031 message was handled | |level 1032 ----------------------|------------|----------------------------------- 1033 Disposition of message|X-Mms-Read- |Disposition-field 1034 being reported | Status: | 1035 | |For MMS-Read-Status value 'read', 1036 | |use 'disposition-type' value 1037 | |'displayed'; for MMS-Read-Status 1038 | |value 'Deleted without being read', 1039 | |use 'disposition-type' value 1040 | |'deleted') 1041 ----------------------|------------|----------------------------------- 1042 Status Text | |Text in first part (human-readable 1043 | |part) 1044 ======================|============|=================================== 1046 When an MMS Relay/Server generates an [MDN] in response to a message 1047 received using [SMTP] on MM3: 1049 Gellens [Page 24] Expires March 2006 1050 * Top-level header field 'To:' SHOULD be the value of the 1051 'Disposition-Notification-To:' header field of the message whose 1052 disposition is being reported . 1054 * Top-level header field 'From:' SHOULD be the address of the 1055 recipient that the read report concerns. 1057 2.1.4.4 Disposition Report Mapping from Internet Message to MMS 1059 The following table maps information elements from a disposition 1060 report as specified in [MDN] to the format of an MMS read report. 1062 2.1.4.4.1 Table 8: Disposition Report Mappings (Internet Message to 1063 MMS) 1065 ===================|==================|================================ 1066 Information Element|MMS Read Report |[MDN] Element 1067 |Element | 1068 ===================|==================|================================ 1069 ID of the original |Message-Id: |'Original-Envelope-ID' field 1070 message (object of | | 1071 disposition report)| | 1072 -------------------|------------------|-------------------------------- 1073 Recipient address |From: |'Final-Recipient' field 1074 of the original | | 1075 message | | 1076 -------------------|------------------|-------------------------------- 1077 Destination address|To: |'To:' header field value of 1078 of report | |top-level. 1079 | | 1080 | |Value taken from 'Disposition- 1081 | |Notification-To:' header field 1082 | |of message being reported, not 1083 | |its 'From:' header field. 1084 -------------------|------------------|-------------------------------- 1085 Date and time the |Date: |'Date:' header field value of 1086 message was handled| |top-level 1087 ===================|==================|================================ 1089 Gellens [Page 25] Expires March 2006 1090 ===================|==================|================================ 1091 Information Element|MMS Read Report |[MDN] Element 1092 |Element | 1093 ===================|==================|================================ 1094 Disposition of |X-Mms-Read-Status:|disposition-field 1095 message being | | 1096 reported |Set to one of the | 1097 |following values: | 1098 | | 1099 |'read' (used for | 1100 |disposition-type | 1101 |value 'displayed')| 1102 | | 1103 |'Deleted without | 1104 |being read' (used | 1105 |for disposition- | 1106 |types 'deleted', | 1107 |'denied' and | 1108 |'failed' when | 1109 |action-mode is | 1110 |'automatic- | 1111 |action') | 1112 -------------------|------------------|-------------------------------- 1113 Status Text | |Text in first part (human- 1114 | |readable part) 1115 ===================|==================|================================ 1117 2.1.5 Message Delivery 1119 Within Internet mail, when [SMTP] is used and delivery reports are 1120 requested [DSN-SMTP], delivery is considered to be acceptance of a 1121 message by the final server, that is, the server closest to the 1122 recipient. When an MMS Relay/Server receives a message using [SMTP] 1123 and a delivery report is requested, the MMS Relay/Server MAY 1124 consider the message delivered when it has been sent to the MMS User 1125 Agent. 1127 3 Security Considerations 1129 Both MMS and Internet mail have their own set of security risks and 1130 considerations. This document specifies how to exchange messages 1131 between these two environments, so it is only appropriate to discuss 1132 considerations specific to this functionality, not those inherent in 1133 either environment. 1135 Gellens [Page 26] Expires March 2006 1136 When a message uses end-to-end security mechanisms such as [PGP] or 1137 S/MIME [SMIME], servers MUST be careful not to accidently destroy 1138 the integrity of the protected content (for example, by altering any 1139 text within the region covered by a signature while mapping between 1140 MMS and email). [Mime-Sec-gw] discusses issues with use of such 1141 mechanisms in gateways. 1143 Some MMS features contain inherently more risk than others, 1144 including reply charging and sender address hiding. Support for 1145 these mechanisms are not included in this document. 1147 4 IANA Considerations 1149 IANA is requested to add "MMS" as a "WITH protocol types" under its 1150 "MAIL Parameters" registry. The description is "Multimedia 1151 Messaging Service"; the referece is to this document. 1153 5 Acknowledgements 1155 A number of people contributed to this document, especially the 1156 members of the IETF Lemonade group, including Greg Vaudreuil. John 1157 Klensin did a very thorough and helpful review. Greg White caught a 1158 large number of nits. Ted Hardie was very helpful. 1160 6 Normative References 1162 IETF: 1164 [DSN-Msg] "An Extensible Message Format for Delivery Status 1165 Notifications", Moore, Vaudreuil, RFC 3464, January 2003. 1167 [DSN-SMTP] "SMTP Service Extension for Delivery Status 1168 Notifications", Moore, RFC 3461, January 2003. 1170 [Hdr-Enc] "MIME (Multipurpose Internet Mail Extensions) Part Three: 1171 Message Header Extensions for Non-ASCII Text", Moore, RFC 2047, 1172 November 1996. 1174 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 1175 Requirement Levels", RFC 2119, Harvard University, March 1997. 1177 [MDN] "Message Disposition Notification", Hansen, Vaudreuil, RFC 1178 3798, May 2004. 1180 Gellens [Page 27] Expires March 2006 1182 [Msg-Fmt] "Internet Message Format", Resnick, RFC 2822, April 2001. 1184 [Report-Fmt] "The Multipart/Report Content Type for the Reporting of 1185 Mail System Administrative Messages", Vaudreuil, RFC 3462, January 1186 2003 1188 [RESP] "Enhanced Mail System Status Codes", Vaudreuil, RFC 3463, 1189 January 2003. 1191 [SMTP] "Simple Mail Transfer Protocol", Klensin, RFC 2821, April 1192 2001. 1194 OMA: 1196 OMA specifications are available at the OMA web site 1197 . 1199 [OMA-MMS] OMA-WAP-MMS-ENC-V1_2-20040323-C 1201 3GPP2 and 3GPP: 1203 3GPP2 specifications are available at the 3GPP2 (Third 1204 Generation Partnership Project 2) web site 1205 . 1207 3GPP specifications are available at the 3GPP (Third Generation 1208 Partnership Project) web site 1210 [Stage_3] "MMS MM1 Stage 3 using OMA/WAP", X.S0016-310 1212 "MMS MM4 Stage 3 Inter-Carrier Interworking", X.S0016-340 1214 "Multimedia Messaging Service: Functional description; Stage 2", TS 1215 23.140 Release 5. 1217 7 Informative References 1219 IETF: 1221 [Auth] "SMTP Service Extension for Authentication", Myers, RFC 2554, 1222 March 1999 1224 [BINARY] SMTP Service Extensions for Transmission of Large and 1225 Binary MIME Messages", Vaudreuil, Parsons, RFC 3030, December 2000. 1227 Gellens [Page 28] Expires March 2006 1229 [Codes] "SMTP Service Extension for Returning Enhanced Error Codes", 1230 Freed, RFC 2034, October 1996. 1232 [Deliver-By] "Deliver By SMTP Service Extension", Newman, RFC 2852, 1233 June 2000. 1235 [Hdrs] "Common Internet Message Headers", J. Palme, RFC 2076, 1236 February 1997. 1238 [IPSec] "Security Architecture for the Internet Protocol", Kent, 1239 Atkinson, RFC 2401, November 1998 1241 [Mime-Sec-gw] "Gateways and MIME Security Multiparts", N. Feed, RFC 1242 2480, January 1999. 1244 [PGP] "MIME Security with OpenPGP", Elkins, Del Torto, Levien, 1245 Roessler, RFC 3156, August 2001 1247 [SMIME] "S/MIME Version 3 Message Specification", Ramsdell, RFC 1248 2633, June 1999 1250 [StartTLS] "SMTP Service Extension for Secure SMTP over Transport 1251 Layer Security", Hoffman, RFC 3207, February 2002 1253 [Submission] "Message Submission", Gellens, Klensin, RFC 2476, 1254 December 1998. 1256 [VPIM] "Voice Profile for Internet Mail - version 2 (VPIMv2)", 1257 Vaudreuil, Parsons, RFC 3801, June 2004. 1259 [Formats] "Multimedia Messaging Service (MMS) Media Format and 1260 Codecs for cdma2000 Spread Spectrum Systems", C.S0045 1262 [Overview] "Multimedia Messaging Services (MMS) Overview", 1263 X.S0016-000 1265 [Stage_1] "Multimedia Messaging Services (MMS); Stage 1", 1266 Requirements, October 2002, S.R0064-0. 1268 [Stage_2] "Multimedia Messaging Service (MMS); Stage 2", Functional 1269 Specification, April 2003, X.S0016-200. 1271 "Multimedia Messaging Service; Media formats and codecs", 1272 TS26.140Release 5. 1274 Gellens [Page 29] Expires March 2006 1275 8 Author's Address 1277 Randall Gellens 1278 QUALCOMM Incorporated 1279 5775 Morehouse Drive 1280 San Diego, CA 92121 1281 randy@qualcomm.com 1283 Appendix A: Changes Since Last Version 1285 [ This section to be deleted upon publication ] 1287 Changes from -04 to -05: 1288 o Abstract now mentions use of X-MMS-* headers in MMS. 1289 o Deleted "(MAY set to locally-generated value to hide sender 1290 identity)" from Table 1. 1291 o Deleted X-Priority from Table 1. 1292 o Replaced comment with empty group syntax' header in section 1293 2.1.3.2. 1294 o Added Acknowledgements section. 1295 o Removed distinction between SMTP/821 and ESMTP/2821. 1296 o Removed discussion of sender address hiding. 1297 o Removed content transformation. 1298 o Replaced "Gateway" with reference to RFC 2821 Section 2.3.8. 1299 o Deleted 'Resent-Count:' 1300 o Deleted background information on resending/forwarding. 1301 o Changed 'Received:' headder generation to MUST on MMS->Internet. 1302 o Specified response code for "sensitivity" as per [VPIM]. 1303 o Changed "sensitivity" response code from SHOULD to MUST. 1304 o Removed reference to RFC 934. 1305 o Removed definition and mentions of anonymous remailer. 1306 o Rewrote and greatly simplified Security Considerations. 1307 o Added "MMS" as a "WITH protocol type" and requested IANA to 1308 register this in its "MAIL Parameters" registry. 1309 o Moved MMS references from Informative to Normative. 1310 o Removed hand-waving about Message-ID. 1311 o Attempted to clarify responsibility for report generation. 1313 Intellectual Property Statement 1315 The IETF takes no position regarding the validity or scope of any 1316 Intellectual Property Rights or other rights that might be claimed 1317 to pertain to the implementation or use of the technology described 1318 in this document or the extent to which any license under such 1319 rights might or might not be available; nor does it represent that 1320 it has made any independent effort to identify any such rights. 1321 Information on the procedures with respect to rights in RFC 1323 Gellens [Page 30] Expires March 2006 1324 documents can be found in BCP 78 and BCP 79. 1326 Copies of IPR disclosures made to the IETF Secretariat and any 1327 assurances of licenses to be made available, or the result of an 1328 attempt made to obtain a general license or permission for the use 1329 of such proprietary rights by implementers or users of this 1330 specification can be obtained from the IETF on-line IPR repository 1331 at http://www.ietf.org/ipr. 1333 The IETF invites any interested party to bring to its attention any 1334 copyrights, patents or patent applications, or other proprietary 1335 rights that may cover technology that may be required to implement 1336 this standard. Please address the information to the IETF at 1337 ietf-ipr@ietf.org. 1339 Full Copyright Statement 1341 Copyright (C) The Internet Society (2005). 1343 This document is subject to the rights, licenses and restrictions 1344 contained in BCP 78, and except as set forth therein, the authors 1345 retain all their rights. 1347 This document and the information contained herein are provided on 1348 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1349 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1350 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1351 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1352 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1353 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1355 Gellens [Page 31] Expires March 2006