Вы находитесь на странице: 1из 65

3GPP2 X.S0016-311 Version 1.0.

0 Version Date: April 14, 2003

MMS MM1 Stage 3 Using M-IMAP for Message Submission and Retrieval Revision: 0

COPYRIGHT
3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner's name based on this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at secretariat@3gpp2.org. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See www.3gpp2.org for more information.

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Revision History

Revision Rev. 0 Initial Publication

Date May 2003

ii

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

1
1 1.1 1.2 1.3 1.4 1.5 1.6 2 3

CONTENTS
Introduction ..........................................................................................................................................................1 Scope .............................................................................................................................................................1 References.....................................................................................................................................................1 Terminology .................................................................................................................................................4 Assumptions .................................................................................................................................................5 Definitions ....................................................................................................................................................5 Abbreviations ...............................................................................................................................................5

Stage 2 Amendments (Normative)........................................................................................................................6 MM1 Mobile-IMAP (M-IMAP) Stage 3 Description ..........................................................................................6 3.1 Introduction (Informative) .........................................................................................................................6 Figure 1 - Abstract Transaction Call Flows...........................................................................................................7 3.2 MM1 M-IMAP Stage 3 Specification (Normative)...................................................................................7 3.2.1 Submission of Multimedia Message......................................................................................................7 3.2.2 Multimedia Message Notification..........................................................................................................9 Figure 2 - Notification and Immediate Retrieval of Multimedia Message ..........................................................10 Figure 3 - Notification and Delayed Retrieval of Multimedia Message..............................................................10 3.2.3 Multimedia Message Retrieval ............................................................................................................11 Table 1 - IMAP related RFCs..............................................................................................................................13 3.2.4 Forwarding of Multimedia Message....................................................................................................13 Figure 4 - Forwarding without prior retrieval of Multimedia Message...............................................................14 3.2.5 Delivery Report (Informative) .............................................................................................................14 3.2.6 Read-Reply Report (Informative)........................................................................................................15 3.3 Terminal Capability Negotiation..............................................................................................................16 3.4 MMS Message contents (Normative) .......................................................................................................16 Figure 5 - Application/vnd.wap.mms-message Structure (from [MMS_OMA]) ................................................17 3.5 MMS Presentation (Informative).............................................................................................................18 3.6 MMS Security Model (Informative) ........................................................................................................18 Table 2 - Security related RFCs...........................................................................................................................19 3.7 Mapping of Abstract messages (Normative) ...........................................................................................19 Table 3 - Mapping of MM1 Submit abstract messages .......................................................................................19 Table 4 - Mapping of MM1 Notification abstract messages ...............................................................................19 Table 5 - Mapping MM1 Retrieve abstract messages .........................................................................................19 Table 6 - Mapping of MM1 Forward abstract messages .....................................................................................20 Table 7 - Mapping of MM1 Delivery Report abstract messages.........................................................................20 Table 8 - Mapping of MM1 Read-Reply Report abstract messages....................................................................20 3.8 Message format on MM1 (Normative) ....................................................................................................20 3.8.1 Message header fields..........................................................................................................................21 Table 9 - MM1_submit.REQ Information Elements to [RFC2822] Header Mappings .....................................21 Table 10 - MM1_submit.RES Information Elements to [RFC2822] Header Mappings .....................................22 Table 11 - MM1_notification.REQ Information Elements to Header Mappings ................................................23 Table 12 - MM1_notification.RES MM Status Information Element values to [RFC2822] Headers................23 Table 13 - MM1_retrieve.REQ MM Status Information Element values to M-IMAP DELV Parameters .........24 Table 14 - MM1_retrieve.RES Information Elements to [RFC2822] Header Mappings...................................24

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Table 15 - MM1_acknowledgement.REQ Information Element values to [RFC2822] Headers .......................25 Table 16 - Header mappings for MM1 Forwarding ............................................................................................25 Table 17 - Mapping of Information elements in the MM1_forward.RES. ..........................................................26 Table 18 - MM1_Delivery_report.REQ Information Elements to [RFC2822] Header Mappings.....................26 Table 19 - MM1_read_reply_ recipient.REQ Information Elements to [RFC2822] Header Mappings ............27 Table 20 - MM1_read_reply_originator.REQ Information Elements to [RFC2822] Header Mappings ...........27 Table 21 - MM1_read_reply_recipient.REQ Information Elements to [RFC2822] Header Mappings .............28 3.9 4 Sample Application (Informative)............................................................................................................31 Mobile-IMAP Reference Specification (Normative) .........................................................................................33 4.1 Features ......................................................................................................................................................33 4.1.1 Abbrievated commands and responses ................................................................................................33 4.1.2 Combined Commands .........................................................................................................................33 4.1.3 Message Submission............................................................................................................................34 4.1.4 Tags .....................................................................................................................................................34 4.1.5 Error messages.....................................................................................................................................34 4.1.6 Timeout................................................................................................................................................34 4.1.7 Log files...............................................................................................................................................35 4.1.8 Coexistence with standard IMAP4 Server...........................................................................................35 4.2 State Transition..........................................................................................................................................35 4.3 AUTH (Authentication) ............................................................................................................................36 4.3.1 Format..................................................................................................................................................36 4.3.2 Operation .............................................................................................................................................37 4.3.3 Error cases ...........................................................................................................................................38 4.3.4 Sample .................................................................................................................................................38 4.4 SACH (Search)...........................................................................................................................................38 4.4.1 Format..................................................................................................................................................38 4.4.2 Operation .............................................................................................................................................39 4.4.3 Error cases ...........................................................................................................................................39 4.5 FECH (Message Fetching) ........................................................................................................................40 4.5.1 Format..................................................................................................................................................40 4.5.2 Operation .............................................................................................................................................42 4.5.3 Error cases ...........................................................................................................................................42 4.5.4 Samples................................................................................................................................................43 4.6 STOR (Flag Setting) ..................................................................................................................................44 4.6.1 Format..................................................................................................................................................44 4.6.2 Operation .............................................................................................................................................44 4.6.3 Error cases ...........................................................................................................................................45 4.7 DELV (Delivery) ........................................................................................................................................45 4.7.1 Format..................................................................................................................................................45 4.7.2 Operation .............................................................................................................................................47 4.7.3 Error cases ...........................................................................................................................................48 4.7.4 Examples .............................................................................................................................................49 4.8 DELT (Delete) ............................................................................................................................................55 4.8.1 format...................................................................................................................................................55 4.8.2 Operation .............................................................................................................................................55 4.8.3 Error cases ...........................................................................................................................................56 4.9 LOUT (Log Out)........................................................................................................................................56 4.9.1 Format..................................................................................................................................................56 4.9.2 Operation .............................................................................................................................................56

ii

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

4.9.3
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Error cases ...........................................................................................................................................56 List of Command Replies...............................................................................................................57 Syntax Specifications......................................................................................................................59

Appendix A Appendix B

iii

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

FOREWORD
This Technical Specification has been produced by the 3rd Generation Partnership Project 2 (3GPP2).

iv

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Introduction

Mobile-IMAP, or M-IMAP, is an adaptation of IMAP4 R1 that provides for minimum overhead message access for mobile messaging. M-IMAP is intended as a part of the MMS system described in the MMS Overview document (MMS_OV). It fulfills the MMS Stage 2 functions (see [MMS_Stage2]) for Message Submission and Message Retrieval. It may also be used to fulfill "Delivery Report" and "Read Report" functions.

1.1

Scope

This specification defines a technical realization of the MMS MM1 interface for Message Submission and Message Retrieval. The methods defined within this document are independent of and may be used with any particular delivery notification method, as section 3.9 explains.

1.2
3GPP2

References

[S.R0064-0]

Multimedia Messaging Services (MMS) Stage 1 Requirements, October 2002, 3GPP2. http://www.3gpp2.org/Public_html/specs/S.R00640_v1.0.pdf X.S0016-000-A/TIA-934-000-A, Multimedia Messaging Services (MMS) Specification Overview, May 2003, 3GPP2.

[MMS_OV]

[MMS_Stage2] X.S0016-200/TIA-934-200, Multimedia Messaging Services (MMS) Stage 2 Functional Specifications, April 2003, 3GPP2. [MMS_OMA] X.S0016-310/TIA-934-310, Multimedia Messaging Services (MMS) Stage 3 Using OMA/WAP, April 2003, 3GPP2. C.S0015-A: Short Message Service (SMS), December 1999, 3GPP2. http://www.3gpp2.org/Public_html/specs/CS0015-0.pdf

[SMS]

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

IETF [RFC1731] RFC 1731, IMAP4 Authentication Mechanisms, December 1994, IETF. http://www.ietf.org/rfc/rfc1731 RFC 1893, Enhanced Mail system Status Codes, January 1992, IETF. http://www.ietf.org/rfc/rfc1893 RFC 1894, An Extensible Message Format for Delivery Status Notifications, January 1966, IETF. http://www.ietf.org/rfc/rfc1894 RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies; IETF. http://www.ietf.org/rfc/rfc2045 RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types; IETF. http://www.ietf.org/rfc/rfc2046 RFC 2047, Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text, IETF. http://www.ietf.org/rfc/rfc2047 RFC 2076, Common Internet Message Headers, Feb 1997, IETF. http://www.ietf.org/rfc/rfc2076 RFC 2088, IMAP4 non-synchronizing literals, January 1997, IETF. http://www.ietf.org/rfc/rfc2088 RFC 2192, IMAP URL Scheme, September 1997, IETF. http://www.ietf.org/rfc/rfc2192 RFC 2195, IMAP/POP AUTHorize Extension for Simple Challenge/Response, September 1997, IETF. http://www.ietf.org/rfc/rfc2195 RFC 2246, The TLS Protocol Version 1.0, IETF. http://www.faqs.org/rfcs/rfc2246 RFC 2289, An Extensible Message Format for Message Disposition Notifications, March 1998, IETF. http://www.ietf.org/rfc/rfc2298
2

[RFC1893]

[RFC1894]

[RFC2045]

[RFC2046]

[RFC2047]

[RFC2076]

[RFC2088]

[RFC2192]

[RFC2195]

[RFC2246]

[RFC2298]

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

[RFC2342]

RFC 2342, IMAP4 Namespace, May 1998, IETF. http://www.ietf.org/rfc/rfc2342 RFC 2359, IMAP4 UIDPLUS extension, June 1998, IETF. http://www.ietf.org/rfc/rfc2359 RFC 2387, The MIME Multipart/Related Content-type, IETF. http://www.ietf.org/rfc/rfc2387 RFC 2444, The One-Time-Password SASL Mechanism, October 1998, IETF. http://www.ietf.org/rfc/rfc2444 RFC 2595, Using TLS with IMAP, POP3 and ACAP, June 1999, IETF. http://www.ietf.org/rfc/rfc2595 RFC 2632, S/MIME Version 3 Certificate Handling, June 1999, IETF. http://www.ietf.org/rfc/rfc2632 RFC 2633, S/MIME Version 3 Message Specification, June 1999, IETF. http://www.ietf.org/rfc/rfc2633 RFC 2634, Enhanced Security Services for S/MIME, June 1999, IETF. http://www.ietf.org/rfc/rfc2634 RFC 2821, Simple Message Transport Protocol, April 2002, IETF. http://www.faqs.org/rfcs/rfc2821 RFC 2822, Internet Message Format, April 2002, IETF. http://www.faqs.org/rfcs/rfc2822 RFC 3156, MIME Security with OpenPGP, August 2001, IETF. http://www.ietf.org/rfc/rfc3156 RFC 3501, IMAP4, Internet Message Access Protocol Version 4 rev1, March 2003, IETF. http://www.ietf.org/rfc/rfc3501

[RFC2359]

[RFC2387]

[RFC2444]

[RFC2595]

[RFC2632]

[RFC2633]

[RFC2634]

[RFC2821]

[RFC2822]

[RFC3156]

[RFC3501] ITU [E.164]

ITU-T Recommendations Series E: E.164: The international public telecommunication numbering plan; May 1997; http://www.itu.int/rec/recommendation.asp?type=folders&la ng=e&parent=T-REC-E.164

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Open Mobile Alliance (OMA) (formerly WAP Forum) [WAP238] WAP-238-WML-20010911-a, Wireless Markup Language version 2 Specification, September 2001, WAP Forum. http://www1.wapforum.org/tech/documents/WAP-238WML-20010911-a.pdf WAP-250-PushArchOverview-20010703-a, Push Architectural Overview, OMA. http://www1.wapforum.org/tech/documents/WAP-250PushArchOverview-20010703-a.pdf

[WAP250]

World-Wide-Web Consortium (W3C) [SMIL] W3C Recommendation 07 August 2001: Synchronized Multimedia Integration Language (SMIL) 2.0 Specification, 2001, W3C. http://www.w3.org/TR/REC-smil

1.3

Terminology
a. shall and shall not identify items of interest that are to be strictly followed and from which no deviation is recommended, b. should and should not indicate items of interest that are highly desirable and particularly suitable, without identifying or excluding other items; or (in the negative form) indicate items of interest that are not desirable, are not particularly suitable, or are not recommended but not prohibited, and c. may and may not indicate items of interest that are optional but permissible within the limits of this recommendation.

This document uses the following verbal forms and verbal form definitions:

In the various M-IMAP examples, client transactions are indicated with a prefix of C:, and server-responses are prefixed with a S:. In the example text, <CR><LF> sequences, representing carriage-return and linefeed characters, respectively, are indicated with the symbol .

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

1.4

Assumptions

This document describes a Stage 3 technical realization for 3GPP2 MMS MM1. It is assumed that the reader is already familiar with the contents of the 3GPP2 MMS Specification Overview [MMS_OV], MMS Stage 1 [S. R0064], and Stage 2 [MMS_Stage2] documents. Further, it is also assumed that the reader is familiar with the WAP Push architecture [WAP250], or with the [SMS] protocols, on which most mobile notification mechanisms are based.

1.5
None

Definitions

1.6

Abbreviations

The following abbreviations are used within this document: C DSN HTTP IETF IMAP4 MDN M-IMAP MIME MM MMS MSG OMA POP3 RFC S SIP SMS SMTP TCP TLS UA UAProf UID Client (used in sample sessions) Delivery Status Notification [RFC1894] Hypertext Transfer Protocol Internet Engineering Task Force Internet Message Access Protocol, version 4 Mobile Directory Number or Message Disposition Notification [RFC2298], depending upon context Mobile IMAP Multipurpose Internet Mail Extensions Multimedia Message Multimedia Messaging Service Message Open Mobile Alliance Post Office Protocol Version 3 Request for Comments Server (used in sample sessions) Session Initiation Protocol Short Message Service Simple Mail Transfer Protocol Transmission Communications Protocol Transport Layer Security User Agent User Agent Profile User Identification (ID) (see [RFC3501])
5

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP

URI URL W3C WAP WML

Uniform Resource Identifier Uniform Resource Locator WWW Consortium Wireless Application Protocol Wireless Markup Language

2
None.

Stage 2 Amendments (Normative)

MM1 Mobile-IMAP (M-IMAP) Stage 3 Description


Introduction (Informative)

3.1

The MMS service is realized by the invocation of reference point MM1 transactions between the MMS User Agent and the MMS Relay/Server. There are three basic messaging services being provided by MM1: notification, retrieval, and submission. Notification is out of scope for this document and not specified. The M-IMAP message retrieval and submission mechanisms may be used in combination with any notification method defined in TIA934/X.S0016 or based on [SMS]. It is compatible with and supports the Stage 3 OMA-WAP-based message notification protocol of [MMS_OMA]. M-IMAP, based on IMAP4r1 (Internet Message Access Protocol Version 4 Rev 1) [RFC3501] is the basis for the message transactions. IMAP4 is an existing Internet messaging protocol and has been widely deployed in a number of distinct environments. The mobile networking environment in general, and MMS functional specifications in particular, create unique requirements on the specification of M-IMAP, which is an adaptation of IMAP4. These extensions are detailed in the appropriate sections below. Figure 1 below depicts the abstract transactions that have been defined for MMS Stage 2. The Submit, Retrieve, Retrieve Acknowledgement, and Report abstract transactions are mapped to corresponding M-IMAP commands and features in the sections below.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

MMS MM1 Stage 3 Using M-IMAP Figure 1 - Abstract Transaction Call Flows
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

X.S0016-311 v1.0

Originator MMS User Agent

Originator MMS Relay / Server

Recipient MMS Relay / Server

Recipient MMS User Agent

MM1 Submit.REQ MM1 Submit.RES MM4_forward.REQ MM1 forward.RES MM1 Notification.REQ MM1 Notification.RES MM1 Retrieve.REQ MM1 Retrieve.RES MM1 Acknowledgement.REQ MM4_delivery_report.REQ MM1 Delivery report.REQ MM4_delivery_report.RES MM4_read_reply.REQ MM1 Read_reply_ report_originator.REQ MM4_read_reply.RES MM1_Read_reply_ report recipient.REQ

3.2

MM1 M-IMAP Stage 3 Specification (Normative)

The M-IMAP implementation option of the MM1 interface provides a protocol that fulfills the Message Submission, and Message Retrieval functions. MIMAP may also be used to fulfill Delivery Report and Read-Reply Report functions. The specific M-IMAP usage to fulfill these functions are described separately. The abstract message flows for these functions are described in [MMS_Stage2]. For each Stage 2 function, only those portions of the M-IMAP commands that are needed to provide the function are described, and sometimes only partially. The complete M-IMAP specification is provided separately in Section 4 below.

3.2.1

Submission of Multimedia Message

The MMS UA utilizes the M-IMAP protocol in order to send a multimedia message. It provides the mechanism for the MMS UA to submit an MM message to the MMS Relay/Server and to get back information in response.

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

3.2.1.1

Transaction Flow: Submission of Multimedia Message

The originator MMS User Agent shall submit a terminal-originated MM to the originator MMS Relay/Server using the M-IMAP protocol as specified below. The MMS UA shall initiate the M-IMAP session before submitting a MM by opening a TCP connection with the MMS Relay/Server and sending an AUTH command, followed by the DELV command that contains the message. C: S: C: S: AUTH S MYNAI OK DELV N command parameters MSG message-text OK

If the incoming message has not been supplied with a satisfactorily unique Message-ID, the MMS Relay/Server shall return the generated unique Message-ID in a separate, specially formatted message, delivered using normal message delivery mechanisms. The detailed syntax and processing of the M-IMAP DELV command are provided in Section 4.7 below. Example:
C: AUTH S MYNAI S: OK C: DELV N TO {7} yournai CC {17} friends@lists.net SUBJECT {18} Birthday pictures! MSG {xx} X-MMS-Read-Reply: no X-MMS-Transaction-Id: 123456 Content-type: application/vnd.wap.mms, boundary="---1234567---" -----1234567--- [SMIL part] -----1234567--- [Picture part] -----1234567--- Content-type: text/plain Hi! Here are a couple of pictures from my new MMS phone taken of the birthday party. Let me know how you like them. -----1234567----- S: OK C: LOUT S: BYE

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

3.2.2

Multimedia Message Notification

This Stage 3 does not make a specific recommendation on the exact notification transport method, but may be used in combination with any notification method defined in TIA-934/X.S0016 or based on [SMS]. The requirements placed by this Stage 3 of the Notification method is that it must represent the MM information elements as specified below in Section 3.8.1.3, and that it must support the transmission of a textual representation of an IMAP URL [RFC2192] containing an IMAP UID, which is a 32-bit integer value. The UID is used by an MMS User Agent in the Retrieval methods. Figure 2 and figure 3 below depicts the notification and retrieval call flows for both the immediate and deferred cases respectively. The abstract notification method is used for the purpose of providing the context of the subsequent notification response and message retrieval.

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

MMS UA

MMS Relay/ Server MM1_Notification.REQ with IMAP <UID>

MM1_notification.REQ

MM1_retrieve.REQ

M-IMAP FECH <UID>

MM1_retrieve.RES

OK

M-IMAP DELV N (notification response) MM1_notification.RES OK

Figure 2 - Notification and Immediate Retrieval of Multimedia Message


MMS Relay/ Server

MMS UA

MM1_notification.REQ

MM1_Notification.REQ w/IMAP <UID>

M-IMAP DELV N Notification response MM1_notification.RES OK Time Passes MM1_retrieve.REQ M-IMAP FECH <UID>

MM1_retrieve.RES

msg & OK

M-IMAP DELV N Acknowledgement MM1_ acknowledgement.REQ OK

Figure 3 - Notification and Delayed Retrieval of Multimedia Message

10

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

3.2.2.1

Transaction Flow: Notification Response

If the MMS User Agent wishes to deny a Delivery Report, it must return a notification response with the information element set thusly Report allowed: no. M-IMAP shall provide for the MM1_notification.RES as depicted in Figure 2 and described below. To form a notification response, the MMS User Agent shall establish a new or use an existing M-IMAP connection, authenticate, and then submit a message consisting of MMS headers and no body using the M-IMAP DELV command. Since the Notifcation response does not use recipient addressing, the addressing used on the DELV command for these administrative messages shall be an operator configuration. The provisioning of the administrative addresses is determined by the operator and is out of scope for this specification. Example: C: DELV N FROM {5} mynai TO {2} <> MSG {97} X-MMS-Message-type: MM1_notification.RES X-MMS-Message-Id: message-id X-MMS-Delivery-Report: no S: OK

3.2.3

Multimedia Message Retrieval

3.2.3.1

Transaction flow: Message Retrieval

MM message retrieval by the MMS User Agent is accomplished with the MIMAP FECH command to the MMS Relay/Server. Delivery of the MM message may be either before or after the MM1_notification.RES message, depending on immediate retrieval or delayed retrieval of MM message respectively. The MMS Relay/Sever may therefore decide to request an acknowledgement from the

11

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

MMS User Agent to confirm successful retrieval in case of delayed retrieval. These variations are shown in Figure 2 and Figure 3 respectively. The MMS User Agent shall initiate the retrieval activity with the M-IMAP FECH command with the IMAP URL containing a UID that was received in the MM1_notification.REQ message. The response message MM1_retrieve.RES, if successful, contains the MM message. This MM message shall include MMS headers providing additional information. Depending on the MMS Relay/Server needs, the MM1_retrieve.RES may request that an acknowledgement be generated by the MMS User Agent. The MMS Relay/Server may make this request based on whether or not it needs to provide a Delivery Report or Read-Reply Report back to the originator of the MM message. Alternatively, it may make that request based upon an expectation that it would then be able to delete the message. If an acknowledgement is requested, the MMS User Agent shall respond by invoking an M-IMAP DELV N command using only the MSG parameter, with the message containing only MMS headers, which are detailed below in the section 3.8.1.7. An example acknowledgement: C: DELV N FROM {5}( mynai( TO {2}( <>( MSG {124}( X-MMS-Message-type: MM1_acknowledgement.RES( X-MMS-Message-Id: message-id( X-MMS-Delivery-Report: no( X-MMS-Read-Reply: no( ( S: OK 3.2.3.2 Message Retrieval Security Issues

The basic security model for an MMS system using M-IMAP is network based authentication. Optionally, the recipient MMS User Agent may invoke authentication and security procedures as described in [RFC2595], [RFC2195] and [RFC1731]. The above-mentioned RFCs provide a comprehensive security framework for retrieving MMs. However the selection of the specific security algorithms is a deployment specific issue and it is left to the discretion of the individual service provider.

12

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

The MMS Relay/Server may support the full set of security algorithms specified in [RFC2595], [RFC2195] and [RFC1731] and their associated references in order to enable a wider selection of security algorithms by the service provider. Table 1 depicts the Mandatory (M), Recommended (R) and Optional (O) RFCs that shall or may be supported by the MMS User Agent and MMS Relay/Server:
Table 1 - IMAP-related RFCs

IMAP related RFCs


[RFC3501] [RFC2595] [RFC2195] [RFC1731] [RFC2342] [RFC2359] [RFC2088]

Title
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 Using TLS with IMAP, POP3 and ACAP IMAP/POP AUTHorize Extension for Simple Challenge/Response IMAP4 Authentication Mechanisms IMAP4 Namespace IMAP4 UIDPLUS extension IMAP4 non-synchronizing literals

Status
M R R R R R O

3.2.3.3

Error Considerations: MMS User Agent Retrieving the Multimedia Message

The error cases, BAD and BYE, related to the MM1_retrieve.REQ and MM1_retrieve.RES are specified in M-IMAP FECH reference Section 4.5.3.

3.2.4

Forwarding of Multimedia Message

The MMS Relay/Server utilizes the M-IMAP protocol to forward multimedia messages without prior retrieval. It provides a method for the MMS UA to indicate the forwarding without a prior retrieval of a MM message to the MMS Relay/Server and to get back information (e.g., Status, Delivery Report, etc.) in response. The following figure gives an example of this transaction. All commands names depicted in the following figure are specified in section 4.

13

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Figure 4 - Forwarding without prior retrieval of Multimedia Message

MMS UA M-IMAP DELV F UID MM1_forward.REQ

MMS Relay/ Server

MM1_forward.RES

OK

3.2.4.1

Transaction flow: Message Forwarding

When the MMS User Agent decides to redirect an MM to another recipient, the M-IMAP DELV F command is used with literal text containing the information elements necessary to accomplish the redirection, including a UID to the original message. Please see section 3.8.1.8 for the detailed mappings from information elements to headers. 3.2.4.2 Error Considerations: Message Forwarding

When errors occur, the M-IMAP DELV command shall respond with BAD and appropriate explanatory text. The responses are described in section 4.7.3.

3.2.5

Delivery Report (Informative)

To permit the originator MMS User Agent to know when a message delivery has occurred the Delivery Report message has been defined to provide that information. The MM1_delivery_report.REQ message originates at the MMS Relay/Server providing information to the MMS User Agent about the message that was delivered. 3.2.5.1 Transaction flow: Delivery Report

The MM1_delivery_report.REQ message may be delivered by the MMS Relay/Server to the MMS User Agent using any technical realization of the MM1_Notification.REQ request defined in TIA-934/X.S0016, including SMS [SMS] (option 1) or using normal message delivery mechanisms (option 2). In option 1 the Delivery Report message shall be sent as the message body of a Notification request, the details of which are out of scope for this specification.

14

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

In option 2 the Delivery Report is an administrative message, and shall be formatted as a Delivery Status Notification (DSN) [RFC1894], and delivered using the same mechanisms as with normal MMs. In both options 1 and 2, due to the nature of the message, the following MMS headers shall be set: X-Mms-Message-Class: Auto X-Mms-Read-Reply: No X-Mms-Delivery-Report: No The MM1_delivery_report.REQ message conveys information about the status of a particular message delivery that was performed. The message is identified by the Message ID that was generated when the original message was posted. It also provides addressing information of the original recipient. If an MM message was addressed to multiple recipients, multiple MM1_delivery_report.REQ messages should be expected to be returned, one for each recipient. A recipient MMS User Agent may, within an MM1_notification.RES message or an MM1_acknowledgement.REQ message, request denial of an originators request for delivery notification. Therefore, an MMS User Agent should not expect to receive all the MM1_delivery_report.REQ messages that it may have requested. 3.2.5.2 Error Considerations: Delivery Report

The error conditions for option 1 are out of scope for this document. In option 2, delivery of a Delivery Report message is as for a normal message and does not require additional error considerations.

3.2.6

Read-Reply Report (Informative)

When the originator MMS User Agent requests the Read-Reply Report in a multimedia message, the recipient MMS User Agent may send a Read-Reply Report message back to it. This message is sent by the recipient MMS User Agent using the normal submission mechanisms. The Read-Reply Report message is delivered to the originator MMS User Agent using the normal message notification and retrieval methods. 3.2.6.1 Transaction flow: Read-Reply Report

If supported by a recipient MMS User Agent, the MM1_read_reply_recipient.REQ message is sent to the MMS Relay/Server when a MM message has been read and includes the X-Mms-Read-Reply header with value Yes. The message shall be submitted using the normal MM1_submit.REQ operation as it is just another message origination.
15

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

The MM1_read_reply_originator.REQ message shall be formatted as specified for Message Disposition Notifications (MDNs) [RFC2298], and delivered by the MMS Relay/Server to the originator MMS User Agent using the normal message notification and retrieval (delivery) mechanisms as described in the Delivery Reports. Due to the nature of the message, the message shall have these MMS headers: X-Mms-Message-Class: Auto X-Mms-Read-Reply: No X-Mms-Delivery-Report: No The MM1_read_reply_originator.REQ message conveys information about the disposition of a particular multimedia message. The message is identified by the Message ID that was generated when the original message was posted. It also provides addressing information of the original recipient. If an MM message was addressed to multiple recipients, multiple MM1_read_reply_originator.REQ messages shall be expected to be returned, one for each recipient, unless the Read-Reply report request is denied by the recipient. A recipient MMS User Agent may deny an originators request for Read-Reply notification. Therefore, an MMS User Agent should not expect to receive all the MM1_read_reply_originator.REQ messages that it may have requested. 3.2.6.2 Error Considerations: Delivery Read-Reply

Origination of a Read-reply message by the recipient MMS User Agent is as for a normal message and does not require additional error considerations. Notification and retrieval of a Read-reply message by the originator MMS User Agent is as for a normal message and does not require additional error considerations.

3.3

Terminal Capability Negotiation

This specification does not support Terminal Capability Negotiation.

3.4

MMS Message contents (Normative)

The Multimedia Message (MM) consists of MMS headers and a message body. The message body may contain any content type, and generally consists of a multipart/related content type. The MIME multipart ([RFC2045], [RFC2046], and [RFC2047]) is used in Internet message formats, which makes MMS MMs compatible. The content type of the MM, as currently specified within the OMA MMS technical realization [MMS_OMA], is application/vnd.wap.mms-message.

16

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

The content type application/vnd.wap.mms-message is based on the content type multipart/related, which provides an example of how multimedia content and presentation information may be encapsulated to a single message (see [RFC2387]). Figure 5 below depicts the conceptual model. Although this technical realization, based on Internet message standards, may accommodate message bodies of any MIME type, the above-mentioned content types are specified for reasons of compatibility and interoperability with the [MMS_OMA] technical realization. application/vnd.wap.mms-message MMS headers
Start

Message Body presentation

image/jpeg

text/plain

audio/wav

Figure 5 - Application/vnd.wap.mms-message Structure (from [MMS_OMA])

The MMS-headers contain MMS-specific information, which is mainly information about the transfer of the multimedia message from the originator terminal to the recipient terminal. See the Encapsulation Protocol from [MMS_OMA] for more details.

17

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

3.5

MMS Presentation (Informative)

The rendering of an MM for a user is the ultimate objective of the MMS. This rendering operation is known as presentation. Various types of data may be used to drive the presentation. For example, the MM presentation may be based on a WML deck [WAP238] or [SMIL] which includes links to other component elements in the multipart message. Other presentation models may include a simple text body with image attachments.

3.6

MMS Security Model (Informative)

Table 2 lists the relevant security RFCs that provide a comprehensive security framework for MMS. The security functions specified by these RFCs include: 1. Authentication of the MMS UA 2. Authentication of the Author of the MM 3. Encryption of the message content 4. Encryption of the MMS UA and MMS Relay/Server communication link The RFCs listed in Table 2 provide a comprehensive security framework for the MM1 technical realization specified in this section. The choice of specific security protocols depends on the security level desired by the MMS service provider and is out of the scope of this specification. The basic security model for an MMS system using M-IMAP is network based authentication. The MMS Relay/Server should support the full set of security protocols specified in the following table in order to provide a comprehensive set of security choices for the MMS service provider. The status is "R" for "Recommended".

18

MMS MM1 Stage 3 Using M-IMAP Table 2 - Security related RFCs


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

X.S0016-311 v1.0

Security-related RFCs [RFC2595] [RFC2195] [RFC1731] [RFC2632] [RFC2633] [RFC2634] [RFC3156] [RFC2444] [RFC2246]

Title Using TLS with IMAP, POP3 and ACAP IMAP/POP AUTHorize Extension for Simple Challenge/Response IMAP4 Authentication Mechanisms S/MIME Version 3 Certificate Handling S/MIME Version 3 Message Specification Enhanced Security Services for S/MIME MIME Security with OpenPGP The One-Time-Password SASL Mechanism The TLS Protocol

Status R R R R R R R R R

3.7

Mapping of Abstract messages (Normative)

The following tables specify the mapping of abstract MM1 messages to the appropriate M-IMAP operations.
Table 3 - Mapping of MM1 Submit abstract messages
Abstract messages MM1_submit.REQ MM1_submit.RES Mapping M-IMAP DELV N Command M-IMAP DELV N Command Direction MMS UA -> MMS Relay/Server MMS Relay/Server -> MMS UA

Table 4 - Mapping of MM1 Notification abstract messages


Abstract messages MM1_notification.REQ MM1_notification.RES Mapping Direction Any MM1_notification method MMS Relay/Server -> MMS UA M-IMAP DELV N Command MMS UA -> MMS Relay/Server

Table 5 - Mapping MM1 Retrieve abstract messages


Abstract messages MM1_retrieve.REQ MM1_retrieve.RES MM1_acknowledgement.REQ Mapping M-IMAP FECH Command M-IMAP FECH Response M-IMAP DELV N Command Direction MMS UA -> MMS Relay/Server MMS Relay/Server -> MMS UA MMS UA -> MMS Relay/Server

19

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP Table 6 - Mapping of MM1 Forward abstract messages
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Abstract messages MM1_forward.REQ MM1_forward.RES

Mapping M-IMAP DELV F Command M-IMAP DELV F Command

Direction MMS UA -> MMS Relay/Server MMS Relay/Server -> MMS UA

Table 7 - Mapping of MM1 Delivery Report abstract messages


Abstract Message MM1_delivery_report.REQ Mapping Normal message notification and retrieval using DSNs [RFC1894] Direction MMS Relay/Server -> MMS UA

Table 8 - Mapping of MM1 Read-Reply Report abstract messages


Abstract messages MM1_read_report_recipient.REQ Direction MMS UA -> MMS Relay/Server MM1_read_report_originator.REQ Normal message notification MMS Relay/Server -> MMS UA and retrieval using MDNs [RFC2298] Mapping M-IMAP DELV N Command

3.8

Message format on MM1 (Normative)

All elements of an MM shall be included within a single [RFC2822] mail message which shall be organized as MIME type application/vnd.wap.mmsmessage. All MM elements shall be of standard MIME content types. In addition to the MM elements, the RFC 2822 mail message shall contain all mandatory MMS information elements, and may contain the optional MMS information elements, as according to the definitions in MMS Stage 2 [MMS_Stage2]. In the case of a Notification message, only certain information elements, as determined by the service operator, shall be transmitted by the MMS Relay/Server to the MMS User Agent. All other MMS-related messages, such as delivery reports, read-reply reports, forwarding shall each be transferred as a single [RFC2822] mail message which shall be organized as MIME type text/plain. This [RFC2822] mail message should reflect all MMS information elements as defined above. In the tables below, the MMS Information Elements are mapped to their corresponding [RFC2822] headers. The second column indicates whether the information element is mandatory (M), optional (O), or conditional (C).

20

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

3.8.1

Message header fields

MMS information elements shall be reflected as header fields according to [RFC2822]. See [RFC2076] for a detailed description of common Internet message headers. Some of the mappings are context dependent. For those information elements that cannot be mapped to standard [RFC2822] header fields the X- extensions mechanism shall be used with an X-MMS- prefix. The mapping of information elements to commonly used (see [RFC2076]) or standard [RFC2822] header fields is shown in following tables. 3.8.1.1 MM1_submit.REQ Header Mappings

The mappings of the MM1_submit.REQ information elements to [RFC2822] headers is detailed in the table below.
Table 9 - MM1_submit.REQ Information Elements to [RFC2822] Header Mappings
Information element MMS MM1 Version Message Type Transaction ID Message ID Recipient(s) address Content type Sender address Message class Date and time Time of Expiry Earliest delivery time Delivery report Reply-Charging Reply-Charging-size Reply-Deadline Priority Sender visibility Read reply Subject Reply-Charging-ID Content Type M M M M M M O O O O O O O O O O O O O O O MM1_submit.REQ Headers X-Mms-MM1-Version: X-Mms-MM1-Message-Type: X-Mms-Transaction-ID: X-Mms-Message-ID: One or more of: To:, Cc:, Bcc: Content-Type: From: X-Mms-Message-Class: Date: X-Mms-Expiry: X-Mms-Delivery-Time: X-Mms-Delivery-Report: X-Mms-Reply-Charging: X-Mms-Reply-Charging-size: X-Mms-Reply-Deadline: X-Mms-Priority: X-Mms-Sender-Visibility: X-Mms-Read-Reply: Subject: X-Mms-Reply-Charging-ID: <message body>

The table above indicates the mappings from MM1_submit.REQ information elements to the corresponding [RFC2822] headers. The MM Message-ID is not directly mapped to a corresponding [RFC2822] Message-ID: header.

21

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

The Content-type information element maps directly to the corresponding header since both are defined as being MIME content types as specified in [RFC2046]. The [RFC2822] From: header is determined by the mail user agent, or, in this case, the MMS User Agent. This corresponds to the MM Sender address, as set by the MMS User Agent. 3.8.1.2 MM1_submit.RES Header Mappings

The MM1_submit.RES abstract message maps to an administrative message sent from the MMS Relay/Server to the MMS User Agent. The administrative message, formatted according to [RFC2822], shall contain the information elements mapped to X-MMS headers. The Request Status and Request Status Text information elements map to the M-IMAP DELV response codes and their associated text as specified in section 4.7.
Table 10 - MM1_submit.RES Information Elements to [RFC2822] Header Mappings
Information element Message Type Transaction ID MMS Version Request Status Request Status Text Message ID Type M M M M O C Submit.RES Headers X-MMS-Message-type: MM1_submit.RES X-MMS-Transaction-Id X-MMS-Version X-MMS-Request-Status: X-MMS-Request-Status-text: X-MMS-Message-ID:

3.8.1.3

MM1_notification.REQ Header Mappings

Although this document does not specify a technical realization for the MM1_notification.REQ, it does require that certain information elements be delivered in the request, as specified in the Stage 2 specification [MMS_Stage2]. The representations of the values for these headers is given below, in section 3.8.1.13. The determination of which information elements are to be transmitted in the MM1_notification.REQ is an operator configuration issue. However, this technical realization requires that the Message Reference shall be sent as part of the MM1_notification.REQ. The table below indicates which information elements should be sent:

22

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

Table 11 - MM1_notification.REQ Information Elements to Header Mappings


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Information element Message Type Transaction ID MMS Version Message class Message size Time of expiry Message Reference Subject Priority Sender address Delivery report Reply-Charging Reply-Deadline Reply-Charging-Size Reply-Charging-ID Element-Descriptor Message Distribution Indicator

Type M M M M M M M O O C O O O O O O O

MM1_Notification.REQ Headers X-MMS-Message-type: MM1_notification.REQ X-MMS-Transaction-ID: X-MMS-Version: X-MMS-Message-class: X-MMS-Message-size: X-MMS-Expiry: X-MMS-Message-Ref: IMAP URL with UID [RFC2192] Subject: X-MMS-Priority: From: X-MMS-Delivery-Report: X-MMS-Reply-Charging: X-MMS-Reply-Deadline: X-MMS-Reply-Charging-Size: X-MMS-Reply-Charging-ID: X-MMS-Element-Ref: X-MMS-Distribution: [No | Ok]

3.8.1.4

MM1_notification.RES Header Mappings

The MM1_notification.RES abstract message maps to an administrative message sent via an M-IMAP DELV N command with a message containing only MMS headers.
Table 12 - MM1_notification.RES MM Status Information Element values to [RFC2822] Headers
Information element Message Type Transaction ID MMS Version MM Status Report allowed Type M M M M O MM1_notification.RES Headers X-MMS-Message-Type: MM1_notification.RES X-MMS-Transaction-Id: X-MMS-Version: X-MMS-Status: [Retrieved | Rejected | Deferred | Unrecognized] X-MMS-Delivery-Report: [yes | no]

3.8.1.5

MM1_retrieve.REQ Header Mappings

The MM1_retrieve.REQ abstract message maps to the M-IMAP FECH command. The MM1_retrieve.REQ has these information elements mapped to parameters on the DELV command:

23

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Table 13 - MM1_retrieve.REQ MM Status Information Element values to M-IMAP DELV Parameters


Information element Message Reference Type M M-IMAP DELV Parameters UID

3.8.1.6

MM1_retrieve.RES Header Mappings

The mappings of the MM1_retrieve.RES information elements to [RFC2822] headers is detailed in the table below.
Table 14 - MM1_retrieve.RES Information Elements to [RFC2822] Header Mappings
Information element MMS MM1 Version Transaction ID Message ID Sender address Content type Recipient(s) address Message class Date and time Delivery report Priority Read reply Subject Request Status Request Status Text Reply-Charging Reply-Charging-ID Reply-Charging-Size Reply-Deadline Forward_counter Forwarded_by Content Type M C M C M O O M C C C C O O O O O O O O C MM1_retrieve.RES Headers X-Mms-MM1-Version: (omitted not needed for MIMAP) X-Mms-Message-ID: From: Content-Type: To:, Cc:, Bcc: X-Mms-Message-Class: Date: X-Mms-Delivery-Report: X-Mms-Priority: X-Mms-Read-Reply: Subject: X-MMS-Status: X-MMS-Status-text: X-Mms-Reply-Charging: X-Mms-Reply-Charging-ID: X-Mms-Reply-Charging-Size: X-Mms-Reply-Deadline: X-Mms-Forward-Counter: Resent-From: <message body>

The Transaction ID is not needed for M-IMAP based MM1 because the retrieval acknowledgement is implicit in the M-IMAP session. 3.8.1.7 MM1_acknowledgement.REQ Header Mappings

The MM1_acknowledgement.REQ abstract message maps to an administrative message sent from the MMS User Agent to the MMS Relay/Server using the MIMAP DELV command with a message containing only MMS headers.

24

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Table 15 - MM1_acknowledgement.REQ Information Element values to [RFC2822] Headers


Information element Message Type Transaction ID MMS Version Delivery Report allowed Read-Reply Report allowed Type M C M O O Acknowledgement.REQ Headers X-MMS-Message-Type: MM1_acknowledgement.REQ X-MMS-Transaction-Id: X-MMS-Version: X-MMS-Delivery-Report: [yes | no] X-MMS-Read-Reply: [yes| no]

3.8.1.8

MM1_forward.REQ Header Mappings

The mappings of the MM1_forward.REQ information elements to [RFC2822] headers is detailed in the table below.
Table 16 - Header mappings for MM1 Forwarding
Information element Message Type MMS MM1 Version Transaction ID Recipient address Forwarding address Date and time Time of Expiry Earliest delivery time Delivery report Read reply Message Reference Type M M M M O O O O O O M MM1_Forward.REQ Headers X-MMS-Message-Type: MM1_forward.REQ X-Mms-MM1-Version: X-Mms-Transaction-ID: One or more of: Resent-To:, ResentCc:, Resent-Bcc: Resent-From: Resent-Date: X-Mms-Expiry: X-Mms-Delivery-Time: X-Mms-Delivery-Report: X-Mms-Read-Reply: M-IMAP UID

3.8.1.9

MM1_forward.RES Header Mappings

The MM1_forward.RES abstract message maps to the M-IMAP DELV F command response. The Status and Status Text information elements map to the M-IMAP DELV F response codes and their associated text as specified in section 4.7. Example:
C: DELV F 432340 MSG {310} TO {11} +MSISDN-C1 CC {11} +MSISDN-C2 FROM {11} +MSISDN-B DATE {37}

25

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Mon, 7 Feb 1994 21:52:25 -0800 (PST) MSG {xxx} X-Mms-Expiry: Wed, 9 Feb 1994 21:52:25 -0800 (PST) X-Mms-Delivery-Time: X-Mms-Delivery-Report: Yes X-Mms-Read-Reply: No This is a message body (with headers above). S: OK

Status and Status text map to the possible status responses of the M-IMAP command, as specified in section 4.7.
Table 17 - Mapping of Information elements in the MM1_forward.RES.
Information element Message Type Transaction ID MMS Version Request Status Request Status Text Message ID Type M M M M O M MM1_Forward.RES Headers X-MMS-Message-type: MM1_forward.RES. X-MMS-Transaction-Id: X-MMS-Version: X-MMS-Status: X-MMS-Status-text: X-MMS-Message-Id:

3.8.1.10

MM1_delivery_report.REQ Header Mappings (Informative)

The mappings of the MM1_delivery_report.REQ information elements to [RFC2822] headers is detailed in the table below.

Table 18 - MM1_Delivery_report.REQ Information Elements to [RFC2822] Header Mappings


Information element MMS MM1 Version Message Type MM Message ID Recipient address Date and time MM Status Code Status Text Type M M M M M M O MM1_Delivery_report.REQ Headers X-Mms-MM1-Version: X-MMS-MM1-Message-Type: X-Mms-Message-ID: From: Date: X-Mms-MM-Status-Code: X-Mms-Status-text: Message-Id:

3.8.1.11

MM1_read_reply_recipient.REQ Header Mappings (Informative)

The mappings of the MM1_read_reply_recipient.REQ information elements to [RFC2822] headers are detailed in the table below.

26

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Table 19 - MM1_read_reply_ recipient.REQ Information Elements to [RFC2822] Header Mappings


Information element MMS MM1 Version Message Type Recipient address Originator address Message-ID Date and time MM Status Code Status text Type M M M M M O M O MM1_read_reply_recipient.REQ Headers X-Mms-MM1-Version: X-Mms-MM1-Message-Type: From: To: X-Mms-Message-ID: Date: X-Mms-MM-Status-Code: X-Mms-Status-Text:

3.8.1.12

MM1_read_reply _originator.REQ Header Mappings (Informative)

The mappings of the MM1_read_reply_originator.REQ information elements to [RFC2822] headers are detailed in the table below.
Table 20 - MM1_read_reply_originator.REQ Information Elements to [RFC2822] Header Mappings
Information element MMS MM1 Version Message Type Recipient address Originator address Message-ID Date and time MM Status Code Status text Type M M M M M M M O MM1_read_reply_originator.REQ Headers X-Mms-MM1-Version: X-MMS-MM1-Message-Type: MM1_read_reply_originator.REQ From: To: X-Mms-Message-ID: Date: X-Mms-MM-Status-Code: X-Mms-Status-Text:

3.8.1.13

MM1_read_reply _recipient.REQ Header Mappings (Informative)

The mappings of the MM1_read_reply_recipient.REQ information elements to [RFC2822] headers are detailed in the table below.

27

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Table 21 - MM1_read_reply_recipient.REQ Information Elements to [RFC2822] Header Mappings


Information element MMS MM1 Version Message Type Recipient address Originator address Message-ID Date and time MM Status Code Status text Type M M M M M M M O MM1_read_reply_recipient.REQ Headers X-Mms-MM1-Version: X-MMS-MM1-Message-Type: MM1_read_reply_recipient.REQ From: To: X-Mms-Message-ID: Date: X-Mms-MM-Status-Code: X-Mms-Status-Text:

3.8.1.14

MM1 Message header field value range

MMS information elements that are mapped to standard [RFC2822] header fields, i.e. which do not have an X-MMS- prefix, should be used according to [RFC2822]. The rest of the header definitions used in this section, including the mechanisms and pre-defined tokens, are described in an augmented Backus-Naur Form (BNF), similar to that used by [RFC2822]. Implementors need to be familiar with the notation in order to understand these definitions. The Status Codes are as defined in [RFC1893] Enhanced Mail System Status Codes. For the residual MMS information elements the following applies: X-Mms-MM1-Version:
MMS-MM1-Version = "X-Mms-MM1-Version" ":" (text-string -) 1*DIGIT "." 1*DIGIT ("." 1*DIGIT)

Examples: X-MMS-MM1-Version: 1.0 X-MMS-MM1-Version: M-IMAP-1.0 Note that the numbers MUST be treated as separate integers and that each may be incremented higher than a single digit. Thus, 2.1.4 is a lower version than 2.1.13, which in turn is lower than 2.3.0 Leading zeros shall be ignored by recipient MMS Relay/Server and shall NOT be sent. The version is according to the version of this specification (see also subclause Foreword).

28

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

X-Mms-MM1-Message-Type:
Message-Type = "X-Mms-MM1-Message-Type" ":" ( "MM1_submit.REQ" | "MM1_notification.REQ" | "MM1_delivery_report.REQ" | "MM1_read_reply_recipient.REQ" | "MM1_read_reply_originator.REQ" )

X-Mms-Content-URI:
Message-Reference = "X-Mms-Content-URI" ":" URI

X-Mms-Expiry:
Time-of-Expiry = "X-Mms-Expiry" ":" ( HTTP-date | delta-seconds )

X-Mms-Forward-Counter:
Forward-counter = "X-Mms-Forward-Counter" ":" long-integer

X-Mms-Delivery-Time:
Earliest-delivery-time = "X-Mms-Delivery-Time" ":" ( HTTP-date | delta-seconds )

X-Mms-Delivery-Report:
Delivery-report = "X-Mms-Delivery-Report" ":" ( "Yes" | "No" )

X-Mms-Message-ID:
Message-ID = "X-Mms-Message-ID" ":" quoted-string

X-Mms-Message-Class:
Message-class = Class-identifier = "X-Mms-Message-Class" ":" ( Class-identifier | quotedstring ) "Personal" | "Advertisement" | "Informational" | "Auto"

X-Mms-Message-Size:
Message-size = "X-Mms-Message-Size" ":" long-integer

X-Mms-Message-Reference:
Message Reference = "X-Mms-Message-Ref" ":" IMAP-URL [RFC2192]

X-Mms-Priority:
Priority = "X-Mms-Priority" ":" ( "Low" | "Normal" | "High" )

X-Mms-Reply-Charging:
Reply-Charging = "X-Mms-Reply-Charging" ":" ( Yes | No )

29

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

X-Mms-Reply-Charging-ID:
Reply-Charging-ID = "X-Mms-Reply-Charging-ID" ":" quoted-string

X-Mms-Reply-Deadline:
Reply-Deadline = "X-Mms-Reply-Deadline" ":" ( HTTP-date | delta-seconds )

X-Mms-Sender-Visibility:
Sender-visibility = "X-Mms-Sender-Visibility" ":" ( "Hide" | "Show" )

X-Mms-Read-Reply:
Read-reply = "X-Mms-Read-Reply" ":" ( "Yes" | "No" )

X-Mms-Request-Status-Code:
Request-status-Code = "X-Mms-Request-Status-Code" ":" ( 2 | 4 | 5 ) <subcode> <itemcode> (See [RFC1893])

X-Mms-MM-Status-Code:
MM-Status-Code = "X-Mms-MM-Status-Code" ":" ( "Expired" | "Retrieved" | "Rejected" | "Deferred" | "Intermediate" | "Forwarded" | "Unrecognised" | text-string )

X-Mms-Status-Text:
Status-text = "X-Mms-Status-Text" ":" (Text-string)

X-Mms-Transaction-ID:
Transaction ID = "X-Mms-Transaction_ID" ":" (Text-string)

3.8.1.15

Message Encoding on MM1

The M-IMAP DELV mail message format shall be encoded according to [RFC2822]. 3.8.1.16 MM1 Address encoding

In the case where [RFC2822] addressing is used the address encoding shall be compliant with encoding rules specified in [RFC2822]. In the case where [E.164] addressing is used the addresses shall be encoded in the following way:
30

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Reverse-Path = "<" MMS-address ">" Forward-Path ="<" MMS-address ">" addr-spec = MMS-address MMS-address = "+" E.164 ["/TYPE=PLMN"] E.164 = 1*DIGIT Where Reverse-Path and Forward-Path are specified in [RFC2821] and addr-spec is specified in [RFC2822] Example:
C: DELV N FROM {11} +14255551212 TO {11} +442055555555 MSG {xxx} Subject: Pictures from Greece Blah blah blah... S: OK ID=1001_14255551212@operatorA.net C: LOUT S: BYE

3.9

Sample Application (Informative)

This M-IMAP Stage 3 may be used with any notification method that is defined in TIA-934/X.S0016 or [SMS]. There are two popular notification methods being used in todays mobile networks: [SMS] and WAP Push [WAP250]. The only requirement of the notification method is that it must be able to support the textual transmission of an IMAP URL [RFC2192] containing a UID reference to the newly arrived message. The MMS User Agent (UA), upon receiving a notification, takes the message reference, in the form of an IMAP URL, and performs a Message Retrieval as described above in the normative sections. Of course, the UA may choose to not retrieve the message immediately, in which case, the UA must send a Notification response. The response is performed with an M-IMAP DELV command with the appropriate MMS headers in a special administrative message that is the notification response message. The primary purpose of the notification response is to change the default behavior of the Delivery Report request.

31

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Having received a notification, the UA then initiates a Message Retrieval using the M-IMAP FECH command, after which the UA must generate a message acknowledgement request in order to, again, change the default behavior of the Delivery Report and Read-Reply Report requests. The Acknowledgement message is sent by the UA to the MMS Relay/Server using the M-IMAP DELV command as another administrative message containing only the specialized MMS headers with appropriate values to affect the Delivery and Read-Reply Report generation. If the default response to any Delivery or Read-Reply Report is acceptable, the UA does not actually need to send an MM1_acknowledgement.REQ because the M-IMAP session is TCP-based, and, therefore, has guaranteed delivery as an implicit feature.

32

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Mobile-IMAP Reference Specification (Normative)


Features

4.1

Mobile-IMAP (M-IMAP) commands and features are based on IMAP4 [RFC3501]. A Mobile-IMAP server shall understand and support regular IMAP4 commands and features, and has the following additional features:

4.1.1

Abbreviated commands and responses

In order to trigger the behavior specific to the M-IMAP mode, as opposed to regular IMAP4, certain commands are uniquely abbreviated. Along with the unique abbreviations, certain portions of regular IMAP4 commands and responses are omitted. Ex) AUTH = AUTHENTICATION SACH=SEARCH If a regular IMAP4 command name is sent by the client to the M-IMAP server, regular IMAP4 responses shall occur. If an M-IMAP command is sent, then abbrievated responses shall occur, as specified in the M-IMAP Reference Specification below. For example, once a MS has logged in via the AUTH command (a M-IMAP command), part of the IMAP4 SELECT command response is returned. However, if an error occurs, the response shall be that of the failed AUTHENTICATE command. For example, if the login fails, the AUTH response of (NOBAD) occurs.

4.1.2

Combined Commands

IMAP4 servers support command pipe-lining, which is the capability of issuing several commands from the client to the IMAP4 server over the same transaction. The M-IMAP reference specification defines and names some common sequences that are frequently used in a mobile networking environment. These named pipeline command sequences are, in effect, a kind of "macro". The effect of using these M-IMAP macro commands is to reduce the number of transactions needed to accomplish common functions. For example, a very frequent operation is for the MS station to login (and authenticate) and then select a mailbox (typically the Inbox). The M-IMAP specifiation defines this common operation as AUTH, which is equivalent to AUTHENTICATE and SELECT.

33

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

4.1.3

Message Submission

M-IMAP has a new command to support using the M-IMAP connection for message submissions. This avoids requiring the MS to use additional resources for establishing another connection.

4.1.4

Tags

IMAP4 specifies the use of command and response tags, by which asynchronous responses may be correlated with their originating commands. M-IMAP expects command responses to be returned synchronously with each command, and thus, the command tags are omitted for M-IMAP commands.

4.1.5

Error messages

There are three types of error return commands; NO, BAD and BYE. No error message or error number is attached to the end of any of these messages. An M-IMAP server returns BAD when it receives an unknown command, or when the argument syntax of the command is incorrect. An M-IMAP server returns NO when the command argument semantics are incorrect, or when the command processing fails (such as an authentication failure). An M-IMAP server returns BYE when an internal system or network error occurs and processing cannot continue.

4.1.6

Timeout

An M-IMAP server in M-IMAP mode sends replies only in response to commands from the Mobile Station. In M-IMAP mode, asynchronous messages from the server do not occur. For example, when new mail arrives in an IMAP folder that is selected, the regular IMAP server notifies the client with an asynchronous untagged response, but the M-IMAP Server does not. However, the M-IMAP server may perform independent actions in the following cases: 1. When data has not been received from the Mobile Station or network for a configurable period of time, the session may be terminated. 2. When a socket is disconnected (for any reason), the M-IMAP server may log the disconnection and shall terminate the server-side of the IMAP session.

34

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

4.1.7

Log files

To aid in debugging and tracking SMTP session activity initiated by the M-IMAP server, M-IMAP implementations may write logfile entries to the server filesystem. The server may write the following messages when it sends a message to the Mobile Station, when it sends a message to an SMTP server, and when an error occurs: Command Commands other than DELV command DELV Log output timing Same as the regular IMAP4 Server Receiving command Message submission Message UID access SMTP session activity Contents Same as the regular IMAP4 Server Same as the regular IMAP4 Server Header information (Message-ID)

4.1.8

Coexistence with standard IMAP4 Server

The M-IMAP server shall simultaneously support both standard IMAP4 connections and M-IMAP connections. In other words, the M-IMAP server understands both M-IMAP commands and standard IMAP4 commands, and sends responses appropriate to the mode. The standard IMAP mode and custom IMAP mode are differentiated from each other by the first command received after the IMAP4 server greeting message. When this first command is AUTH or LOUT, the command shall be recognized as an M-IMAP command, and the M-IMAP server shall operate in MIMAP mode for the duration of the session. With any other initial command, the M-IMAP server shall enter standard IMAP mode and the server shall support only standard IMAP4 commands for the duration of the session. In the case of the standard IMAP mode, untagged BYE responses and tagged OK responses shall be returned when a timeout occurs. In M-IMAP mode, the untagged BYE response shall be returned. All M-IMAP functions may be accomplished using standard IMAP4 commands and features.

4.2

State Transition

At any given time, an M-IMAP session is in one of the following four states: Non Auth, Auth, Select and Logout. Each command and transition state is shown below (normal system):

35

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

TCP connection NonAuth AUTH R AUTH S Auth LOUT AUTH R Select LOUT Logout FECH SACH STOR DELV DELT AUTH S AUTH R DELV AUTH S FECH SACH LOUT

Non Auth: Auth:

The state after returning the greeting to the connection from the Mobile Station State where the mailbox is accessible in Read-Only after user authentication is finished (such as a check whether the user is allowed to use the Mobile-IMAP Server). State where the mailbox is accessible in Read-Write after the user authentication is finished. Logged out state. Just after this, the server drops the connection with the Mobile Station.

Select: Logout:

4.3
4.3.1

AUTH (Authentication)
Format
S: Login for sending messages R: Login for receiving messages MSD | NAI

AUTH <Login type> <LoginID> <Login type>: <LoginID>:

Return value when successful: S-type login: OK<CR><LF> R-type login: Number of incoming messages <CR><LF> OK<CR><LF>

36

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Error return values: NO<CR><LF> BAD<CR><LF> BYE<CR><LF> Example:


C: AUTH R S: OK

4.3.2

Operation

The LoginID is either the Mobile Directory Number (MDN) of the Mobile Station, or an NAI. The NAI is typically associated with the MDN, but, in the case of a guest user, it may not. The LoginID is used to determine the mailbox on which subsequent commands operate. While the mailbox is determined by the LoginID, the M-IMAP session authentication credentials are not. Instead, the M-IMAP server may authenticate the M-IMAP session (and bill for) using the account associated with Mobile Station IP address from which the M-IMAP session originated. This is called network-based authentication. The Login type determines whether the session is to be used for accessing messages or delivering messages. For R type logins, the number of new messages in the mailbox is returned. This is equivalent to the AUTHENTICATION and SELECT commands of regular IMAP4. For S type logins, it is equivalent to the AUTHENTICATION and EXAMINE commands of regular IMAP4. If the specified LoginID has access to a valid mailbox, the OK response shall be returned. When a user is logged in with the R type and the number of incoming messages is sent back with OK, this user has succeeded in logging in to the IMAP Server. When there is no incoming message, the number of incoming messages is 0 (zero). When a user logged in with the S type, OK is sent back. The AUTH command shall be accepted even when it has already changed to the Auth or Select state. This may happen in the following cases: When a user has recently accessed with the S type and the session has already terminated, but its module is still alive When a user has recently accessed with the S type or R type, but the session terminated due to an error that occurred during the processing, when its module is still alive

37

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

4.3.3
(1) NO -

Error cases

When the relevant user is not allowed to access this Custom IMAP Server Cannot log in. Commands other than AUTH and LOUT commands are not accepted. When an argument is incorrect (insufficient arguments or incorrect character strings, etc.) When a command character string is incorrect Cannot log in. Commands other than AUTH and LOUT commands are not accepted.

(2) BAD -

(3) BYE When a connection to the back-end system (MSSdirectory server) cannot be established (for instance, when the server is down. Cannot log in. The server discards this message and cuts off the connection immediately (panic shut-down notification)

4.3.4

Sample
; Greeting message ; Logging in with the user name pochi ; There are two new messages in the inbox

Example for logging in to receive mail s: OK c: AUTH R pochi s: 2

4.4
4.4.1

SACH (Search)
Format
xR Recent xU Unseen xS Seen (Incoming) (Unread) (Read)

SACH [<flag pattern>|<UID>] <flag pattern>:

xH Unseen and Header Seen (Receiving header only) xN Unseen and Header UnSeen (Unread except for the Receiving header only)

38

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Return value when successful: UID1 UID2 UID3 <CR><LF>OK<CR><LF> Error return value: BAD<CR><LF> BYE<CR><LF>

4.4.2

Operation

When a server is in the Select state, a search is made for the flag pattern or the UID from the inbox. When a flag pattern is specified, UIDs with a message that has a flag matching that pattern are listed up and returned. Messages come with three flags, Recent, Header Seen, and Seen. Each flag pattern is as follows: Patterns xR xU xS xH xN Recent ON Not checking Not checking Not checking Not checking Header Seen Not checking Not checking Not checking ON OFF Seen Not checking OFF ON OFF OFF

When a flag pattern is specified and there are no matches, only OK is sent back. When specifying a UID, a search is made for a message with the given UID in the mailbox. If the message is there, the UID and OK are sent back. If there is no message with the given UID, only OK is sent back.

4.4.3
(1) BAD -

Error cases

When an argument is incorrect (insufficient arguments or incorrect character strings, etc.) When a command character string is incorrect In the case of a Non Auth state

A search cannot be made. (2) BYE When a connection cannot be established to the back-end system (such as MSS), for instance, when the server is down

39

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

The server discards this message and cuts off the connection immediately (panic shut-down notification)

4.5
4.5.1

FECH (Message Fetching)


Format

FECH <UID list> <xHP|xHA|xHO|xB> [[Part] [<isolated part>]] xHP = body[header.fields (date from reply-to subject)] When receiving headers only, obtain Date, From, Reply-to, and Subject only. xHA = body[header.fields (date from reply-to subject to cc)] When receiving headers + texts, obtain To and Cc in addition to Date, From, Reply-to and Subject. xHO = body[header.fields (to cc)] When receiving headers only and obtaining the texts later on, obtain the rest of the headers. xHM = body [part. MIME] Obtaining header information of MIME part xB = body Obtain the structure of messages or text <UID list> When specifying multiple UIDs, separate them by , (commas). When specifying consecutive UIDs, separate the starting UID and the last UID by : (colon) Return value when successful Case of xHP: ( UID {Total number of characters} <CR><LF> Date: Date <CR><LF> From: From <CR><LF> Reply-to: Reply-to <CR><LF> Subject: Subject <CR><LF> )<CR><LF> ()<CR><LF>
40

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

OK <CR><LF> Case of xHA: ( UID {Total number of characters}<CR><LF> Date: Date <CR><LF> From: From <CR><LF> Reply-to: Reply-to <CR><LF> Subject: Subject <CR><LF> To: To <CR><LF> Cc: Cc <CR><LF> )<CR><LF> ()<CR><LF> OK <CR><LF> Case of xHO: ( UID {Total number of characters}<CR><LF> To: To <CR><LF> Cc: Cc <CR><LF> )<CR><LF> ()<CR><LF> OK<CR><LF> Case of xHM: ( UID {Total number of characters}<CR><LF> From: from<CR><LF> ; configurable To: To <CR><LF> ; list of Cc: Cc <CR><LF> ; headers Date: Date <CR><LF> Subject: subject<CR><LF> ( MIME Structure ) )<CR><LF> ()<CR><LF> OK<CR><LF> Case of xB (No part specification) ( UID {Total number of characters}<CR><LF> structure information <CR><LF> )<CR><LF> ()<CR><LF> OK <CR><LF> Case of xB (part specified) ( UID {Total number of characters}<CR><LF> text<CR><LF> )<CR><LF> ()<CR><LF> OK <CR><LF> Error return value:

41

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

BAD<CR><LF> BYE<CR><LF>

4.5.2

Operation

The FECH command allows portions of a message header and/or text to be selectively extracted. Messages to be fetched are specified by one or more UIDs. When more than one UID is specified, messages or portions of them are fetched in decreasing order of the specified UIDs. The information returned for each given message UID is followed by a <CR><LF>, and an OK<CR><LF> is sent after the information of the last message UID. When extracting portions of the message body text (xB specified), specify the MIME part number to be extracted in [ ] (square brackets) (in the case of extracting headers only, there is no need to specify the MIME part number). The FECH xHM command retrieves a configurable list of headers as well as the MIME structure of the body (see IMAP4 [RFC3501]MIME Structure). M-IMAP server implementations should support the capability of configuring which headers are to be returned for a given FECH selector. M-IMAP client implementations may expect certain headers for a given selector, but should be prepared to receive any one or more headers for a given FETCH selector. The isolated part is specified with < and > (angle brackets), the starting octet of the isolated part, and the number of octets to be extracted within the isolated part, separated by . (period). The number of isolated octets apply to the data of both the body and header. When the requested information from the specified UID cannot be obtained (for example, the UID is invalid, or the specified part did not exist), only the UID is returned.

4.5.3
(1) BAD -

Error cases

When an argument is incorrect (insufficient arguments or incorrect character strings, etc.) When the command character string is incorrect In the case of a Non Auth state

The data cannot be obtained. (3) BYE When a connection to the back-end system (MSS) cannot be established (for instance, when the server is down)

42

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

The server throws away this message and cuts off the connection immediately (panic shut-down notification)

4.5.4
UID1:1000

Samples

Return-Path: <> Received: from [127.0.0.1] by jpn-sun4.operator.net (InterMail vM.5.01.00.00 201-249-103-102-20000402) with SMTP id <20000524084030.AAK12811.jpn-sun4.operator.net@[127.0.0.1]> for <user40099@operator.net>; Wed, 24 May 2000 17:40:30 +0900 From: from@operator.net Reply-To: replyto@operator.net To: to@operator.net Cc: cc@operator.net Subject: sub Message-Id: <20000524084030.AAK12811.jpn-sun4.operator.net@[127.0.0.1]> Date: Wed, 24 May 2000 17:41:35 +0900

UID2:1001
Return-Path: <> Received: from [127.0.0.1] by jpn-sun4.operator.net (InterMail vM.5.01.00.00 201-249-103-102-20000402) with SMTP id <20000524084301.AAL12811.jpn-sun4.operator.net@[127.0.0.1]> for <user40099@operator.net>; Wed, 24 May 2000 17:43:01 +0900 From: f@operator.net To: t@operator.net Cc: "Cc desu" <cc@operator.net> Message-Id: <20000524084301.AAL12811.jpn-sun4.operator.net@[127.0.0.1]> Date: Wed, 24 May 2000 17:44:10 +0900

A long line is folded by using / (forward slash) for convenience in writing. signifies a line break. Example 1: Obtaining header part. No isolated parts. Specifying UID separated by commas. UID specification order is not fixed (descending order).

c: FECH 1001,1000 Xha s: (1000 {152} \ Date: Wed, 24 May 2000 17:41:35 +0900 \ From: from@operator.net \ Reply-To: replyto@operator.net \ Subject: sub__To: to@operator.net \ Cc: cc@operator.net(\ )(\ (1001 {114} (\ Date: Wed, 24 May 2000 17:44:10 +0900(\ From: f@operator.net(\ To: t@operator.net(\

43

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Cc: "Cc desu" <cc@operator.net>(\ )(\ OK( Example 2: Obtaining header part. Isolated part specification. Specifying UID range. Failed to obtain some UIDs (1002).

c: FECH 1000:1002 xHA<0.51> s: (1000 {51} \ Date: Wed, 24 May 2000 17:41:35 +0900 \ From: from@operator.net \ ) \ (1001 {51} \ Date: Wed, 24 May 2000 17:44:10 +0900 \ From: f@operator.net \ ) \ (1002) \ OK

4.6
4.6.1

STOR (Flag Setting)


Format

STOR <UID list> [xS|xH|sD|sR] xS = -flags (\Seen) Remove the \Seen flags from the messages specified by the given UIDs. In effect, change the state of the messages to unread. xH = -flags (\Seen \HeaderSeen) Remove the \Seen and \HeaderSeen flags from the messages specified by the given UIDs. In effect, change them to unread state, except for Receiving header only. Return value when successful: OK Error return value: BAD BYE

4.6.2

Operation

Change the flags of specified UID messages. Send back OK in the following cases:

44

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

When the flags of specified UIDs are successfully changed When a nonexistent UID is included in the specified UIDs and flags of UIDs other than the UID that could be changed When none of the specified UIDs exist When the specified UID flag has been already set, but the same flag is set again When the specified UID flag has been already reset, but the same flag is reset again

4.6.3
(1) BAD -

Error cases

When an argument is incorrect (insufficient arguments or incorrect character strings, etc.) When a command character string is incorrect In a state other than the Select state When an internal system connection (for example, to the message store) cannot be established (for instance, when the server is down) A server throws away this message and drops the connection immediately (panic shut-down notification)

(2) BYE

4.7
4.7.1

DELV (Delivery)
Format

DELV <transmission format> [<UID> [<part>]] FROM {<n>} <from> TO {<n>} <to> CC {<n>} <cc> BCC {<n>} <bcc> SUBJECT {<n>} <subject> REPLY-TO {<n>} <reply-to> CONTENT-TYPE {<n>} <content-type> CONTENT-TRANSFER-ENCODING {<n>} <transfer-encoding> MSG {<n>} <message text> <transmission format>

45

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

N: New message R: Reply message F: Forwarded message The <transmission format>, MSG, and at least one addressing parameter are required; all other parameters are optional. One or more addresses may be specified in the TO, CC, and BCC fields. The <transmission format> determines the basic format of the outgoing message. M-IMAP server implementations should support a configuration message template for each format, allowing the operator control over message formatting. The <UID> <part> parameters are used only for Reply and Forward formats. <from> <to> <cc> <bcc>: Specify the sender, destination, carbon copy and blind carbon copy addresses. It includes the MIME-encoded nickname. Formats of addresses and nicknames conform to RFC 822. <n>: Specify number of characters of the following parameter Parameter partCount the number of characters in parts excluding the space following each parameter identifier: (FROM, TO, CC, BCC, SUBJECT, REPLY-TO, CONTENT-TRANSFERENCODING, CONTENT-TYPE) Example: TO {32} nick name <hanako@operator.net> Count the number of characters in parts excluding the blank lines that separate the header from the text of an RFC822 message. Example) MSG {23} Is this a test message? CONTENT-TYPE and MSG: If the CONTENT-TYPE parameter is given on the DELV command, then the MSG parameter shall be used as the message body, without message headers. However, if the CONTENT-TYPE parameter is not given, or empty, then the value of the MSG parameter may contain message headers, followed by a blank line (i.e., <CR><LF>), followed by the message body. In the latter case, if a multipart type or a type other than text is included in the message body, at least one of the headers shall be a Content-type: with an appropriate value. Return value when successful: OK Error return value: BAD

46

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

4.7.2

Operation

Submit a message for delivery. The M-IMAP server creates an SMTP envelope, header and text by using the command arguments, and message body, and sends them to an SMTP server. Each paramater value is preceded by the number of octects that comprise the value. The DELV command has parameters that allow the specification of the message envelope and header. In particular, the FROM parameter value is used for the corresponding SMTP FROM command, as well as the From: message header. Similarly, the TO, CC, and BCC parameter values are used for addressing recipients and to compose the corresponding RFC822 message headers: To:, Cc:, and Bcc:, respectively. If the CONTENT-TYPE command parameter is not given, or has an empty value, then the MSG parameter may contain message headers, followed by a blank line (<CF><LF>), followed by the message body. If the message body is a MIME object, then the message headers must include Content-type: with an appropriate value. After receiving the DELV command parameters, including the MSG text, and then successfully parsing them to create an envelope and message header, an OK is sent back to the Mobile Station. This may occur before the outgoing message has been transmitted to the SMTP server. When an M-IMAP server cannot respond because the connection with the Mobile Station has already been dropped, the M-IMAP server creates an error message and delivers it to the senders mailbox. The M-IMAP server creates a new, outgoing message using the message parameters, possibly including one or more messages (referenced by UID) as attachments, and transmits it to an SMTP server. Addressing errors in the outgoing message are reported with a bounce message, as is typical for SMTP submission errors. The transmission formats for each message are as follows:
Message format Envelope Message header MAIL FROM RCPT TO From: To: Cc: Reply-To: When creating a new When replying message Argument FROM Address Argument TO/CC/BCC Address Argument FROM Address Argument TO Address Argument CC Address Argument REPLY-TO Address When forwarding

47

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Subject: Content-Type:

Content-TransferEncoding: Separator Ex-message header Server side additional information

Argument CONTENT-TYPE or multipart/Mixed; Argument CONTENT-TRANSFER-ENCODING 16 consecutive - No 16 consecutive - Date: From: To: Cc: Subject: No beginning quotation mark Yes

Argument SUBJECT Address Argument CONTENT-TYPE

Ex-message text Ex-message attachment file

Beginning quotation mark No

For a forwarded message, follow the regulations below for the Content-Type:
Argument CONTENT-TYPE text/plain; Multipart/Mixed; text/plain;(as it is) Multipart/Mixed;(as it is) Multipart/Mixed;(rewriting) Multipart/Mixed;(as it is)

No ex-message attachment Ex-message attachment

Prior to sending a message to the SMTP server, the M-IMAP server shall generate and insert as appropriate the Message-ID, Date and Return-Path header fields as appropriate into the message header.

4.7.3
(1) NO -

Error cases

When the envelope information is incorrect The Mail address of the log-in ID is different from the value given in the FROM parameter

(2) BAD When the arguments to create an envelope are insufficient When the FROM parameter does not exist When none of the TO/CC/BCC parameters exist When the Address format is incorrect

48

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

When an argument is incorrect (insufficient arguments or incorrect character strings, etc.) When the command character string is incorrect In the case of a Non Auth state For internal system and network errors (e.g., when the mail cannot be written or transmitted to the SMTP server)

(3) BYE

(4) Error mail The user is notified of an error that occurs after sending back OK (argument parsing succeeded) to a command from a Mobile Station in the form of an error mail. The following are the types of error mail. When original messages are acquired from MSS The M-IMAP Server creates the following error mail and sends it to the user. Error mail may be set at a system-wide scale.
Subject: Message Send Error From: SYSTEM To: <FROM or REPLY-TO address of the user> The message to <TO><CC><BCC> could not be sent at <Time and Date> because of an error

When the TO address is incorrect The SMTP server creates an error mail and sends it to the user

(5) Others The M-IMAP server retries to establish a connection to an SMTP server. When the destination SMTP server is not available, the M-IMAP server periodically retries to connect.

4.7.4

Examples

A long line is folded by using / for convenience in writing. The shaded parts are the parts that the server added or processed. (1) New messages (No attachment in the Mobile Station side)

49

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

c: DELV N FROM {29} Sender <sender@operator.net> \ TO {25} Prime <to1@operator.net> \ BCC {46} Secret <bcc1@operator.net>,\ bcc2@operator2.net \ SUBJECT {34} =?iso-2022-jp?B?GyRCJUYlOSVIGyhC?= \ CONTENT-TYPE {47} Content-Type: text/plain;\ charset="iso-2022-jp"\ CONTENT-TRANSFER-ENCODING {4} 7bit\ MSG {23} This is a plain message s: OK A transmission message to the SMTP server is as follows Envelope
MAIL RCPT RCPT RCPT FROM: sender@operator.net TO: to1@operator.net TO: bcc1@operator.net TO: bcc2@operator2.net

Text
From: Sender <sender@operator.net> To: Prime <to1@operator.net> Subject: =?iso-2022-jp?B?GyRCJUYlOSVIGyhC?= Content-Type: text/plain;charset=iso-2022-jp Content-Transfer-Encoding: 7bit This is a plain message

(2) New messages (With attachment on the Mobile Station side)


c: DELV N FROM {29} Sender <sender@operator.net> \ TO {25} Prime <to1@operator.net > \ BCC {46} Secret <bcc1@operator.net>, bcc2@operator2.net \ SUBJECT {34} =?iso-2022-jp?B?GyRCJUYlOSVIGyhC?= \ CONTENT-TYPE {68} multipart/mixed;boundary=\ "----=_NextPart_000_00C1_01BFC725.4B420B00" \ MSG {688} \ ------=_NextPart_000_00C1_01BFC725.4B420B00 \ Content-Type: text/plain;charset="iso-2022-jp" \ Content-Transfer-Encoding: 7bit \ \ $BK\J8 (B \ \ ------=_NextPart_000_00C1_01BFC725.4B420B00 \ Content-Type: application/octet-stream;name="=?iso\ -2022-jp?B?UFBUUBskQiRYJE4lNyVnITwlSCUrJUMlSBsoQi5\ sbms=?=" \ Content-Transfer-Encoding: base64 \ Content-Disposition: attachment;filename="=?iso-20\ 22-jp?B?UFBUUBskQiRYJE4lNyVnITw lSCUrJUMlSBsoQi5sb\ ms=?=" \ \ TAAAAAEUAgAAAAAAwAAAAAAAAEYBAAAAAAAAAAAAAAAAAAAAAA\ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAA\ AD8AFAAfD+BP0CDqOmkQotgIACswMJ0UAC4AoP8smVf1GhCI7A\

50

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

DdAQzMSBUAAAAAAAAAZQAAAAAAAABQUFRQAAAAAAAAAA== \ \ ------=_NextPart_000_00C1_01BFC725.4B420B00-s: OK

A transmission message to the SMTP server is as follows Envelope


MAIL RCPT RCPT RCPT FROM: sender@operator.net TO: to1@operator.net TO: bcc1@operator.net TO: bcc2@operator2.net

Text
From: Sender <sender@operator.net> To: Prime <to1@operator.net> Subject: =?iso-2022-jp?B?GyRCJUYlOSVIGyhC?= Content-Type: multipart/mixed; boundary="----=_NextPart_000_00C1_01BFC725.4B420B00" ------=_NextPart_000_00C1_01BFC725.4B420B00 Content-Type: text/plain;charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $BK\J8 (B ------=_NextPart_000_00C1_01BFC725.4B420B00 Content-Type: application/octet-stream; name="=?iso-2022-jp?B?UFBUUBskQiRYJE4lNyVnITwlSCUrJUMlSBsoQi5sbms=?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?iso-2022-jp?B?UFBUUBskQiRYJE4lNyVnITwlSCUrJUMlSBsoQi5sbms =?=" TAAAAAEUAgAAAAAAwAAAAAAAAEYBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAQAAAAAAAAAAAAAAAAAAAD8AFAAfD+BP0CDqOmkQotgIACswMJ0UAC4AoP8smVf1GhCI7ADdAQzM SBUAAAAAAAAAZQAAAAAAAABQUFRQAAAAAAAAAA== ------=_NextPart_000_00C1_01BFC725.4B420B00--

(3) Reply messages (No attachment in the Mobile Station side) c: DELV R 3322 FROM {29} Sender <sender@operator.net> \ TO {25} Prime <to1@ operator.net> \ BCC {46} Secret <bcc1@ operator.net>, bcc2@operator2.net \ SUBJECT {34} =?iso-2022-jp?B?GyRCJUYlOSVIGyhC?= \ CONTENT-TYPE {47} Content-Type: text/plain;\ charset="iso-2022-jp"\ CONTENT-TRANSFER-ENCODING {4} 7bit\ MSG {23} This is a plain message s: OK A sample message submission to an SMTP server is as follows:

51

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Envelope
MAIL RCPT RCPT RCPT FROM: sender@operator.net TO: to1@operator.net TO: bcc1@operator.net TO: bcc2@operator2.net

Text
From: Sender <sender@operator.net> To: Prime <to1@operator.net> Subject: =?iso-2022-jp?B?GyRCJUYlOSVIGyhC?= Content-Type: text/plain;charset=iso-2022-jp Content-Transfer-Encoding: 7bit This is a plain message ---------------> This is the original message. > Message UID is #3322 stored in a mailbox

(4) Forwarded messages (No attachment in the Mobile Station sideWith original message attachment)
c: DELV F 3322 FROM {29} Sender <sender@operator.net> \ TO {25} Prime <to1@operator.net> \ BCC {46} Secret <bcc1@operator.net>, bcc2@operator2.net \ SUBJECT {34} =?iso-2022-jp?B?GyRCJUYlOSVIGyhC?= \ CONTENT-TYPE {47} Content-Type: text/plain;\ charset="iso-2022-jp"\ CONTENT-TRANSFER-ENCODING {4} 7bit\ MSG {23} This is a plain message s: OK

A sample message submission is as follows Envelope


MAIL RCPT RCPT RCPT FROM: sender@operator.net TO: to1@operator.net TO: bcc1@operator.net TO: bcc2@operator2.net

Text
From: Sender <sender@operator.net> To: Prime <to1@operator.net> Subject: =?iso-2022-jp?B?GyRCJUYlOSVIGyhC?= Content-Type: multipart/mixed; boundary="----=_NextPart_000_00C1_01BFC725.4B420B01" ------=_NextPart_000_00C1_01BFC725.4B420B01 Content-Type: text/plain;charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $BK\J8 (B ---------------Date: Wed, 24 May 2000 17:44:10 +0900 From: origin@operator3.net To: sender@operator.net

52

MMS MM1 Stage 3 Using M-IMAP Subject: forward test


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

X.S0016-311 v1.0

This is the original message. Message UID is #3322 stored in some MSS ------=_NextPart_000_00C1_01BFC725.4B420B01 Content-Type: image/jpeg; name="Dsc00003.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment;filename="Dsc00003.jpg" TAAAAAEUAgAAAAAAwAAAAAAAAEYBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAQAAAAAAAAAAAAAAAAAAAD8AFAAfD+BP0CDqOmkQotgIACswMJ0UAC4AoP8smVf1GhCI 7ADdAQzMSBUAAAAAAAAAZQAAAAAAAABQUFRQAAAAAAAAAA== ------=_NextPart_000_00C1_01BFC725.4B420B01--

(5) Forwarded messages (With attachment in the Mobile Station side. With original message attachment)
c: DELV F FROM {29} Sender <sender@operator.net> \ TO {25} Prime <to1@operator.net> \ BCC {46} Secret <bcc1@operator.net>, bcc2@operator2.net \ SUBJECT {34} =?iso-2022-jp?B?GyRCJUYlOSVIGyhC?= \ CONTENT-TYPE {68} multipart/mixed;boundary=\ "----=_NextPart_000_00C1_01BFC725.4B420B00" \ MSG {688} \ ------=_NextPart_000_00C1_01BFC725.4B420B00 \ Content-Type: text/plain;charset="iso-2022-jp" \ Content-Transfer-Encoding: 7bit \ \ $BK\J8 (B \ \ ------=_NextPart_000_00C1_01BFC725.4B420B00 \ Content-Type: application/octet-stream;name="=?iso\ -2022-jp?B?UFBUUBskQiRYJE4lNyVnITwlSCUrJUMlSBsoQi5\ sbms=?=" \ Content-Transfer-Encoding: base64 \ Content-Disposition: attachment;filename="=?iso-20\ 22-jp?B?UFBUUBskQiRYJE4lNyVnITw lSCUrJUMlSBsoQi5sb\ ms=?=" \ \ TAAAAAEUAgAAAAAAwAAAAAAAAEYBAAAAAAAAAAAAAAAAAAAAAA\ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAA\ AD8AFAAfD+BP0CDqOmkQotgIACswMJ0UAC4AoP8smVf1GhCI7A\ DdAQzMSBUAAAAAAAAAZQAAAAAAAABQUFRQAAAAAAAAAA== \ \ ------=_NextPart_000_00C1_01BFC725.4B420B00-s: OK

A sample message submission is as follows Envelope


MAIL FROM: sender@operator.net RCPT TO: to1@operator.net

53

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

RCPT TO: bcc1@operator.net RCPT TO: bcc2@operator2.net

Text
From: Sender <sender@operator.net> To: Prime <to1@operator.net> Subject: =?iso-2022-jp?B?GyRCJUYlOSVIGyhC?= Content-Type: multipart/mixed; boundary="----=_NextPart_000_00C1_01BFC725.4B420B00" ------=_NextPart_000_00C1_01BFC725.4B420B00 Content-Type: text/plain;charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $BK\J8 (B ---------------Date: Wed, 24 May 2000 17:44:10 +0900 From: origin@operator3.net To: sender@operator.net Subject: forward test This is the original message. Message UID is #3322 stored in some MSS ------=_NextPart_000_00C1_01BFC725.4B420B00 Content-Type: image/jpeg; name="Dsc00003.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment;filename="Dsc00003.jpg" TAAAAAEUAgAAAAAAwAAAAAAAAEYBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAQAAAAAAAAAAAAAAAAAAAD8AFAAfD+BP0CDqOmkQotgIACswMJ0UAC4AoP8smVf1GhCI 7ADdAQzMSBUAAAAAAAAAZQAAAAAAAABQUFRQAAAAAAAAAA== ------=_NextPart_000_00C1_01BFC725.4B420B00 Content-Type: application/octet-stream; name="=?iso-2022-jp?B?UFBUUBskQiRYJE4lNyVnITwlSCUrJUMlSBsoQi5sbms= ?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?iso-2022-jp?B?UFBUUBskQiRYJE4lNyVnITwlSCUrJUMlSBsoQi5s bms=?=" TAAAAAEUAgAAAAAAwAAAAAAAAEYBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAQAAAAAAAAAAAAAAAAAAAD8AFAAfD+BP0CDqOmkQotgIACswMJ0UAC4AoP8smVf1GhCI 7ADdAQzMSBUAAAAAAAAAZQAAAAAAAABQUFRQAAAAAAAAAA== ------=_NextPart_000_00C1_01BFC725.4B420B00--

(6) Example with Content-type in the MSG parameter:

54

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

C: DELV N TO {x} yournai FROM {xx} mynai SUBJECT {xx} An MMS message! MSG {xx} X-MMS-MM1-Version: M-IMAP-1.0 X-MMS-Report-reply: yes X-MMS-Transaction-Id: 12345 Content-type: application/vnd.wap.mms-message, boundary=----abcdef---- ------abcdef---Content-type: text/plain This is an MMS message. ------abcdef---Content-type: image/png Content-encoding: base64 [picture encoding] ------abcdef-----S: OK

4.8
4.8.1

DELT (Delete)
format
OK<CR><LF>

DELT <UID list> Return value when successful: Error return value:

BAD<CR><LF> BYE<CR><LF>

4.8.2

Operation

Erase the messages of the specified UIDs from the mailbox. Attach a \Delete flag to each message and delete it later (carry out the process applicable to the Expunge command of the regular IMAP command). Send back OK in the following cases: When all the specified UIDs could be deleted. When the nonexistent UID is included in the specified UIDs, and messages of UIDs other than that the UID could be deleted

55

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

When none of the specified UIDs exist

4.8.3
(1) BAD -

Error cases

A state other than the Select state A connection with MSS cannot be established

(2) BYE The server discards this message and drops the connection immediately (panic shut-down notification)

4.9
4.9.1
LOUT

LOUT (Log Out)


Format

Return value when successful: OK<CR><LF> Error return value: BAD<CR><LF>

4.9.2

Operation

Perform the logout process. When an M-IMAP server receives a logout command, it responds with OK. After that, the connection to the Mobile Station is dropped.

4.9.3
(1) BAD -

Error cases

When an argument is incorrect (insufficient arguments or incorrect character strings, etc.) When the command character string is incorrect

56

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Appendix A
Command Normal finish AUTH Number of new messages <CR><LF> OK <CR><LF>

List of Command Replies


Process failure NO<CR><LF> - Access denied Process unknown BAD<CR><LF> - Incorrect argument - Incorrect command character string - State mismatch BAD<CR><LF> - Incorrect argument - Incorrect command character string - State mismatch BAD<CR><LF> - Incorrect argument - Incorrect command character string - State mismatch BAD<CR><LF> - Incorrect argument - Incorrect command character string - State mismatch BAD<CR><LF> - Envelope creation failed - Incorrect argument - Incorrect command character string - State mismatch BAD<CR><LF> - Incorrect argument - Incorrect command character string - State mismatch Disconnection BYE<CR><LF> - MSS down - DIR down

SACH

[<uid> ]* <CR><LF> OK <CR><LF>

None

BYE<CR><LF> - MSS down

FECH

[(UID data) <CR><LF>]* OK <CR><LF>

None

BYE<CR><LF> - MSS down

STOR

OK<CR><LF>

None

BYE<CR><LF> - MSS down

DELV

OK [ID=msgid] <CR><LF>

NO<CR><LF> - Incorrect envelope semantics

BYE<CR><LF> - Storage in spool failed

DELT

OK<CR><LF>

None

BYE<CR><LF> - MSS down

57

X.S0016-311 v1.0

MMS MM1 Stage 3 Using M-IMAP


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Command Normal finish LOUT OK<CR><LF> - Disconnection

Process failure None

Process unknown BAD<CR><LF> - Incorrect argument - Incorrect command character string - State mismatch

Disconnection None

58

MMS MM1 Stage 3 Using M-IMAP

X.S0016-311 v1.0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Appendix B

Syntax Specifications

M-IMAP commands are described in BNF (using classic BNF rules including implicit white space) notation. For tokens without notation, see [IMAP4 [RFC3501]]. authenticate search store delivery fetch message delete logout auth_type fetch_flag fetch_option search_key search_flags store_att_flags message_format delivery_option from_field to_field cc_field bcc_field subject_field reply-to_field content-type_field content-transferencoding_field message_field AUTH auth_type userid SACH search_key STOR set store_att_flags DELV from_field to_field cc_field bcc_field subject_field reply-to_field content-type_field content-transfer-encoding_field message_field FECH set fetch_flag fetch_option DELT set LOUT S | R xHP | xHA | xHO | xB section | section [< number . nz_number >] | nil search_flags | uid xR | xU | xS | xH | xN xS | xH N | F | R uid | uid section | nil FROM { number } addr_name TO { number }addr_name | nil CC { number } addr_name | nil BCC { number } addr_name | nil SUBEJCT { number } string | nil REPLY-TO { number } addr_name | nil CONTENT-TYPE { number } string | nil CONTENT-TRANSFER-ENCODING { number } string | nil MSG { number } string | nil

59