spec mm1 3gpp

i

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 [email protected]. 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

ii

Revision History

Revision Date

Rev. 0 Initial Publication May 2003

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

i

1 CONTENTS 1 Introduction ..........................................................................................................................................................1

1.1 Scope .............................................................................................................................................................1 1.2 References.....................................................................................................................................................1 1.3 Terminology .................................................................................................................................................4 1.4 Assumptions .................................................................................................................................................5 1.5 Definitions ....................................................................................................................................................5 1.6 Abbreviations ...............................................................................................................................................5

2 Stage 2 Amendments (Normative)........................................................................................................................6 3 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


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

ii

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 Sample Application (Informative)............................................................................................................31 4 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


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

iii

4.9.3 Error cases ...........................................................................................................................................56 Appendix A List of Command Replies...............................................................................................................57 Appendix B Syntax Specifications......................................................................................................................59


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

iv

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


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 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 References

3GPP2

[S.R0064-0] Multimedia Messaging Services (MMS) Stage 1 Requirements, October 2002, 3GPP2. http://www.3gpp2.org/Public_html/specs/S.R0064-0_v1.0.pdf

[MMS_OV] X.S0016-000-A/TIA-934-000-A, Multimedia Messaging Services (MMS) Specification Overview, May 2003, 3GPP2.

[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.

[SMS] C.S0015-A: Short Message Service (SMS), December 1999, 3GPP2. http://www.3gpp2.org/Public_html/specs/CS0015-0.pdf


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

2

IETF

[RFC1731] RFC 1731, IMAP4 Authentication Mechanisms, December 1994, IETF. http://www.ietf.org/rfc/rfc1731

[RFC1893] RFC 1893, Enhanced Mail system Status Codes, January 1992, IETF. http://www.ietf.org/rfc/rfc1893

[RFC1894] RFC 1894, An Extensible Message Format for Delivery Status Notifications, January 1966, IETF. http://www.ietf.org/rfc/rfc1894

[RFC2045] RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies; IETF. http://www.ietf.org/rfc/rfc2045

[RFC2046] RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types; IETF. http://www.ietf.org/rfc/rfc2046

[RFC2047] RFC 2047, Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text, IETF. http://www.ietf.org/rfc/rfc2047

[RFC2076] RFC 2076, Common Internet Message Headers, Feb 1997, IETF. http://www.ietf.org/rfc/rfc2076

[RFC2088] RFC 2088, IMAP4 non-synchronizing literals, January 1997, IETF. http://www.ietf.org/rfc/rfc2088

[RFC2192] RFC 2192, IMAP URL Scheme, September 1997, IETF. http://www.ietf.org/rfc/rfc2192

[RFC2195] RFC 2195, IMAP/POP AUTHorize Extension for Simple Challenge/Response, September 1997, IETF. http://www.ietf.org/rfc/rfc2195

[RFC2246] RFC 2246, The TLS Protocol Version 1.0, IETF. http://www.faqs.org/rfcs/rfc2246

[RFC2298] RFC 2289, An Extensible Message Format for Message Disposition Notifications, March 1998, IETF. http://www.ietf.org/rfc/rfc2298


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

[RFC2342] RFC 2342, IMAP4 Namespace, May 1998, IETF. http://www.ietf.org/rfc/rfc2342

[RFC2359] RFC 2359, IMAP4 UIDPLUS extension, June 1998, IETF. http://www.ietf.org/rfc/rfc2359

[RFC2387] RFC 2387, The MIME Multipart/Related Content-type, IETF. http://www.ietf.org/rfc/rfc2387

[RFC2444] RFC 2444, The One-Time-Password SASL Mechanism, October 1998, IETF. http://www.ietf.org/rfc/rfc2444

[RFC2595] RFC 2595, Using TLS with IMAP, POP3 and ACAP, June 1999, IETF. http://www.ietf.org/rfc/rfc2595

[RFC2632] RFC 2632, S/MIME Version 3 Certificate Handling, June 1999, IETF. http://www.ietf.org/rfc/rfc2632

[RFC2633] RFC 2633, S/MIME Version 3 Message Specification, June 1999, IETF. http://www.ietf.org/rfc/rfc2633

[RFC2634] RFC 2634, Enhanced Security Services for S/MIME, June 1999, IETF. http://www.ietf.org/rfc/rfc2634

[RFC2821] RFC 2821, Simple Message Transport Protocol, April 2002, IETF. http://www.faqs.org/rfcs/rfc2821

[RFC2822] RFC 2822, Internet Message Format, April 2002, IETF. http://www.faqs.org/rfcs/rfc2822

[RFC3156] RFC 3156, MIME Security with OpenPGP, August 2001, IETF. http://www.ietf.org/rfc/rfc3156

[RFC3501] RFC 3501, IMAP4, Internet Message Access Protocol Version 4 rev1, March 2003, IETF. http://www.ietf.org/rfc/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&lang=e&parent=T-REC-E.164


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

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-238-WML-20010911-a.pdf

[WAP250] WAP-250-PushArchOverview-20010703-a, Push Architectural Overview, OMA. http://www1.wapforum.org/tech/documents/WAP-250-PushArchOverview-20010703-a.pdf

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

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

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.

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 “↵ ”.


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

5

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 Definitions

None

1.6 Abbreviations

The following abbreviations are used within this document:

C Client (used in sample sessions) DSN Delivery Status Notification [RFC1894] HTTP Hypertext Transfer Protocol IETF Internet Engineering Task Force IMAP4 Internet Message Access Protocol, version 4 MDN Mobile Directory Number or Message Disposition Notification

[RFC2298], depending upon context M-IMAP Mobile IMAP MIME Multipurpose Internet Mail Extensions MM Multimedia Message MMS Multimedia Messaging Service MSG Message OMA Open Mobile Alliance POP3 Post Office Protocol Version 3 RFC Request for Comments S Server (used in sample sessions) SIP Session Initiation Protocol SMS Short Message Service SMTP Simple Mail Transfer Protocol TCP Transmission Communications Protocol TLS Transport Layer Security UA User Agent UAProf User Agent Profile UID User Identification (ID) (see [RFC3501])


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

6

URI Uniform Resource Identifier URL Uniform Resource Locator W3C WWW Consortium WAP Wireless Application Protocol WML Wireless Markup Language

2 Stage 2 Amendments (Normative) None.

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

3.1 Introduction (Informative) 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 TIA-934/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

7

Figure 1 - Abstract Transaction Call Flows

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

MM4_delivery_report.RES MM1 Delivery report.REQ MM1_Read_reply_

report recipient.REQ MM4_read_reply.REQ

MM4_read_reply.RES MM1 Read_reply_

report_originator.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. M-IMAP 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.


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

8

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: AUTH S MYNAI S: OK C: DELV N command parameters MSG message-text S: 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}↵ [email protected]↵ 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


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

9

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.


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

10

MM1_Notification.REQ with IMAP <UID>

OK

MMS UA

MM1_notification.REQ

MM1_retrieve.REQ M-IMAP FECH <UID>

M-IMAP DELV N (notification response)

MM1_retrieve.RES

MM1_notification.RESOK

MMS Relay/Server

Figure 2 - Notification and Immediate Retrieval of Multimedia Message

MMS UAMMS Relay/

Server

MM1_notification.REQ

MM1_retrieve.REQ

MM1_retrieve.RES

MM1_ acknowledgement.REQ

Time Passes

M-IMAP DELV N Notification response

MM1_notification.RES OK

M-IMAP DELV N Acknowledgement

OK

MM1_Notification.REQ w/IMAP <UID>

M-IMAP FECH <UID>

msg & OK

Figure 3 - Notification and Delayed Retrieval of Multimedia Message


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

11

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 M-IMAP 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


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

12

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.


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

13

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 Title Status

[RFC3501] INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1

M

[RFC2595] Using TLS with IMAP, POP3 and ACAP R [RFC2195] IMAP/POP AUTHorize Extension for

Simple Challenge/Response R

[RFC1731] IMAP4 Authentication Mechanisms R [RFC2342] IMAP4 Namespace R [RFC2359] IMAP4 UIDPLUS extension R [RFC2088] IMAP4 non-synchronizing literals 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.


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

14

Figure 4 - Forwarding without prior retrieval of Multimedia Message

OK

MMS UAMMS Relay/

Server

MM1_forward.REQM-IMAP DELV F UID

MM1_forward.RES

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.


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

15

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 originator’s 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.


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

16

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 originator’s 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’.


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

17

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

Message Body

presentation

image/jpeg

text/plain

audio/wav

Start

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.


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

18

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".


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

19

Table 2 - Security related RFCs

Security-related RFCs Title Status

[RFC2595] Using TLS with IMAP, POP3 and ACAP R

[RFC2195] IMAP/POP AUTHorize Extension for Simple Challenge/Response R

[RFC1731] IMAP4 Authentication Mechanisms R [RFC2632] S/MIME Version 3 Certificate Handling R [RFC2633] S/MIME Version 3 Message Specification R [RFC2634] Enhanced Security Services for S/MIME R [RFC3156] MIME Security with OpenPGP R [RFC2444] The One-Time-Password SASL Mechanism R [RFC2246] The TLS Protocol 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 Mapping Direction MM1_submit.REQ M-IMAP DELV N Command MMS UA -> MMS Relay/Server MM1_submit.RES M-IMAP DELV N Command MMS Relay/Server -> MMS UA

Table 4 - Mapping of MM1 Notification abstract messages

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

Table 5 - Mapping MM1 Retrieve abstract messages

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


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

20

Table 6 - Mapping of MM1 Forward abstract messages

Abstract messages Mapping Direction MM1_forward.REQ M-IMAP DELV F Command MMS UA -> MMS Relay/Server MM1_forward.RES M-IMAP DELV F Command MMS Relay/Server -> MMS UA

Table 7 - Mapping of MM1 Delivery Report abstract messages

Abstract Message Mapping Direction MM1_delivery_report.REQ Normal message notification

and retrieval using DSNs [RFC1894]

MMS Relay/Server -> MMS UA

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

Abstract messages Mapping Direction MM1_read_report_recipient.REQ M-IMAP DELV N Command MMS UA -> MMS

Relay/Server MM1_read_report_originator.REQ Normal message notification

and retrieval using MDNs [RFC2298]

MMS Relay/Server -> MMS UA

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.mms-message”. 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”).


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

21

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 Type MM1_submit.REQ Headers MMS MM1 Version M X-Mms-MM1-Version: Message Type M X-Mms-MM1-Message-Type: Transaction ID M X-Mms-Transaction-ID: Message ID M X-Mms-Message-ID: Recipient(s) address M One or more of: To:, Cc:, Bcc: Content type M Content-Type: Sender address O From: Message class O X-Mms-Message-Class: Date and time O Date: Time of Expiry O X-Mms-Expiry: Earliest delivery time O X-Mms-Delivery-Time: Delivery report O X-Mms-Delivery-Report: Reply-Charging O X-Mms-Reply-Charging: Reply-Charging-size O X-Mms-Reply-Charging-size: Reply-Deadline O X-Mms-Reply-Deadline: Priority O X-Mms-Priority: Sender visibility O X-Mms-Sender-Visibility: Read reply O X-Mms-Read-Reply: Subject O Subject: Reply-Charging-ID O X-Mms-Reply-Charging-ID: Content O <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.


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

22

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 Type Submit.RES Headers Message Type M X-MMS-Message-type: MM1_submit.RES Transaction ID M X-MMS-Transaction-Id MMS Version M X-MMS-Version Request Status M X-MMS-Request-Status: Request Status Text O X-MMS-Request-Status-text: Message ID C 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:


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

23

Table 11 - MM1_notification.REQ Information Elements to Header Mappings

Information element Type MM1_Notification.REQ Headers Message Type M X-MMS-Message-type: MM1_notification.REQ Transaction ID M X-MMS-Transaction-ID: MMS Version M X-MMS-Version: Message class M X-MMS-Message-class: Message size M X-MMS-Message-size: Time of expiry M X-MMS-Expiry: Message Reference M X-MMS-Message-Ref: IMAP URL with UID

[RFC2192] Subject O Subject: Priority O X-MMS-Priority: Sender address C From: Delivery report O X-MMS-Delivery-Report: Reply-Charging O X-MMS-Reply-Charging: Reply-Deadline O X-MMS-Reply-Deadline: Reply-Charging-Size O X-MMS-Reply-Charging-Size: Reply-Charging-ID O X-MMS-Reply-Charging-ID: Element-Descriptor O X-MMS-Element-Ref: Message Distribution Indicator O 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

Type MM1_notification.RES Headers

Message Type M X-MMS-Message-Type: MM1_notification.RES Transaction ID M X-MMS-Transaction-Id: MMS Version M X-MMS-Version: MM Status M X-MMS-Status: [Retrieved | Rejected | Deferred | Unrecognized] Report allowed O 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:


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

24

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

Information element Type M-IMAP DELV Parameters Message Reference M 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 Type MM1_retrieve.RES Headers MMS MM1 Version M X-Mms-MM1-Version: Transaction ID C (omitted – not needed for M-

IMAP) Message ID M X-Mms-Message-ID: Sender address C From: Content type M Content-Type: Recipient(s) address O To:, Cc:, Bcc: Message class O X-Mms-Message-Class: Date and time M Date: Delivery report C X-Mms-Delivery-Report: Priority C X-Mms-Priority: Read reply C X-Mms-Read-Reply: Subject C Subject: Request Status O X-MMS-Status: Request Status Text O X-MMS-Status-text: Reply-Charging O X-Mms-Reply-Charging: Reply-Charging-ID O X-Mms-Reply-Charging-ID: Reply-Charging-Size O X-Mms-Reply-Charging-Size: Reply-Deadline O X-Mms-Reply-Deadline: Forward_counter O X-Mms-Forward-Counter: Forwarded_by O Resent-From: Content C <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 M-IMAP DELV command with a message containing only MMS headers.


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

25

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

Information element Type Acknowledgement.REQ Headers Message Type M X-MMS-Message-Type:

MM1_acknowledgement.REQ Transaction ID C X-MMS-Transaction-Id: MMS Version M X-MMS-Version: Delivery Report allowed O X-MMS-Delivery-Report: [yes | no] Read-Reply Report allowed O 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 Type MM1_Forward.REQ Headers Message Type M X-MMS-Message-Type:

MM1_forward.REQ MMS MM1 Version M X-Mms-MM1-Version: Transaction ID M X-Mms-Transaction-ID: Recipient address M One or more of: Resent-To:, Resent-

Cc:, Resent-Bcc: Forwarding address O Resent-From: Date and time O Resent-Date: Time of Expiry O X-Mms-Expiry: Earliest delivery time O X-Mms-Delivery-Time: Delivery report O X-Mms-Delivery-Report: Read reply O X-Mms-Read-Reply: Message Reference M 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}↵


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

26

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 Type MM1_Forward.RES Headers Message Type M X-MMS-Message-type: MM1_forward.RES. Transaction ID M X-MMS-Transaction-Id: MMS Version M X-MMS-Version: Request Status M X-MMS-Status: Request Status Text O X-MMS-Status-text: Message ID M 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 Type MM1_Delivery_report.REQ Headers

MMS MM1 Version M X-Mms-MM1-Version: Message Type M X-MMS-MM1-Message-Type: MM Message ID M X-Mms-Message-ID: Recipient address M From: Date and time M Date: MM Status Code M X-Mms-MM-Status-Code: Status Text O 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.


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

27

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

Information element Type MM1_read_reply_recipient.REQ Headers

MMS MM1 Version M X-Mms-MM1-Version: Message Type M X-Mms-MM1-Message-Type: Recipient address M From: Originator address M To: Message-ID M X-Mms-Message-ID: Date and time O Date: MM Status Code M X-Mms-MM-Status-Code: Status text O 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 Type MM1_read_reply_originator.REQ Headers MMS MM1 Version M X-Mms-MM1-Version: Message Type M X-MMS-MM1-Message-Type:

MM1_read_reply_originator.REQ Recipient address M From: Originator address M To: Message-ID M X-Mms-Message-ID: Date and time M Date: MM Status Code M X-Mms-MM-Status-Code: Status text O 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.


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

28

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

Information element Type MM1_read_reply_recipient.REQ Headers MMS MM1 Version M X-Mms-MM1-Version: Message Type M X-MMS-MM1-Message-Type:

MM1_read_reply_recipient.REQ Recipient address M From: Originator address M To: Message-ID M X-Mms-Message-ID: Date and time M Date: MM Status Code M X-Mms-MM-Status-Code: Status text O 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”).


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

29

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 = "X-Mms-Message-Class" ":" ( Class-identifier | quoted-string )

Class-identifier = "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” )


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

30

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:


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

31

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 [email protected] 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 today’s 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.


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

32

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.


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

33

4 Mobile-IMAP Reference Specification (Normative)

4.1 Features

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 (“NO”・”BAD”) 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”.


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

34

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.


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

35

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 Log output timing Contents Commands other than DELV command

Same as the regular IMAP4 Server

Same as the regular IMAP4 Server

DELV Receiving command Message submission Message UID access SMTP session activity

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 M-IMAP 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):


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

36

NonAuth

Auth

Select

Logout

LOUT

TCP connection

AUTH R AUTH S

AUTH R

LOUT

FECHSACH STOR DELV DELT AUTH SAUTH R

DELV AUTH SFECH SACH

LOUT

Non Auth: The state after returning the greeting to the connection from the Mobile Station

Auth: 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).

Select: State where the mailbox is accessible in Read-Write after the user authentication is finished.

Logout: Logged out state. Just after this, the server drops the connection with the Mobile Station.

4.3 AUTH (Authentication)

4.3.1 Format AUTH <Login type> <LoginID>

<Login type>: S: Login for sending messages R: Login for receiving messages

<LoginID>: MSD | NAI

Return value when successful:

S-type login:

OK<CR><LF>

R-type login:

Number of incoming messages <CR><LF> OK<CR><LF>


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

37

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


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

38

4.3.3 Error cases (1) NO

- 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.

(2) BAD

- 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.

(3) BYE

- When a connection to the back-end system (MSS・directory 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 Example for logging in to receive mail

s: OK ; Greeting message c: AUTH R pochi ; Logging in with the user name pochi s: 2 ; There are two new messages in the inbox

4.4 SACH (Search)

4.4.1 Format SACH [<flag pattern>|<UID>]

<flag pattern>: xR： Recent (Incoming)

xU： Unseen (Unread)

xS： Seen (Read)

xH： Unseen and Header Seen (Receiving header only)

xN： Unseen and Header UnSeen (Unread except for the “Receiving header only”)


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

39

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 Recent Header Seen Seen xR ON Not checking Not checking xU Not checking Not checking OFF xS Not checking Not checking ON xH Not checking ON OFF xN Not checking 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 Error cases (1) BAD



- 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


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

40

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

4.5 FECH (Message Fetching)

4.5.1 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>


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

41

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:


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

42

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.



- 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)


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

43

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

4.5.4 Samples UID1:1000

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 <[email protected]>; Wed, 24 May 2000 17:40:30 +0900 From: [email protected] Reply-To: [email protected] To: [email protected] Cc: [email protected] 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 <[email protected]>; Wed, 24 May 2000 17:43:01 +0900 From: [email protected] To: [email protected] Cc: "Cc desu" <[email protected]> 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: [email protected]↵ \ Reply-To: [email protected]↵ \ Subject: sub__To: [email protected]↵ \ Cc: [email protected](\ )(\ (1001 {114} (\ Date: Wed, 24 May 2000 17:44:10 +0900(\ From: [email protected](\ To: [email protected](\


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

44

Cc: "Cc desu" <[email protected]>(\ )(\ 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: [email protected]↵ \ )↵ \ (1001 {51} ↵ \ Date: Wed, 24 May 2000 17:44:10 +0900↵ \ From: [email protected]↵ \ )↵ \ (1002)↵ \ OK↵

4.6 STOR (Flag Setting)

4.6.1 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:


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

45

• 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




- In a state other than the Select state (2) BYE

- 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)

4.7 DELV (Delivery)

4.7.1 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>


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

46

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 part：Count the number of characters in parts excluding the space following each parameter identifier:

(FROM, TO, CC, BCC, SUBJECT, REPLY-TO, CONTENT-TRANSFER-ENCODING, CONTENT-TYPE)

Example: …TO {32} “nick name” <[email protected]> …

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


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

47

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 sender’s 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 When creating

a new message

When replying When forwarding

MAIL FROM Argument FROM Address Envelope RCPT TO Argument TO/CC/BCC Address From: Argument FROM Address To: Argument TO Address Cc: Argument CC Address

Message header

Reply-To: Argument REPLY-TO Address


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

48

Subject: Argument SUBJECT Address Content-Type: Argument CONTENT-TYPE Argument

CONTENT-TYPE or multipart/Mixed;

Content-Transfer-Encoding:

Argument CONTENT-TRANSFER-ENCODING

Separator ― 16 consecutive “-“

16 consecutive “-“

Ex-message header

― No Date: From: To: Cc: Subject:

Ex-message text ― Beginning quotation mark

No beginning quotation mark

Server side additional

information

Ex-message attachment file

― No Yes

For a forwarded message, follow the regulations below for the Content-Type:

Argument CONTENT-TYPE text/plain; Multipart/Mixed;

No ex-message attachment text/plain;(as it is) Multipart/Mixed;(as it is) Ex-message attachment Multipart/Mixed;(rewriting) Multipart/Mixed;(as it is)

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 Error cases (1) NO

- 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


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

49



- In the case of a Non Auth state (3) BYE

- For internal system and network errors (e.g., when the mail cannot be written or transmitted to the SMTP server)

(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)


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

50

c: DELV N FROM {29} “Sender” <[email protected]> \ TO {25} “Prime” <[email protected]> \ BCC {46} “Secret” <[email protected]>,\ [email protected] \ 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 FROM: [email protected] RCPT TO: [email protected] RCPT TO: [email protected] RCPT TO: [email protected]

Text From: “Sender” <[email protected]> To: “Prime” <[email protected]> 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” <[email protected]> \ TO {25} “Prime” <[email protected] > \ BCC {46} “Secret” <[email protected]>, [email protected] \ 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\


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

51

DdAQzMSBUAAAAAAAAAZQAAAAAAAABQUFRQAAAAAAAAAA==↵ \ ↵ \ ------=_NextPart_000_00C1_01BFC725.4B420B00--

s: OK

A transmission message to the SMTP server is as follows：


Text From: “Sender” <[email protected]> To: “Prime” <[email protected]> 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 =?=" TAAAAAEUAgAAAAAAwAAAAAAAAEYBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAD8AFAAfD+BP0CDqOmkQotgIACswMJ0UAC4AoP8smVf1GhCI7ADdAQzMSBUAAAAAAAAAZQAAAAAAAABQUFRQAAAAAAAAAA== ------=_NextPart_000_00C1_01BFC725.4B420B00--

(3) Reply messages (No attachment in the Mobile Station side)

c: DELV R 3322 FROM {29} “Sender” <[email protected]> \ TO {25} “Prime” <to1@ operator.net> \ BCC {46} “Secret” <bcc1@ operator.net>, [email protected] \ 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:


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

52


Text From: “Sender” <[email protected]> To: “Prime” <[email protected]> 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 side・With original message attachment)

c: DELV F 3322 FROM {29} “Sender” <[email protected]> \ TO {25} “Prime” <[email protected]> \ BCC {46} “Secret” <[email protected]>, [email protected] \ 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：


Text From: “Sender” <[email protected]> To: “Prime” <[email protected]> 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: [email protected] To: [email protected]


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

53

Subject: forward test 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" TAAAAAEUAgAAAAAAwAAAAAAAAEYBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAD8AFAAfD+BP0CDqOmkQotgIACswMJ0UAC4AoP8smVf1GhCI7ADdAQzMSBUAAAAAAAAAZQAAAAAAAABQUFRQAAAAAAAAAA== ------=_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” <[email protected]> \ TO {25} “Prime” <[email protected]> \ BCC {46} “Secret” <[email protected]>, [email protected] \ 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: [email protected] RCPT TO: [email protected]


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

54

RCPT TO: [email protected] RCPT TO: [email protected]

Text From: “Sender” <[email protected]> To: “Prime” <[email protected]> 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: [email protected] To: [email protected] 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" TAAAAAEUAgAAAAAAwAAAAAAAAEYBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAD8AFAAfD+BP0CDqOmkQotgIACswMJ0UAC4AoP8smVf1GhCI7ADdAQzMSBUAAAAAAAAAZQAAAAAAAABQUFRQAAAAAAAAAA== ------=_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=?=" TAAAAAEUAgAAAAAAwAAAAAAAAEYBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAD8AFAAfD+BP0CDqOmkQotgIACswMJ0UAC4AoP8smVf1GhCI7ADdAQzMSBUAAAAAAAAAZQAAAAAAAABQUFRQAAAAAAAAAA== ------=_NextPart_000_00C1_01BFC725.4B420B00--

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


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

55

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 DELT (Delete)

4.8.1 format DELT <UID list>

Return value when successful: OK<CR><LF>

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


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

56

- When none of the specified UIDs exist


- A state other than the Select state

(2) BYE

- A connection with MSS cannot be established

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

4.9 LOUT (Log Out)

4.9.1 Format LOUT

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.





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

57

Appendix A List of Command Replies Command Normal finish Process failure Process unknown Disconnection AUTH Number of new

messages <CR><LF> OK <CR><LF>

NO<CR><LF> - Access

denied

BAD<CR><LF> - Incorrect

argument - Incorrect

command character string

- State mismatch

BYE<CR><LF> - MSS down - DIR down

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

None BAD<CR><LF> - Incorrect



- State mismatch

BYE<CR><LF> - MSS down

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

None BAD<CR><LF> - Incorrect



- State mismatch


STOR OK<CR><LF> None BAD<CR><LF> - Incorrect



- State mismatch


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

NO<CR><LF> - Incorrect

envelope semantics

BAD<CR><LF> - Envelope creation

failed - Incorrect



- State mismatch

BYE<CR><LF> - Storage in

spool failed

DELT OK<CR><LF> None BAD<CR><LF> - Incorrect



- State mismatch



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

58

Command Normal finish Process failure Process unknown Disconnection LOUT OK<CR><LF>

- Disconnection None BAD<CR><LF>

- Incorrect argument

- Incorrect command character string

- State mismatch

None


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

59

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 “AUTH” auth_type userid search “SACH” search_key store “STOR” set store_att_flags delivery “DELV” from_field to_field cc_field bcc_field

subject_field reply-to_field content-type_field content-transfer-encoding_field message_field

fetch “FECH” set fetch_flag fetch_option message delete “DELT” set logout “LOUT” auth_type “S” | “R” fetch_flag “xHP” | “xHA” | “xHO” | “xB” fetch_option section |

section [“<” number “.” nz_number “>”] | nil

search_key search_flags | uid search_flags “xR” | “xU” | “xS” | “xH” | “xN” store_att_flags “xS” | “xH” message_format “N” | “F” | “R” delivery_option uid | uid section | nil from_field “FROM” “{“ number “}” addr_name to_field “TO” “{“ number “}”addr_name | nil cc_field “CC” “{“ number “}” addr_name | nil bcc_field “BCC” “{“ number “}” addr_name | nil subject_field “SUBEJCT” “{“ number “}” string | nil reply-to_field “REPLY-TO” “{“ number “}” addr_name | nil content-type_field “CONTENT-TYPE” “{“ number “}” string | nil content-transfer- encoding_field

“CONTENT-TRANSFER-ENCODING” “{“ number “}” string | nil

message_field “MSG” “{“ number “}” string | nil

spec mm1 3gpp

Documents