[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Draft: Mapping Between MMS and Internet Mail         R. Gellens
Document: draft-gellens-lemonade-mms-mapping-00.txt             Qualcomm
Expires: December 2003                                         June 2003


Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail


Status of this Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as
    Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet- Drafts as
    reference material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    <http://www.ietf.org/ietf/1id-abstracts.txt>

    The list of Internet-Draft Shadow Directories can be accessed at
    <http://www.ietf.org/shadow.html>.

Copyright Notice

    Copyright (C) The Internet Society (2003).  All Rights Reserved.


Abstract

    The cellular telephone industry has defined a service known as the
    Multimedia Messaging Service (MMS).  This service uses formats and
    protocols which are similar to, but differ in key ways from those
    used in Internet mail.

    This document specifies how to exchange messages between these two
    services, including mapping information elements as used in MMS
    X-MMS-* headers to and from that used in ESMTP and Internet message
    headers.







Gellens                  [Page 1]                  Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


Table of Contents

    1  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
      1.1  Scope   . . . . . . . . . . . . . . . . . . . . . . . . .   2
      1.2  Conventions Used in this Document  . . . . . . . . . . . .  3
      1.3  Assumptions . . . . . . . . . . . . . . . . . . . . . . .   3
    2  Mapping Between MMS and Internet Mail  . . . . . . . . . . . .  3
      2.1  Mapping Specification . . . . . . . . . . . . . . . . . .   3
        2.1.1  Sending MMs  . . . . . . . . . . . . . . . . . . . . .  3
        2.1.2  Receiving messages  . . . . . . . . . . . . . . . . .   4
        2.1.3  MMS Information Element Mappings . . . . . . . . . . .  4
          2.1.3.1  Conversion of messages from MMS to Internet format  7
          2.1.3.2  Conversion of messages from Internet to MMS format 13
        2.1.4  Report Conversion . . . . . . . . . . . . . . . . . .  16
        2.1.5  Message Delivery . . . . . . . . . . . . . . . . . . . 16
    3  Security Considerations . . . . . . . . . . . . . . . . . . .  17
    4  Normative References . . . . . . . . . . . . . . . . . . . . . 17
    5  Informative References  . . . . . . . . . . . . . . . . . . .  19
    6  Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20
      Intellectual Property Statement  . . . . . . . . . . . . . . .  20
      Full Copyright Statement  . . . . . . . . . . . . . . . . . . . 21


1 Introduction

1.1 Scope

    This specification describes how to exchange messages with Internet
    mail systems.  This includes translation between MMS (as defined by
    3GPP/3GPP2/OMA) and Internet Mail messages using Extended Simple
    Mail Transfer Protocol [SMTP] and Internet mail format [Msg-Fmt].

    The MMS architecture [Stage_2] and specifications [Stage_3] refer to
    interfaces as reference points named MMx.  For example, MM1 is the
    client-server interface, MM4 is the server-server interface, and MM3
    is an interface to "external" or non-MMS systems.  The specification
    in this document be used on MMS reference point MM3 to exchange
    messages between MMS systems and any system which uses Internet
    Message formats and protocols.

    Note that MM3 can also be used for interworking with "external"
    (non-MMS) systems other than SMTP-based, such as Short Messaging
    Service (SMS) and access to external mail stores (such as a voice
    mail system).  This specification does not address these other uses
    or sub-interfaces of MM3; it is only concerned with Internet mail
    interworking and specifically exchange of messages.





Gellens                  [Page 2]                  Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


    All MM3 Stage 2 [Stage_2] functions are supported except for reply
    charging.  Sender address hiding may be used but is not recommended
    without security assurances which are beyond the scope of this
    specification (see Section 3).


1.2 Conventions Used in this Document

    The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
    NOT", and "MAY" in this document are to be interpreted as described
    in "Key words for use in RFCs to Indicate Requirement Levels"
    [KEYWORDS].


1.3 Assumptions

    It is assumed that the reader is already familiar with the contents
    of the 3GPP2 MMS Specification Overview [Overview], MMS Stage 1
    (requirements) [Stage_1] and Stage 2 (architecture and abstract
    messages) [Stage_2], and 3GPP/3GPP2 Stage 3 (protocols) [Stage_3]
    documents.  It is also assumed that the reader is familiar with
    Internet mail, especially RFC 2821 [SMTP] and RFC 2822 [Msg-Fmt].


2 Mapping Between MMS and Internet Mail

    This section defines the interworking between MMS Relay/Servers and
    External Servers using native ESMTP.  That is, information elements
    are exchanged using standard Internet Message [Msg-Fmt] header
    fields and standard [SMTP] elements.

    SMTP and Internet mail extensions are used for features such as
    delivery reports, message expiration, discovery of server support
    for optional features, etc.


2.1 Mapping Specification

2.1.1 Sending MMs

    When sending an MM to an external messaging system such an Internet
    mail system, the originator MMS Relay/Server SHOULD convert the MM
    if required.








Gellens                  [Page 3]                  Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


    The originator MMS Relay/Server SHOULD use the information elements
    associated with the MM to define the control information (Internet
    Message header fields and ESMTP values) needed for the transfer
    protocol.  The originator MMS Relay/Server MAY also use the
    information elements associated with the MM to convey these within
    the converted message.

    Section 2.1.3 lists the mappings between X-MMS-* headers and
    Internet Message header fields and ESMTP values.

    Delivery and read report MMs SHOULD be converted to standard
    Internet Message report format (multipart/report) to the extent
    possible.


2.1.2 Receiving messages

    When receiving a message from an external messaging system the
    recipient MMS Relay/Server MAY convert incoming messages to the MM
    format used within the receiving system.

    The recipient MMS Relay/Server MAY convert control information
    received from the External Server into appropriate information
    elements of an MM.

    Section 2.1.3 lists the mappings between X-MMS-* headers and
    Internet Message header fields and ESMTP values.

    Standard Internet Message report format (multipart/report) messages
    MAY be converted to delivery or read report MMS, as appropriate.





















Gellens                  [Page 4]                  Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


2.1.3 MMS Information Element Mappings

    The mappings between MMS elements and ESMTP/Internet Message
    elements are detailed below.  The MMS Headers listed are from
    [OMA-MMS].

    _________________|_________________|________________|______________
    Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header
    _________________|_________________|________________|______________
    3GPP MMS Version |................ |x-mms-mms-      |x-mms-
                     |                 |   version:     |   version:
    _________________|_________________|________________|______________
    Message Type     |N/A              |N/A             |x-mms-message-
    (of PDU)         |                 |                |   type:
    _________________|_________________|________________|______________
    Transaction ID   |N/A              |N/A             |x-mms-transact
                     |                 |                |   ion-id:
    _________________|_________________|________________|______________
    Message ID       |ENVID [DSN]      |Message-ID:     |Message-id:
    _________________|_________________|________________|______________
    Recipient        |RCPT TO          |To:, Cc:, or    |To:, Cc:, Bcc:
    address(es)      |address(es)      |omitted (bcc)   |
    _________________|_________________|________________|______________
    Sender's address |MAIL FROM        |From: (MAY set  |From:
                     |address if       |to locally-gen- |
                     |user-originated; |erated value    |
                     |MUST set MAIL    |to hide sender  |
                     |FROM to null     |identity in     |
                     |("<>") for all   |anonymous mes-  |
                     |automatically-   |sages when      |
                     |generated MMs    |receiving sys-  |
                     |                 |tem does not    |
                     |                 |support anony-  |
                     |                 |mous messages)  |
    _________________|_________________|________________|______________
    Content type     |................ |Content-Type:   |Content-type:
    _________________|_________________|________________|______________
    Message class    |Class=auto:      |MAY set 'Prece  |x-mms-message-
                     |MUST set MAIL    |   dence: bulk' |   class:
                     |FROM to null     |on class=auto   |
                     |("<>").          |                |
    _________________|_________________|________________|______________
    Date and time    |................ |Date:           |Date:
    _________________|_________________|________________|______________
    Time of expiry   |DELIVER-BY       |............... |x-mms-expiry:
                     |[Deliver-By]     |                |
    _________________|_________________|________________|______________
    Earliest deliv-  |AFTER [Future-   |............... |x-mms-delivery
    ery time         |Deliv]           |                |   -time:


Gellens                  [Page 5]                  Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


    _________________|_________________|________________|______________
    Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header
    _________________|_________________|________________|______________
    Delivery report  |NOTIFY [DSN]     |............... |x-mms-delivery
    request          |SHOULD also      |                |   -report:
                     |specify recip-   |                |
                     |ient address as  |                |
                     |ORCPT; SHOULD    |                |
                     |also specify     |                |
                     |ENVID            |                |
    _________________|_________________|________________|______________
    Importance       |................ |X-Priority:     |x-mms-
                     |                 |(MAY use        |   priority:
                     |                 |'Importance'    |
                     |                 |instead).       |
    _________________|_________________|________________|______________
    Sender visib-    |X-ANONYMOUS (see |............... |x-mms-sender-
    ility            |text below)      |                |   visibility:
    _________________|_________________|________________|______________
    Read reply       |................ |Disposition-    |x-mms-read-
    request          |                 |   Notification |   reply:
                     |                 |   -To: [MDN]   |
    _________________|_________________|________________|______________
    Reply-charging   |(not currently   |(not currently  |x-mms-reply-
    permission       |supported)       |supported)      |   charging:
    _________________|_________________|________________|______________
    Reply-charging   |(not currently   |(not currently  |x-mms-reply-
    permission       |supported)       |supported)      |   charging-
    deadline         |                 |                |   deadline:
    _________________|_________________|________________|______________
    Reply-charging   |(not currently   |(not currently  |x-mms-reply-
    permission       |supported)       |supported)      |   charging-
    limitation       |                 |                |   size:
    _________________|_________________|________________|______________
    Reply-charging   |(not currently   |(not currently  |x-mms-reply-
    usage request    |supported)       |supported)      |   charging-
                     |                 |                |   id:
    _________________|_________________|________________|______________
    Reply-charging   |(not currently   |(not currently  |x-mms-reply-
    usage reference  |supported)       |supported)      |   charging:
    _________________|_________________|________________|______________
    Subject          |................ |Subject:        |Subject:
    _________________|_________________|________________|______________
    Forward counter  |................ |Resent-Count:   |(Not sup-
                     |                 |                |ported)
    _________________|_________________|________________|______________
    Previously-sent- |................ |Resent-From:    |x-mms-previous
    by               |                 |                |   ly-sent-by:
    _________________|_________________|________________|______________


Gellens                  [Page 6]                  Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


    _________________|_________________|________________|______________
    Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header
    _________________|_________________|________________|______________
    Previously-sent- |................ |Resent-Date:    |x-mms-
    date and-time    |                 |                |   previously-
                     |                 |                |   sent-date:
    _________________|_________________|________________|______________
    Hop/host trace   |................ |Received:       |(Not sup-
                     |                 |                |ported)
    _________________|_________________|________________|______________
    Content          |................ |<message body>  |<message body>


2.1.3.1 Conversion of messages from MMS to Internet format

    3GPP MMS Version

    The 'x-mms-mms-version:' header, if present, MAY be retained.

    Message Type (of PDU)

    The 'x-mms-message-type:' header, if present, SHOULD be removed.

    Transaction ID

    The 'x-mms-transaction-id:' header, if present, SHOULD be removed.

    Message ID

    The 'Message-ID:' header MUST be retained.  If not present it MUST
    be created, with a unique value.  The message ID SHOULD be
    transmitted in the SMTP envelope as the ENVID parameter, as
    specified in [DSN].

    Recipient(s) address

    The address of each recipient MUST be transmitted in the SMTP
    envelope as a RCPT TO value.  All disclosed recipients SHOULD also
    appear in a 'To:' or 'Cc:' header.  At least one 'To:' or 'Cc:'
    header MUST be present.  If all recipients are undisclosed, a 'To:'
    header MAY be created that contains a comment, for example 'To:
    (undisclosed recipients)'.  The 'To:' header SHOULD NOT appear more
    than once.  The 'Cc:' header SHOULD NOT appear more than once.








Gellens                  [Page 7]                  Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


    Each recipient address MUST obey the length restrictions per [SMTP]
    and [Msg-Fmt].

    Current Internet message format requires that only 7-bit US-ASCII
    characters be present.  Other characters (for example, non-7-bit
    characters in a phrase part of an address header) must be encoded
    according to [Hdr-Enc].  Note that it would be possible to define an
    SMTP extension to permit transmission of unencoded 8-bit characters,
    but in the absence of such an extension [Hdr-Enc] must be used.

    Sender address

    The address of the message sender SHOULD appear in the 'From:'
    header, unless address hiding has been requested.  If address hiding
    has been requested, the 'From:' header MAY contain a comment to this
    effect, for example, 'From: (anonymous sender)'.

    The address of the message sender for all user-generated messages
    ('X-Mms-Message-Class: personal') SHOULD be transmitted in the SMTP
    envelope as the MAIL FROM value unless address hiding has been
    requested and the receiving server is not known to support address
    hiding.

    The 'From:' header and the MAIL FROM value MAY set to a
    locally-generated value to hide the sender identity in anonymous
    messages when the receiving system does not support anonymous
    messages.  Locally generated addressed MAY be internally mapped to
    the actual address to allow replies to anonymous messages, but such
    mapping is beyond the scope of this specification.

    Because of the risk of mail loops, it is critical that the MAIL FROM
    be set to null ("<>") for all automatically-generated MMs
    ('X-Mms-Message-Class: auto').  The MAIL FROM value MUST be set to
    null for all automatically -generated messages.

    Current Internet message format requires that only 7-bit US-ASCII
    characters be present.  Other characters (for example, non-7-bit
    characters in a phrase part of an address header) must be encoded
    according to [Hdr-Enc].  Note that it would be possible to define an
    SMTP extension to permit transmission of unencoded 8-bit characters,
    but in the absence of such an extension [Hdr-Enc] must be used.










Gellens                  [Page 8]                  Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


    The sender address MUST obey the length restrictions of [SMTP] and
    [Msg-Fmt].

    Content type

    The 'Content-Type:' header SHOULD be preserved.  Content types not
    in widespread use in the Internet MAY be converted into those that
    are, when such conversion can be done without loss of content.  For
    example, SMIL messages MAY be converted into widely-supported
    multipart/related with multipart/html.

    Message class

    The 'x-mms-message-class:' header SHOULD be removed.  A 'Precedence:
    bulk' header MAY be inserted for class=auto.  See 'Sender Address'
    above.

    Time of Expiry

    The 'x-mms - expiry:' header, if present, SHOULD be removed.

    The remaining time until the message is considered expired SHOULD be
    transmitted in the SMTP envelope by using the DELIVER-BY extension,
    as specified in [Deliver-By].

    Note that the ESMTP DELIVER-BY extension carries remaining time
    until expiration; each server decrements the value by the amount of
    time it has possessed the message.  The 'x-mms-expiry:' header may
    contain either the absolute time at which the message is considered
    expired or the relative time until the message SHOULD be expired.

    Earliest delivery time

    The 'x-mms-delivery-time:' header , if present, SHOULD be removed.

    Messages SHOULD be retained at the original server until the
    earliest delivery time has been reached.  On message submission, the
    client MAY indicate the remaining time until relay or delivery is
    permitted by using the AFTER extension as proposed in
    draft-vaudreuil-futuredelivery-xx.txt.

    Note that the ESMTP AFTER extension carries the amount of time that
    the original server is required to retain the message before it may
    be relayed or delivered.  The 'x-mms-delivery-time:' header may
    contain either the absolute or relative time.






Gellens                  [Page 9]                  Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


    Delivery report request

    Requests for delivery status notification (DSN) SHOULD be
    transmitted in the SMTP envelope by using the DSN extension as
    specified in [DSN] to request "success" or "none" notification
    (depending on the value of the 'x-mms'delivery-report' header).
    When the NOTIFY extension is used, the unaltered recipient address
    SHOULD be transmitted as the ORCPT value, and the original message
    ID SHOULD be transmitted as the ENVID value.

    The 'x-mms-delivery-report:' header, if present, SHOULD be removed.

    Importance

    Message importance (also known as priority) SHOULD be transmitted
    using an 'X-Priority:' header.

    Although not standardized, many email applications support the
    'X-Priority:' header, and use an 'X-Priority' value of 3 for
    messages with "normal" priority.  More important messages have lower
    values and less important message have higher values.  In most
    cases, urgent messages have an X-Priority value of 1.

    Suggested mappings for 'x-priority:' follow:

        'X-Mms-Priority: High'      'X-Priority: 2 (high)'
        'X-Mms-Priority: Normal     [omit]
        'X-Mms-Priority: Low        'X-Priority: 4 (low)'

    Normal priority messages SHOULD omit the 'X-Priority:' header.

    Message importance MAY instead be transmitted using an 'Importance:'
    header with one of the values 'high', 'normal', or 'low'.

    The 'x-mms-priority:' header, if present, SHOULD be removed.

    Sender visibility

    Requests for sender address hiding MAY be transmitted in the SMTP
    envelope by using the X-ANONYMOUS extension.  The request is made by
    adding "X-ANONYMOUS" to the MAIL FROM command.  Servers which
    support address hiding MAY advertise this by including X-ANONYMOUS
    in their EHLO response.








Gellens                 [Page 10]                 Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 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 'x-mms-sender-visibility:' header, if present, SHOULD be
    removed.

    Read reply request

    A request for a read reply SHOULD be transmitted using a
    'Disposition-Notification-To:' header as specified in [MDN].

    The 'x-mms-read-reply:' header, if present, SHOULD be removed.

    Reply-charging

    Reply charging permission and acceptance are complex issues
    requiring both user agent and server support.  Misapplied reply
    charging may cause incorrect billing.  Until the security issues
    have been properly addressed, reply charging SHOULD NOT be honored
    when using this interface.

    The 'x-mms-reply-charging:', 'x-mms-reply-charging-deadline:',
    'x-mms-reply-charging-size:', and 'x-mms-reply-charging-id:' headers
    MAY be removed.  Messages containing a reply-charging usage request
    ('x-mms-reply-charging-id:' and 'x-mms-reply-charging: accepted' or
    'x-mms-reply-charging: accepted (text only)' headers) SHOULD be
    rejected.

    Subject

    The 'Subject:' header MUST be preserved.  Current Internet message
    format requires that only 7-bit US-ASCII characters be present.
    Other characters must be encoded according to [Hdr-Enc].  Note that
    it would be possible to define an SMTP extension to permit
    transmission of unencoded 8-bit characters, but in the absence of
    such an extension [Hdr-Enc] must be used.

    Resending/Forwarding










Gellens                 [Page 11]                 Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


    In Internet mail, there are two primary ways of sending a previously
    received message to a new recipient: forwarding and resending.
    Forwarding is when a user creates a new message containing the
    original message, either simply embedded within the text, or
    delineated.  Embedded messages generally have each original line
    preceded by a quote symbol ('>'), surround the original text with a
    preceding and trailing line which starts with hyphens as per
    [Encap], such as '--- begin forwarded text' and '--- end forwarded
    text', or encapsulate the original message as a 'message/rfc822'
    content type, perhaps within a 'multipart/mixed' message. (This last
    method offers more robust delineation.) Resending is when the
    original message is unaltered except for the possible addition of
    'resent-' headers to explain the resending to the new recipient.

    A message may be resent more than once; each time new 'resent-'
    headers SHOULD be added at the top of the message.  Thus, if more
    than one series of 'resent-' headers are present, the original
    series is the last; the most recent is the first.

    Forward counter

    The 'Resent-Count:' header MAY be used to track the number of times
    the message has been resent.  Note that loop control is often done
    by counting 'Received' headers, which are more general than
    'resent-' headers.

    Previously-sent Information

    A 'Resent-From:' header MAY be added to indicate the address of the
    user who directed the message to be resent.

    A 'Resent-Date:' header SHOULD be added to indicate the time and
    date that the message was resent.

    Any 'x-mms-previously-sent-by:' and 'x-mms-previously-sent-date'
    headers, if present, SHOULD be removed.  The information contained
    in them SHOULD be translated into 'from:', 'resent-to:',
    'resent-from:', 'resent-date:', and 'resent-count:' headers.  The
    original sender of the message SHOULD appear in the 'from:' header;
    the original recipient(s) SHOULD appear in the 'to:' header; the
    time and date the message was originally sent SHOULD appear in the
    'date:' header.  The most recent sender SHOULD appear in the
    top-most 'resent-from:' header; the most recent recipient(s) SHOULD
    appear in the top-most 'resent-to:' header; the time and date the
    message was most recently sent MUST appear in the top-most
    'resent-date:' header.





Gellens                 [Page 12]                 Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


    'Received:' Headers

    Each system that processes a message SHOULD add a 'Received:' header
    as per [SMTP].  A message MAY be rejected if the number of
    'Received:' headers exceeds a locally-defined maximum, which MUST
    conform to [SMTP] section 6.2.

    Content

    The message content appears in the message body.  Note that Internet
    message format requires that line-endings be encoded as CR LF, thus
    charset encodings that do not have this property cannot be used in
    text/* body parts. (They MAY be used in other body parts, but only
    when they are suitable encoded or when binary transmission has been
    negotiated.) In particular, MMS allows UTF-16, while Internet
    message format does not.  UTF-16 encoding MUST be transcoded to
    UTF-8 or another charset and encoding which is suitable for use in
    Internet message format/protocols.


2.1.3.2 Conversion of messages from Internet to MMS format

    3GPP MMS Version

    An 'x-mms-mms-version:' header SHOULD be added.

    Message Type (of PDU)

    An 'x-mms-message-type:' header SHOULD be used in accordance with
    the specific MMS interface (e.g., MM1, MM4).

    Transaction ID

    An 'x-mms-transaction-id:' header SHOULD be used in accordance with
    the specific MMS interface (e.g., MM1, MM4).

    Message ID

    The 'Message-ID:' header MUST be retained.  If not present it MUST
    be created, with a unique value.  If the 'Message-ID:' header does
    not exist, but the SMTP envelop contains an ENVID value (as
    specified in [DSN]), it MAY be used as the message ID.









Gellens                 [Page 13]                 Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


    Recipient(s) address

    'To:' and 'Cc:' headers MUST be retained.

    Each recipient contained in the SMTP envelope (RCPT TO values) MUST
    be considered a recipient of the message.  Recipients who appear in
    address headers but not the SMTP envelope MUST be ignored.
    Recipients are processed in accordance with the MMS interface (e.g.,
    MM1, MM4).

    Sender address

    The 'From:' header MUST be retained.

    If address hiding has been requested, the 'From:' header MAY contain
    a comment to this effect, for example, 'From: (anonymous sender)'.

    Content type

    The 'Content-Type:' header SHOULD be preserved.

    Message class

    An X-Mms-Message-Class: personal' header SHOULD be created for all
    received messages with a non-null return path (MAIL FROM value in
    the SMTP envelope).  An X-Mms-Message-Class: auto' header MAY be
    created for messages with a null return path.

    Time of Expiry

    An 'x-mms - expiry:' header SHOULD be created if the message
    contains a relative time to expiration in the DELIVER-BY extension,
    as specified in [Deliver-By].

    Earliest delivery time

    An 'x-mms-delivery-time:' header SHOULD NOT be created.  If a
    message arrives via ESMTP relay containing an earliest time of
    delivery in the AFTER extension, it SHOULD be rejected.  If a
    message is submitted via Message Submission [Submission] containing
    an earliest time of delivery in the AFTER extension, it MUST either
    be retained until the delivery time arrives, or rejected.  It MUST
    NOT be delivered or further relayed prior to the delivery time.








Gellens                 [Page 14]                 Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


    Delivery report request

    An 'x-mms-delivery-report:' header SHOULD be created for messages
    which request 'success' or 'none' delivery status notification by
    use of the DSN extension as specified in [DSN].  Requests for
    'delay' notifications or non-default actions, such as that only the
    message headers should be returned, cannot be mapped onto MMS
    headers and thus SHOULD be ignored.

    Priority

    An 'x-priority:' or 'importance:' header, if present, SHOULD be
    replaced with an 'x-mms-priority:' header.  Suggested mappings:

        'X-Priority: 1 (highest)'       'X-Mms-Priority: High'
        'X-Priority: 2 (high)'          'X-Mms-Priority: High'
        'X-Priority: 3 (normal)'              [omitted]
        'X-Priority: 4 (low)'           'X-Mms-Priority: Low
        'X-Priority: 5 (lowest)'        'X-Mms-Priority: Low

    Normal priority messages SHOULD omit the 'X-Mms-Priority:' header.

    Sender visibility

    Requests for sender address hiding may be received in the SMTP
    envelope by the X-ANONYMOUS extension.  Servers which support
    address hiding MAY advertise this by including X-ANONYMOUS in their
    EHLO response.  A message received which includes X-ANONYMOUS in the
    MAIL FROM command has requested address hiding.

    Note that even if servers claim to support address hiding, there is
    no technical guarantee that it will be properly honored; servers
    SHOULD NOT trust other servers to support this without a basis which
    is beyond the scope of this specification (such as business
    relationships).

    Requests for sender address hiding MAY be reflected in the created
    MM by adding an 'x-mms-sender-visibility:' header.

    Read reply request

    A request for a read reply contained in a
    'Disposition-Notification-To:' header as specified in [MDN] SHOULD
    be replaced with an 'x-mms-read-reply:' header.







Gellens                 [Page 15]                 Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


    Subject

    The 'Subject:' header MUST be preserved.

    Resending/Forwarding

    One or more sets of 'resent-' headers, if present, SHOULD be mapped
    to 'to:', 'from:', 'date:', and 'x-mms-previously-sent-' headers.

    'Received:' Headers

    Each system that processes a message SHOULD add a 'Received:' header
    as per [SMTP].  A message MAY be rejected if the number of
    'Received:' headers exceeds a locally-defined maximum, which MUST be
    no less than 100.

    Content

    The message content appears in the message body.

2.1.4 Report Conversion

    Standard Internet Message systems use the multipart/report MIME type
    for delivery and disposition (read) reports.  Delivery reports are
    specified in [DSN].  Message disposition reports, which include read
    reports, are specified in [MDN].

    When creating delivery or disposition reports from MMS reports, the
    MMS report MAY be parsed to determine the reported event and time,
    status, and the headers of the referenced (original) message.  These
    elements, once determined, are used to populate the subparts of the
    delivery or disposition report.  The first subpart is of type
    text/plain, and contains a human-readable explanation of the event.
    This text MAY include a statement that the report was synthesized
    based on an MMS report.  The second subpart is of type
    report/delivery-status (for delivery reports) or
    report/disposition-notification (for disposition reports).  This
    second part contains a structured itemization of the event.  The
    third subpart is of type message/rfc822 and includes the headers and
    optionally the body of the referenced (original) message.











Gellens                 [Page 16]                 Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


2.1.5 Message Delivery

    Within Internet mail, when ESMTP is used and delivery reports are
    requested, delivery is considered to be acceptance of a message by
    the final server, that is, the server closest to the recipient.
    When an MMS Relay/Server receives a message using ESMTP and a
    delivery report is requested, the MMS Relay/Server MAY consider the
    message delivered when it has been sent to the MMS User Agent.


3 Security Considerations

    Data contained within messages SHOULD NOT be automatically trusted.
    Even within a carrier's network, and certainly within the Internet,
    various deliberate and accidental attacks or corruptions are
    possible.  For example, routers may contain vulnerabilities which
    may be exploited, IP traffic be intercepted and/or modified, etc.
    Systems such as MMS and Internet Mail are thus potentially
    vulnerable to a wide range of attacks, including misidentification
    of message sources, unauthorized disclosure of message contents,
    unauthorized disclosure of message sender or recipient, alteration
    of message recipient or content, etc.

    Since MMS does not include a clear separation between in-transit
    envelope and message content, there are increased risks of
    unauthorized disclosure of routing information, and additional
    challenges in protecting data.  Some MMS features contain inherently
    more risk than others.  For example, reply charging and sender
    address hiding.  The reply charging mechanism requires a high degree
    of trust between entities with little technical basis.  Deliberate
    or accidental abuse of this trust can result in unexpected or
    unauthorized charges.  For example, a sender may be charged for
    unauthorized replies, or a sender may be charged for a reply which
    the author thought would be paid for the recipient.  A sender's
    identity may be disclosed in violation of a request for this to be
    blocked.  The identity of recipients may be disclosed to other
    recipients (or even non-recipients) for a message in which the
    sender intended for the recipients not to be disclosed.

    Mechanisms can be developed to protect against various threats,
    however, these are not included in this version of this
    specification.  It is recommended that features such as reply
    charging and sender identity hiding not be used across carrier
    domains, and be used within carrier domains only with full
    understanding of the risks involved.






Gellens                 [Page 17]                 Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


4 Normative References

    OMA:

        OMA specifications are available at the OMA web site
        <http://www.openmobilealliance.org>.

    [OMA-MMS] OMA-WAP-MMS-ENC-v1_1-20020823


    3GPP2 and 3GPP:

        3GPP2 specifications are available at the 3GPP2 (Third
        Generation Partnership Project 2) web site
        <http://www.3gpp2.org>.

        3GPP specifications are available at the 3GPP (Third Generation
        Partnership Project) web site <http://www.3gpp.org>

    [Stage_3] "MMS MM1 Stage 3 using OMA/WAP", TIA-934-310, X.S0016-310

              "MMS MM4 Stage 3 Inter-Carrier Interworking", TIA-934-340,
    X.S0016-340

              þMultimedia Messaging Service:  Functional description;
    Stage2™,TS23.140 Release 5.


    IETF:

    [Future-Deliv] "SMTP Submission Service Extension for Future
    Delivery ", G. White, G. Vaudreuil, Work in progress,
    draft-vaudreuil-futuredelivery-xx.txt

    [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
    Requirement Levels", RFC 2119, Harvard University, March 1997.

    [Msg-Encap] "Proposed Standard for Message Encapsulation", Rose,
    Stefferud, RFC 934, January 1985.

    [DSN] "SMTP Service Extension for Delivery Status Notifications",
    Moore, RFC 1891, January 1996;









Gellens                 [Page 18]                 Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


           "An Extensible Message Format for Delivery Status
    Notifications", Moore, Vaudreuil, RFC 1894, January 1996.

    [MDN] "An Extensible Message Format for Message Disposition
    Notifications", Fajman, RFC 22298, March 1998.

    [Submission] "Message Submission", Gellens, Klensin, RFC 2476,
    December 1998.

    [SMTP] "Simple Mail Transfer Protocol", Klensin, RFC 2821, April
    2001.

    [Msg-Fmt] "Internet Message Format", Resnick, RFC 2822, April 2001.

    [Deliver-By] "Deliver By SMTP Service Extension", Newman, RFC 2852,
    June 2000.

    [Hdr-Enc] "MIME (Multipurpose Internet Mail Extensions) Part Three:
    Message Header Extensions for Non-ASCII Text", Moore, RFC 2047,
    November 1996.


5 Informative References

    OMA:

        OMA specifications are available at the OMA web site
        <http://www.openmobilealliance.org>.

    (no OMA informative references)

    3GPP2 and 3GPP:

        3GPP2 specifications are available at the 3GPP2 (Third
        Generation Partnership Project 2) web site
        <http://www.3gpp2.org>.

        3GPP specifications are available at the 3GPP (Third Generation
        Partnership Project) web site <http://www.3gpp.org>

    [Overview] "Multimedia Messaging Services (MMS) Overview",
    PN-3-0085-000,









Gellens                 [Page 19]                 Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


    [Stage_1] "Multimedia Messaging Services (MMS); Stage 1",
    Requirements, October 2002, S.R0064-0.

    [Stage_2] þMultimedia Messaging Service (MMS); Stage 2", Functional
    Specification, April 2003, X.S0016-200/TIA-934-200.

    [Formats] "MMS Media Formats and Codecs™, C.P0045, (work in
    progress)

              "Multimedia Messaging Service; Media formats and codecs",
    TS26.140Release 5.


    IETF:

    [Encap] "Proposed standard for message encapsulation", M.T.  Rose,
    E.A.  Stefferud, RFC 934, January 1985.

    [Hdrs] "Common Internet Message Headers", J. Palme, RFC 2076,
    February 1997.


6 Author's Address

    Randall Gellens
    QUALCOMM Incorporated
    5775 Morehouse Drive
    San Diego, CA  92121
    USA
    randy@qualcomm.com


Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    intellectual property or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; neither does it represent that it
    has made any effort to identify any such rights.  Information on the
    IETF's procedures with respect to rights in standards-track and
    standards-related documentation can be found in BCP-11.  Copies of
    claims of rights made available for publication and any assurances
    of licenses to be made available, or the result of an attempt made
    to obtain a general license or permission for the use of such
    proprietary rights by implementors or users of this specification
    can be obtained from the IETF Secretariat.




Gellens                 [Page 20]                 Expires December 2003

Internet Draft      Mapping Between MMS and Internet Mail      June 2003


    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights which may cover technology that may be required to practice
    this standard.  Please address the information to the IETF Executive
    Director.


Full Copyright Statement

    Copyright (C) The Internet Society 2003.  All Rights Reserved.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
    or assist in its implementation may be prepared, copied, published
    and distributed, in whole or in part, without restriction of any
    kind, provided that the above copyright notice and this paragraph
    are included on all such copies and derivative works.  However, this
    document itself may not be modified in any way, such as by removing
    the copyright notice or references to the Internet Society or other
    Internet organizations, except as needed for the purpose of
    developing Internet standards in which case the procedures for
    copyrights defined in the Internet Standards process must be
    followed, or as required to translate it into languages other than
    English.

    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Society or its successors or assigns.

    This document and the information contained herein is provided on an
    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

















Gellens                 [Page 21]                 Expires December 2003


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/