idnits 2.17.1 draft-gellens-lemonade-mms-mapping-00.txt: -(848): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 4 instances of lines with non-ascii characters in the document. == 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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Gellens [Page 10] Expires December 2003 Note that even if servers claim to support address hiding, there is no technical guarantee that it will be properly honored; servers MUST not trust other servers to support this without a basis which is beyond the scope of this specification (such as business relationships). -- 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 (June 2003) is 7620 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: 'Future-Deliv' is defined on line 787, but no explicit reference was found in the text == Unused Reference: 'Msg-Encap' is defined on line 794, but no explicit reference was found in the text == Unused Reference: 'Formats' is defined on line 851, but no explicit reference was found in the text == Unused Reference: 'Hdrs' is defined on line 862, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'OMA-MMS' -- No information found for draft-vaudreuil-futuredelivery-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Future-Deliv' ** Downref: Normative reference to an Unknown state RFC: RFC 934 (ref. 'Msg-Encap') ** Obsolete normative reference: RFC 1891 (ref. 'DSN') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 2476 (ref. 'Submission') (Obsoleted by RFC 4409) ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (ref. 'Msg-Fmt') (Obsoleted by RFC 5322) -- Duplicate reference: RFC934, mentioned in 'Encap', was also mentioned in 'Msg-Encap'. Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 7 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-gellens-lemonade-mms-mapping-00.txt Qualcomm 4 Expires: December 2003 June 2003 6 Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet- Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 26 The list of Internet-Draft Shadow Directories can be accessed at 27 . 29 Copyright Notice 31 Copyright (C) The Internet Society (2003). All Rights Reserved. 33 Abstract 35 The cellular telephone industry has defined a service known as the 36 Multimedia Messaging Service (MMS). This service uses formats and 37 protocols which are similar to, but differ in key ways from those 38 used in Internet mail. 40 This document specifies how to exchange messages between these two 41 services, including mapping information elements as used in MMS 42 X-MMS-* headers to and from that used in ESMTP and Internet message 43 headers. 45 Gellens [Page 1] Expires December 2003 46 Table of Contents 48 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 49 1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.2 Conventions Used in this Document . . . . . . . . . . . . 3 51 1.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3 52 2 Mapping Between MMS and Internet Mail . . . . . . . . . . . . 3 53 2.1 Mapping Specification . . . . . . . . . . . . . . . . . . 3 54 2.1.1 Sending MMs . . . . . . . . . . . . . . . . . . . . . 3 55 2.1.2 Receiving messages . . . . . . . . . . . . . . . . . 4 56 2.1.3 MMS Information Element Mappings . . . . . . . . . . . 4 57 2.1.3.1 Conversion of messages from MMS to Internet format 7 58 2.1.3.2 Conversion of messages from Internet to MMS format 13 59 2.1.4 Report Conversion . . . . . . . . . . . . . . . . . . 16 60 2.1.5 Message Delivery . . . . . . . . . . . . . . . . . . . 16 61 3 Security Considerations . . . . . . . . . . . . . . . . . . . 17 62 4 Normative References . . . . . . . . . . . . . . . . . . . . . 17 63 5 Informative References . . . . . . . . . . . . . . . . . . . 19 64 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20 65 Intellectual Property Statement . . . . . . . . . . . . . . . 20 66 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 21 68 1 Introduction 70 1.1 Scope 72 This specification describes how to exchange messages with Internet 73 mail systems. This includes translation between MMS (as defined by 74 3GPP/3GPP2/OMA) and Internet Mail messages using Extended Simple 75 Mail Transfer Protocol [SMTP] and Internet mail format [Msg-Fmt]. 77 The MMS architecture [Stage_2] and specifications [Stage_3] refer to 78 interfaces as reference points named MMx. For example, MM1 is the 79 client-server interface, MM4 is the server-server interface, and MM3 80 is an interface to "external" or non-MMS systems. The specification 81 in this document be used on MMS reference point MM3 to exchange 82 messages between MMS systems and any system which uses Internet 83 Message formats and protocols. 85 Note that MM3 can also be used for interworking with "external" 86 (non-MMS) systems other than SMTP-based, such as Short Messaging 87 Service (SMS) and access to external mail stores (such as a voice 88 mail system). This specification does not address these other uses 89 or sub-interfaces of MM3; it is only concerned with Internet mail 90 interworking and specifically exchange of messages. 92 Gellens [Page 2] Expires December 2003 93 All MM3 Stage 2 [Stage_2] functions are supported except for reply 94 charging. Sender address hiding may be used but is not recommended 95 without security assurances which are beyond the scope of this 96 specification (see Section 3). 98 1.2 Conventions Used in this Document 100 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 101 NOT", and "MAY" in this document are to be interpreted as described 102 in "Key words for use in RFCs to Indicate Requirement Levels" 103 [KEYWORDS]. 105 1.3 Assumptions 107 It is assumed that the reader is already familiar with the contents 108 of the 3GPP2 MMS Specification Overview [Overview], MMS Stage 1 109 (requirements) [Stage_1] and Stage 2 (architecture and abstract 110 messages) [Stage_2], and 3GPP/3GPP2 Stage 3 (protocols) [Stage_3] 111 documents. It is also assumed that the reader is familiar with 112 Internet mail, especially RFC 2821 [SMTP] and RFC 2822 [Msg-Fmt]. 114 2 Mapping Between MMS and Internet Mail 116 This section defines the interworking between MMS Relay/Servers and 117 External Servers using native ESMTP. That is, information elements 118 are exchanged using standard Internet Message [Msg-Fmt] header 119 fields and standard [SMTP] elements. 121 SMTP and Internet mail extensions are used for features such as 122 delivery reports, message expiration, discovery of server support 123 for optional features, etc. 125 2.1 Mapping Specification 127 2.1.1 Sending MMs 129 When sending an MM to an external messaging system such an Internet 130 mail system, the originator MMS Relay/Server SHOULD convert the MM 131 if required. 133 Gellens [Page 3] Expires December 2003 134 The originator MMS Relay/Server SHOULD use the information elements 135 associated with the MM to define the control information (Internet 136 Message header fields and ESMTP values) needed for the transfer 137 protocol. The originator MMS Relay/Server MAY also use the 138 information elements associated with the MM to convey these within 139 the converted message. 141 Section 2.1.3 lists the mappings between X-MMS-* headers and 142 Internet Message header fields and ESMTP values. 144 Delivery and read report MMs SHOULD be converted to standard 145 Internet Message report format (multipart/report) to the extent 146 possible. 148 2.1.2 Receiving messages 150 When receiving a message from an external messaging system the 151 recipient MMS Relay/Server MAY convert incoming messages to the MM 152 format used within the receiving system. 154 The recipient MMS Relay/Server MAY convert control information 155 received from the External Server into appropriate information 156 elements of an MM. 158 Section 2.1.3 lists the mappings between X-MMS-* headers and 159 Internet Message header fields and ESMTP values. 161 Standard Internet Message report format (multipart/report) messages 162 MAY be converted to delivery or read report MMS, as appropriate. 164 Gellens [Page 4] Expires December 2003 165 2.1.3 MMS Information Element Mappings 167 The mappings between MMS elements and ESMTP/Internet Message 168 elements are detailed below. The MMS Headers listed are from 169 [OMA-MMS]. 171 _________________|_________________|________________|______________ 172 Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header 173 _________________|_________________|________________|______________ 174 3GPP MMS Version |................ |x-mms-mms- |x-mms- 175 | | version: | version: 176 _________________|_________________|________________|______________ 177 Message Type |N/A |N/A |x-mms-message- 178 (of PDU) | | | type: 179 _________________|_________________|________________|______________ 180 Transaction ID |N/A |N/A |x-mms-transact 181 | | | ion-id: 182 _________________|_________________|________________|______________ 183 Message ID |ENVID [DSN] |Message-ID: |Message-id: 184 _________________|_________________|________________|______________ 185 Recipient |RCPT TO |To:, Cc:, or |To:, Cc:, Bcc: 186 address(es) |address(es) |omitted (bcc) | 187 _________________|_________________|________________|______________ 188 Sender's address |MAIL FROM |From: (MAY set |From: 189 |address if |to locally-gen- | 190 |user-originated; |erated value | 191 |MUST set MAIL |to hide sender | 192 |FROM to null |identity in | 193 |("<>") for all |anonymous mes- | 194 |automatically- |sages when | 195 |generated MMs |receiving sys- | 196 | |tem does not | 197 | |support anony- | 198 | |mous messages) | 199 _________________|_________________|________________|______________ 200 Content type |................ |Content-Type: |Content-type: 201 _________________|_________________|________________|______________ 202 Message class |Class=auto: |MAY set 'Prece |x-mms-message- 203 |MUST set MAIL | dence: bulk' | class: 204 |FROM to null |on class=auto | 205 |("<>"). | | 206 _________________|_________________|________________|______________ 207 Date and time |................ |Date: |Date: 208 _________________|_________________|________________|______________ 209 Time of expiry |DELIVER-BY |............... |x-mms-expiry: 210 |[Deliver-By] | | 211 _________________|_________________|________________|______________ 212 Earliest deliv- |AFTER [Future- |............... |x-mms-delivery 213 ery time |Deliv] | | -time: 215 Gellens [Page 5] Expires December 2003 216 _________________|_________________|________________|______________ 217 Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header 218 _________________|_________________|________________|______________ 219 Delivery report |NOTIFY [DSN] |............... |x-mms-delivery 220 request |SHOULD also | | -report: 221 |specify recip- | | 222 |ient address as | | 223 |ORCPT; SHOULD | | 224 |also specify | | 225 |ENVID | | 226 _________________|_________________|________________|______________ 227 Importance |................ |X-Priority: |x-mms- 228 | |(MAY use | priority: 229 | |'Importance' | 230 | |instead). | 231 _________________|_________________|________________|______________ 232 Sender visib- |X-ANONYMOUS (see |............... |x-mms-sender- 233 ility |text below) | | visibility: 234 _________________|_________________|________________|______________ 235 Read reply |................ |Disposition- |x-mms-read- 236 request | | Notification | reply: 237 | | -To: [MDN] | 238 _________________|_________________|________________|______________ 239 Reply-charging |(not currently |(not currently |x-mms-reply- 240 permission |supported) |supported) | charging: 241 _________________|_________________|________________|______________ 242 Reply-charging |(not currently |(not currently |x-mms-reply- 243 permission |supported) |supported) | charging- 244 deadline | | | deadline: 245 _________________|_________________|________________|______________ 246 Reply-charging |(not currently |(not currently |x-mms-reply- 247 permission |supported) |supported) | charging- 248 limitation | | | size: 249 _________________|_________________|________________|______________ 250 Reply-charging |(not currently |(not currently |x-mms-reply- 251 usage request |supported) |supported) | charging- 252 | | | id: 253 _________________|_________________|________________|______________ 254 Reply-charging |(not currently |(not currently |x-mms-reply- 255 usage reference |supported) |supported) | charging: 256 _________________|_________________|________________|______________ 257 Subject |................ |Subject: |Subject: 258 _________________|_________________|________________|______________ 259 Forward counter |................ |Resent-Count: |(Not sup- 260 | | |ported) 261 _________________|_________________|________________|______________ 262 Previously-sent- |................ |Resent-From: |x-mms-previous 263 by | | | ly-sent-by: 264 _________________|_________________|________________|______________ 266 Gellens [Page 6] Expires December 2003 267 _________________|_________________|________________|______________ 268 Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header 269 _________________|_________________|________________|______________ 270 Previously-sent- |................ |Resent-Date: |x-mms- 271 date and-time | | | previously- 272 | | | sent-date: 273 _________________|_________________|________________|______________ 274 Hop/host trace |................ |Received: |(Not sup- 275 | | |ported) 276 _________________|_________________|________________|______________ 277 Content |................ | | 279 2.1.3.1 Conversion of messages from MMS to Internet format 281 3GPP MMS Version 283 The 'x-mms-mms-version:' header, if present, MAY be retained. 285 Message Type (of PDU) 287 The 'x-mms-message-type:' header, if present, SHOULD be removed. 289 Transaction ID 291 The 'x-mms-transaction-id:' header, if present, SHOULD be removed. 293 Message ID 295 The 'Message-ID:' header MUST be retained. If not present it MUST 296 be created, with a unique value. The message ID SHOULD be 297 transmitted in the SMTP envelope as the ENVID parameter, as 298 specified in [DSN]. 300 Recipient(s) address 302 The address of each recipient MUST be transmitted in the SMTP 303 envelope as a RCPT TO value. All disclosed recipients SHOULD also 304 appear in a 'To:' or 'Cc:' header. At least one 'To:' or 'Cc:' 305 header MUST be present. If all recipients are undisclosed, a 'To:' 306 header MAY be created that contains a comment, for example 'To: 307 (undisclosed recipients)'. The 'To:' header SHOULD NOT appear more 308 than once. The 'Cc:' header SHOULD NOT appear more than once. 310 Gellens [Page 7] Expires December 2003 311 Each recipient address MUST obey the length restrictions per [SMTP] 312 and [Msg-Fmt]. 314 Current Internet message format requires that only 7-bit US-ASCII 315 characters be present. Other characters (for example, non-7-bit 316 characters in a phrase part of an address header) must be encoded 317 according to [Hdr-Enc]. Note that it would be possible to define an 318 SMTP extension to permit transmission of unencoded 8-bit characters, 319 but in the absence of such an extension [Hdr-Enc] must be used. 321 Sender address 323 The address of the message sender SHOULD appear in the 'From:' 324 header, unless address hiding has been requested. If address hiding 325 has been requested, the 'From:' header MAY contain a comment to this 326 effect, for example, 'From: (anonymous sender)'. 328 The address of the message sender for all user-generated messages 329 ('X-Mms-Message-Class: personal') SHOULD be transmitted in the SMTP 330 envelope as the MAIL FROM value unless address hiding has been 331 requested and the receiving server is not known to support address 332 hiding. 334 The 'From:' header and the MAIL FROM value MAY set to a 335 locally-generated value to hide the sender identity in anonymous 336 messages when the receiving system does not support anonymous 337 messages. Locally generated addressed MAY be internally mapped to 338 the actual address to allow replies to anonymous messages, but such 339 mapping is beyond the scope of this specification. 341 Because of the risk of mail loops, it is critical that the MAIL FROM 342 be set to null ("<>") for all automatically-generated MMs 343 ('X-Mms-Message-Class: auto'). The MAIL FROM value MUST be set to 344 null for all automatically -generated messages. 346 Current Internet message format requires that only 7-bit US-ASCII 347 characters be present. Other characters (for example, non-7-bit 348 characters in a phrase part of an address header) must be encoded 349 according to [Hdr-Enc]. Note that it would be possible to define an 350 SMTP extension to permit transmission of unencoded 8-bit characters, 351 but in the absence of such an extension [Hdr-Enc] must be used. 353 Gellens [Page 8] Expires December 2003 354 The sender address MUST obey the length restrictions of [SMTP] and 355 [Msg-Fmt]. 357 Content type 359 The 'Content-Type:' header SHOULD be preserved. Content types not 360 in widespread use in the Internet MAY be converted into those that 361 are, when such conversion can be done without loss of content. For 362 example, SMIL messages MAY be converted into widely-supported 363 multipart/related with multipart/html. 365 Message class 367 The 'x-mms-message-class:' header SHOULD be removed. A 'Precedence: 368 bulk' header MAY be inserted for class=auto. See 'Sender Address' 369 above. 371 Time of Expiry 373 The 'x-mms - expiry:' header, if present, SHOULD be removed. 375 The remaining time until the message is considered expired SHOULD be 376 transmitted in the SMTP envelope by using the DELIVER-BY extension, 377 as specified in [Deliver-By]. 379 Note that the ESMTP DELIVER-BY extension carries remaining time 380 until expiration; each server decrements the value by the amount of 381 time it has possessed the message. The 'x-mms-expiry:' header may 382 contain either the absolute time at which the message is considered 383 expired or the relative time until the message SHOULD be expired. 385 Earliest delivery time 387 The 'x-mms-delivery-time:' header , if present, SHOULD be removed. 389 Messages SHOULD be retained at the original server until the 390 earliest delivery time has been reached. On message submission, the 391 client MAY indicate the remaining time until relay or delivery is 392 permitted by using the AFTER extension as proposed in 393 draft-vaudreuil-futuredelivery-xx.txt. 395 Note that the ESMTP AFTER extension carries the amount of time that 396 the original server is required to retain the message before it may 397 be relayed or delivered. The 'x-mms-delivery-time:' header may 398 contain either the absolute or relative time. 400 Gellens [Page 9] Expires December 2003 401 Delivery report request 403 Requests for delivery status notification (DSN) SHOULD be 404 transmitted in the SMTP envelope by using the DSN extension as 405 specified in [DSN] to request "success" or "none" notification 406 (depending on the value of the 'x-mms'delivery-report' header). 407 When the NOTIFY extension is used, the unaltered recipient address 408 SHOULD be transmitted as the ORCPT value, and the original message 409 ID SHOULD be transmitted as the ENVID value. 411 The 'x-mms-delivery-report:' header, if present, SHOULD be removed. 413 Importance 415 Message importance (also known as priority) SHOULD be transmitted 416 using an 'X-Priority:' header. 418 Although not standardized, many email applications support the 419 'X-Priority:' header, and use an 'X-Priority' value of 3 for 420 messages with "normal" priority. More important messages have lower 421 values and less important message have higher values. In most 422 cases, urgent messages have an X-Priority value of 1. 424 Suggested mappings for 'x-priority:' follow: 426 'X-Mms-Priority: High' 'X-Priority: 2 (high)' 427 'X-Mms-Priority: Normal [omit] 428 'X-Mms-Priority: Low 'X-Priority: 4 (low)' 430 Normal priority messages SHOULD omit the 'X-Priority:' header. 432 Message importance MAY instead be transmitted using an 'Importance:' 433 header with one of the values 'high', 'normal', or 'low'. 435 The 'x-mms-priority:' header, if present, SHOULD be removed. 437 Sender visibility 439 Requests for sender address hiding MAY be transmitted in the SMTP 440 envelope by using the X-ANONYMOUS extension. The request is made by 441 adding "X-ANONYMOUS" to the MAIL FROM command. Servers which 442 support address hiding MAY advertise this by including X-ANONYMOUS 443 in their EHLO response. 445 Gellens [Page 10] Expires December 2003 446 Note that even if servers claim to support address hiding, there is 447 no technical guarantee that it will be properly honored; servers 448 MUST not trust other servers to support this without a basis which 449 is beyond the scope of this specification (such as business 450 relationships). 452 The 'x-mms-sender-visibility:' header, if present, SHOULD be 453 removed. 455 Read reply request 457 A request for a read reply SHOULD be transmitted using a 458 'Disposition-Notification-To:' header as specified in [MDN]. 460 The 'x-mms-read-reply:' header, if present, SHOULD be removed. 462 Reply-charging 464 Reply charging permission and acceptance are complex issues 465 requiring both user agent and server support. Misapplied reply 466 charging may cause incorrect billing. Until the security issues 467 have been properly addressed, reply charging SHOULD NOT be honored 468 when using this interface. 470 The 'x-mms-reply-charging:', 'x-mms-reply-charging-deadline:', 471 'x-mms-reply-charging-size:', and 'x-mms-reply-charging-id:' headers 472 MAY be removed. Messages containing a reply-charging usage request 473 ('x-mms-reply-charging-id:' and 'x-mms-reply-charging: accepted' or 474 'x-mms-reply-charging: accepted (text only)' headers) SHOULD be 475 rejected. 477 Subject 479 The 'Subject:' header MUST be preserved. Current Internet message 480 format requires that only 7-bit US-ASCII characters be present. 481 Other characters must be encoded according to [Hdr-Enc]. Note that 482 it would be possible to define an SMTP extension to permit 483 transmission of unencoded 8-bit characters, but in the absence of 484 such an extension [Hdr-Enc] must be used. 486 Resending/Forwarding 488 Gellens [Page 11] Expires December 2003 489 In Internet mail, there are two primary ways of sending a previously 490 received message to a new recipient: forwarding and resending. 491 Forwarding is when a user creates a new message containing the 492 original message, either simply embedded within the text, or 493 delineated. Embedded messages generally have each original line 494 preceded by a quote symbol ('>'), surround the original text with a 495 preceding and trailing line which starts with hyphens as per 496 [Encap], such as '--- begin forwarded text' and '--- end forwarded 497 text', or encapsulate the original message as a 'message/rfc822' 498 content type, perhaps within a 'multipart/mixed' message. (This last 499 method offers more robust delineation.) Resending is when the 500 original message is unaltered except for the possible addition of 501 'resent-' headers to explain the resending to the new recipient. 503 A message may be resent more than once; each time new 'resent-' 504 headers SHOULD be added at the top of the message. Thus, if more 505 than one series of 'resent-' headers are present, the original 506 series is the last; the most recent is the first. 508 Forward counter 510 The 'Resent-Count:' header MAY be used to track the number of times 511 the message has been resent. Note that loop control is often done 512 by counting 'Received' headers, which are more general than 513 'resent-' headers. 515 Previously-sent Information 517 A 'Resent-From:' header MAY be added to indicate the address of the 518 user who directed the message to be resent. 520 A 'Resent-Date:' header SHOULD be added to indicate the time and 521 date that the message was resent. 523 Any 'x-mms-previously-sent-by:' and 'x-mms-previously-sent-date' 524 headers, if present, SHOULD be removed. The information contained 525 in them SHOULD be translated into 'from:', 'resent-to:', 526 'resent-from:', 'resent-date:', and 'resent-count:' headers. The 527 original sender of the message SHOULD appear in the 'from:' header; 528 the original recipient(s) SHOULD appear in the 'to:' header; the 529 time and date the message was originally sent SHOULD appear in the 530 'date:' header. The most recent sender SHOULD appear in the 531 top-most 'resent-from:' header; the most recent recipient(s) SHOULD 532 appear in the top-most 'resent-to:' header; the time and date the 533 message was most recently sent MUST appear in the top-most 534 'resent-date:' header. 536 Gellens [Page 12] Expires December 2003 537 'Received:' Headers 539 Each system that processes a message SHOULD add a 'Received:' header 540 as per [SMTP]. A message MAY be rejected if the number of 541 'Received:' headers exceeds a locally-defined maximum, which MUST 542 conform to [SMTP] section 6.2. 544 Content 546 The message content appears in the message body. Note that Internet 547 message format requires that line-endings be encoded as CR LF, thus 548 charset encodings that do not have this property cannot be used in 549 text/* body parts. (They MAY be used in other body parts, but only 550 when they are suitable encoded or when binary transmission has been 551 negotiated.) In particular, MMS allows UTF-16, while Internet 552 message format does not. UTF-16 encoding MUST be transcoded to 553 UTF-8 or another charset and encoding which is suitable for use in 554 Internet message format/protocols. 556 2.1.3.2 Conversion of messages from Internet to MMS format 558 3GPP MMS Version 560 An 'x-mms-mms-version:' header SHOULD be added. 562 Message Type (of PDU) 564 An 'x-mms-message-type:' header SHOULD be used in accordance with 565 the specific MMS interface (e.g., MM1, MM4). 567 Transaction ID 569 An 'x-mms-transaction-id:' header SHOULD be used in accordance with 570 the specific MMS interface (e.g., MM1, MM4). 572 Message ID 574 The 'Message-ID:' header MUST be retained. If not present it MUST 575 be created, with a unique value. If the 'Message-ID:' header does 576 not exist, but the SMTP envelop contains an ENVID value (as 577 specified in [DSN]), it MAY be used as the message ID. 579 Gellens [Page 13] Expires December 2003 580 Recipient(s) address 582 'To:' and 'Cc:' headers MUST be retained. 584 Each recipient contained in the SMTP envelope (RCPT TO values) MUST 585 be considered a recipient of the message. Recipients who appear in 586 address headers but not the SMTP envelope MUST be ignored. 587 Recipients are processed in accordance with the MMS interface (e.g., 588 MM1, MM4). 590 Sender address 592 The 'From:' header MUST be retained. 594 If address hiding has been requested, the 'From:' header MAY contain 595 a comment to this effect, for example, 'From: (anonymous sender)'. 597 Content type 599 The 'Content-Type:' header SHOULD be preserved. 601 Message class 603 An X-Mms-Message-Class: personal' header SHOULD be created for all 604 received messages with a non-null return path (MAIL FROM value in 605 the SMTP envelope). An X-Mms-Message-Class: auto' header MAY be 606 created for messages with a null return path. 608 Time of Expiry 610 An 'x-mms - expiry:' header SHOULD be created if the message 611 contains a relative time to expiration in the DELIVER-BY extension, 612 as specified in [Deliver-By]. 614 Earliest delivery time 616 An 'x-mms-delivery-time:' header SHOULD NOT be created. If a 617 message arrives via ESMTP relay containing an earliest time of 618 delivery in the AFTER extension, it SHOULD be rejected. If a 619 message is submitted via Message Submission [Submission] containing 620 an earliest time of delivery in the AFTER extension, it MUST either 621 be retained until the delivery time arrives, or rejected. It MUST 622 NOT be delivered or further relayed prior to the delivery time. 624 Gellens [Page 14] Expires December 2003 625 Delivery report request 627 An 'x-mms-delivery-report:' header SHOULD be created for messages 628 which request 'success' or 'none' delivery status notification by 629 use of the DSN extension as specified in [DSN]. Requests for 630 'delay' notifications or non-default actions, such as that only the 631 message headers should be returned, cannot be mapped onto MMS 632 headers and thus SHOULD be ignored. 634 Priority 636 An 'x-priority:' or 'importance:' header, if present, SHOULD be 637 replaced with an 'x-mms-priority:' header. Suggested mappings: 639 'X-Priority: 1 (highest)' 'X-Mms-Priority: High' 640 'X-Priority: 2 (high)' 'X-Mms-Priority: High' 641 'X-Priority: 3 (normal)' [omitted] 642 'X-Priority: 4 (low)' 'X-Mms-Priority: Low 643 'X-Priority: 5 (lowest)' 'X-Mms-Priority: Low 645 Normal priority messages SHOULD omit the 'X-Mms-Priority:' header. 647 Sender visibility 649 Requests for sender address hiding may be received in the SMTP 650 envelope by the X-ANONYMOUS extension. Servers which support 651 address hiding MAY advertise this by including X-ANONYMOUS in their 652 EHLO response. A message received which includes X-ANONYMOUS in the 653 MAIL FROM command has requested address hiding. 655 Note that even if servers claim to support address hiding, there is 656 no technical guarantee that it will be properly honored; servers 657 SHOULD NOT trust other servers to support this without a basis which 658 is beyond the scope of this specification (such as business 659 relationships). 661 Requests for sender address hiding MAY be reflected in the created 662 MM by adding an 'x-mms-sender-visibility:' header. 664 Read reply request 666 A request for a read reply contained in a 667 'Disposition-Notification-To:' header as specified in [MDN] SHOULD 668 be replaced with an 'x-mms-read-reply:' header. 670 Gellens [Page 15] Expires December 2003 671 Subject 673 The 'Subject:' header MUST be preserved. 675 Resending/Forwarding 677 One or more sets of 'resent-' headers, if present, SHOULD be mapped 678 to 'to:', 'from:', 'date:', and 'x-mms-previously-sent-' headers. 680 'Received:' Headers 682 Each system that processes a message SHOULD add a 'Received:' header 683 as per [SMTP]. A message MAY be rejected if the number of 684 'Received:' headers exceeds a locally-defined maximum, which MUST be 685 no less than 100. 687 Content 689 The message content appears in the message body. 691 2.1.4 Report Conversion 693 Standard Internet Message systems use the multipart/report MIME type 694 for delivery and disposition (read) reports. Delivery reports are 695 specified in [DSN]. Message disposition reports, which include read 696 reports, are specified in [MDN]. 698 When creating delivery or disposition reports from MMS reports, the 699 MMS report MAY be parsed to determine the reported event and time, 700 status, and the headers of the referenced (original) message. These 701 elements, once determined, are used to populate the subparts of the 702 delivery or disposition report. The first subpart is of type 703 text/plain, and contains a human-readable explanation of the event. 704 This text MAY include a statement that the report was synthesized 705 based on an MMS report. The second subpart is of type 706 report/delivery-status (for delivery reports) or 707 report/disposition-notification (for disposition reports). This 708 second part contains a structured itemization of the event. The 709 third subpart is of type message/rfc822 and includes the headers and 710 optionally the body of the referenced (original) message. 712 Gellens [Page 16] Expires December 2003 713 2.1.5 Message Delivery 715 Within Internet mail, when ESMTP is used and delivery reports are 716 requested, delivery is considered to be acceptance of a message by 717 the final server, that is, the server closest to the recipient. 718 When an MMS Relay/Server receives a message using ESMTP and a 719 delivery report is requested, the MMS Relay/Server MAY consider the 720 message delivered when it has been sent to the MMS User Agent. 722 3 Security Considerations 724 Data contained within messages SHOULD NOT be automatically trusted. 725 Even within a carrier's network, and certainly within the Internet, 726 various deliberate and accidental attacks or corruptions are 727 possible. For example, routers may contain vulnerabilities which 728 may be exploited, IP traffic be intercepted and/or modified, etc. 729 Systems such as MMS and Internet Mail are thus potentially 730 vulnerable to a wide range of attacks, including misidentification 731 of message sources, unauthorized disclosure of message contents, 732 unauthorized disclosure of message sender or recipient, alteration 733 of message recipient or content, etc. 735 Since MMS does not include a clear separation between in-transit 736 envelope and message content, there are increased risks of 737 unauthorized disclosure of routing information, and additional 738 challenges in protecting data. Some MMS features contain inherently 739 more risk than others. For example, reply charging and sender 740 address hiding. The reply charging mechanism requires a high degree 741 of trust between entities with little technical basis. Deliberate 742 or accidental abuse of this trust can result in unexpected or 743 unauthorized charges. For example, a sender may be charged for 744 unauthorized replies, or a sender may be charged for a reply which 745 the author thought would be paid for the recipient. A sender's 746 identity may be disclosed in violation of a request for this to be 747 blocked. The identity of recipients may be disclosed to other 748 recipients (or even non-recipients) for a message in which the 749 sender intended for the recipients not to be disclosed. 751 Mechanisms can be developed to protect against various threats, 752 however, these are not included in this version of this 753 specification. It is recommended that features such as reply 754 charging and sender identity hiding not be used across carrier 755 domains, and be used within carrier domains only with full 756 understanding of the risks involved. 758 Gellens [Page 17] Expires December 2003 759 4 Normative References 761 OMA: 763 OMA specifications are available at the OMA web site 764 . 766 [OMA-MMS] OMA-WAP-MMS-ENC-v1_1-20020823 768 3GPP2 and 3GPP: 770 3GPP2 specifications are available at the 3GPP2 (Third 771 Generation Partnership Project 2) web site 772 . 774 3GPP specifications are available at the 3GPP (Third Generation 775 Partnership Project) web site 777 [Stage_3] "MMS MM1 Stage 3 using OMA/WAP", TIA-934-310, X.S0016-310 779 "MMS MM4 Stage 3 Inter-Carrier Interworking", TIA-934-340, 780 X.S0016-340 782 �Multimedia Messaging Service: Functional description; 783 Stage2�,TS23.140 Release 5. 785 IETF: 787 [Future-Deliv] "SMTP Submission Service Extension for Future 788 Delivery ", G. White, G. Vaudreuil, Work in progress, 789 draft-vaudreuil-futuredelivery-xx.txt 791 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 792 Requirement Levels", RFC 2119, Harvard University, March 1997. 794 [Msg-Encap] "Proposed Standard for Message Encapsulation", Rose, 795 Stefferud, RFC 934, January 1985. 797 [DSN] "SMTP Service Extension for Delivery Status Notifications", 798 Moore, RFC 1891, January 1996; 800 Gellens [Page 18] Expires December 2003 801 "An Extensible Message Format for Delivery Status 802 Notifications", Moore, Vaudreuil, RFC 1894, January 1996. 804 [MDN] "An Extensible Message Format for Message Disposition 805 Notifications", Fajman, RFC 22298, March 1998. 807 [Submission] "Message Submission", Gellens, Klensin, RFC 2476, 808 December 1998. 810 [SMTP] "Simple Mail Transfer Protocol", Klensin, RFC 2821, April 811 2001. 813 [Msg-Fmt] "Internet Message Format", Resnick, RFC 2822, April 2001. 815 [Deliver-By] "Deliver By SMTP Service Extension", Newman, RFC 2852, 816 June 2000. 818 [Hdr-Enc] "MIME (Multipurpose Internet Mail Extensions) Part Three: 819 Message Header Extensions for Non-ASCII Text", Moore, RFC 2047, 820 November 1996. 822 5 Informative References 824 OMA: 826 OMA specifications are available at the OMA web site 827 . 829 (no OMA informative references) 831 3GPP2 and 3GPP: 833 3GPP2 specifications are available at the 3GPP2 (Third 834 Generation Partnership Project 2) web site 835 . 837 3GPP specifications are available at the 3GPP (Third Generation 838 Partnership Project) web site 840 [Overview] "Multimedia Messaging Services (MMS) Overview", 841 PN-3-0085-000, 843 Gellens [Page 19] Expires December 2003 845 [Stage_1] "Multimedia Messaging Services (MMS); Stage 1", 846 Requirements, October 2002, S.R0064-0. 848 [Stage_2] �Multimedia Messaging Service (MMS); Stage 2", Functional 849 Specification, April 2003, X.S0016-200/TIA-934-200. 851 [Formats] "MMS Media Formats and Codecs�, C.P0045, (work in 852 progress) 854 "Multimedia Messaging Service; Media formats and codecs", 855 TS26.140Release 5. 857 IETF: 859 [Encap] "Proposed standard for message encapsulation", M.T. Rose, 860 E.A. Stefferud, RFC 934, January 1985. 862 [Hdrs] "Common Internet Message Headers", J. Palme, RFC 2076, 863 February 1997. 865 6 Author's Address 867 Randall Gellens 868 QUALCOMM Incorporated 869 5775 Morehouse Drive 870 San Diego, CA 92121 871 USA 872 randy@qualcomm.com 874 Intellectual Property Statement 876 The IETF takes no position regarding the validity or scope of any 877 intellectual property or other rights that might be claimed to 878 pertain to the implementation or use of the technology described in 879 this document or the extent to which any license under such rights 880 might or might not be available; neither does it represent that it 881 has made any effort to identify any such rights. Information on the 882 IETF's procedures with respect to rights in standards-track and 883 standards-related documentation can be found in BCP-11. Copies of 884 claims of rights made available for publication and any assurances 885 of licenses to be made available, or the result of an attempt made 886 to obtain a general license or permission for the use of such 887 proprietary rights by implementors or users of this specification 888 can be obtained from the IETF Secretariat. 890 Gellens [Page 20] Expires December 2003 891 The IETF invites any interested party to bring to its attention any 892 copyrights, patents or patent applications, or other proprietary 893 rights which may cover technology that may be required to practice 894 this standard. Please address the information to the IETF Executive 895 Director. 897 Full Copyright Statement 899 Copyright (C) The Internet Society 2003. All Rights Reserved. 901 This document and translations of it may be copied and furnished to 902 others, and derivative works that comment on or otherwise explain it 903 or assist in its implementation may be prepared, copied, published 904 and distributed, in whole or in part, without restriction of any 905 kind, provided that the above copyright notice and this paragraph 906 are included on all such copies and derivative works. However, this 907 document itself may not be modified in any way, such as by removing 908 the copyright notice or references to the Internet Society or other 909 Internet organizations, except as needed for the purpose of 910 developing Internet standards in which case the procedures for 911 copyrights defined in the Internet Standards process must be 912 followed, or as required to translate it into languages other than 913 English. 915 The limited permissions granted above are perpetual and will not be 916 revoked by the Internet Society or its successors or assigns. 918 This document and the information contained herein is provided on an 919 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 920 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 921 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 922 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 923 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 925 Gellens [Page 21] Expires December 2003