NO323223B1 - A system, method and protocol for mobile e-mail communication - Google Patents

Description

Technical area

The present invention relates to the fields of mobile communication and Internet mail, and in particular it relates to a method and a protocol for the transmission of e-mail messages to and from said mobile device.

Background for the invention

Today's mail communication systems consist of an e-mail server for sending mail over the internet, and an e-mail client for reading and writing e-mail messages. The client is normally located on a personal computer with ample processing power and storage capacity. Transferring mail is a complicated process that makes use of several communication protocols. The protocols are designed with a fixed terminal in mind, which creates problems when a user wants to read or send mail from a terminal with more limited capacity, e.g. a mobile phone. Existing solutions do not take into account the limitations of mobile phones, i.e. limited processing and storage capabilities, limited navigation capabilities, small keyboards. Neither the limitations of the wireless networks, i.e. unstable conditions and long waiting time, nor unpredictable QoS are taken care of. Specifically, the problems that arise are due to the protocols that create overwhelming messaging between client and server, and unnecessary overhead in different parts of the email. This creates problems in a communication channel with limited bandwidth. In addition, excessively complex productions of the e-mail messages will create problems for display on a computer screen with limited size and resolution. Other problems are due to presentation formats that are not supported. A mobile terminal usually has both limited processing power and limited space for storing programs. Email clients are often of a complex nature, which is difficult to implement on a mobile client with limited performance. Finally, strict firewall setups will present problems for mobile access.

Attempts have been made to create more efficient solutions for mobile access to mail, e.g. by using VPN channels between server and client, or by introducing an additional web/WAP mail server to handle the traffic between the mail server and the client. However, these solutions create their own problems.

Summary of the Invention

There is therefore a need for a solution for mobile access to e-mail messages which avoids the shortcomings associated with prior art postal communication systems outlined above.

It is a purpose of the present invention to provide a method and protocol for mobile e-mail communication which is better adapted to a communication channel with limited bandwidth than is the case with systems in the prior art.

Another purpose is to provide a method and protocol which means that the e-mail messages can be displayed correctly on a computer screen of limited size.

A further purpose is to provide a method and protocol that is less demanding in terms of processing power and storage options in the mobile client.

The above purposes are achieved in a method for mobile e-mail communication as described in the attached claim 1, as well as a protocol for the transmission of e-mail messages as described in claim 16. Preferred embodiments of the invention will appear from the corresponding independent claims.

More specifically, the invention consists in a method for mobile e-mail communication between an e-mail server with a POP/IMAP/SMTP interface and a mobile terminal with an e-mail client with a SOAP interface, via a server for e-mail services with a POP/IMAP/SMTP interface as well as SOAP interface, said method including the following: sending SOAP message requests from the mobile terminal to the server for e-mail services, which contain predefined method calls for logging in and authenticating the user, for retrieving a mailbox from an account, for retrieving the headers from messages in a mailbox, to retrieve mail message content such as information describing the content, to retrieve the content of an attachment, to delete a message, to send mail from the mobile client, and which has as a parameter a message in XML protocol format,

converting the requests in the server for e-mail services into standard e-mail messages, and sending said standard e-mail messages to the e-mail server, and returning messages to the mobile terminal as SOAP messages with content in XML protocol format.

Furthermore, the invention consists of an e-mail communication protocol format for the transmission of messages to and from a mobile terminal, including the following: a <Headers> element containing a limited set of information relevant to a user of the mobile terminal, a <Flags> element imaged directly from the IMAP spec i fication,

a <Body> element of type "text/plain" MIME.

Brief description of the drawing figures

The invention will now be described in detail with reference to the attached drawings, where: Figure 1 shows the architecture of the current postal system (prior art). Figure 2 shows the connection between an SMTP mail object and a message in the Internet Message Format (known technique).

Figure 3 shows an SMTP envelope (prior art).

Figure 4 shows examples of e-mail structures (known technique).

Figure 5 shows a VPN solution (known technique).

Figure 6 shows a Web/WAP record overall architecture (prior art). Figure 7 shows a proposed new solution with end-to-end mapping of SMTP, POP, IMAP to XML Web service. Figure 8 shows an alternative new solution where the XML web service makes use of XMTP. Figure 9 illustrates the invention's solution when sending an e-mail message using XMMAP. Figure 10 shows the invention's web service architecture for e-mail using XMMAP. Figure 11 shows the message flow that occurs between participating components when sending an e-mail message using XMMAP.

Figure 12 shows the interfaces for the Web service.

Figure 13 shows a model of Web Service Enterprise.

Detailed description

As shown in figure 1, current mail communication systems consist of two main components, namely e-mail Server and e-mail Client. These are both composed of several elements that use several communication protocols, and of internal service elements. Examples of protocols are SMTP (Simple Mail Transfer Protocol) [4], IMAP (Internet Message Access Protocol) [5] and POP (Post Office Protocol) [6].

To send an e-mail message, the user will interact with the user interface (User Interface - Ul), which assists in setting up an e-mail message. When the user wants to send the email message, Ul will hand the message to the MUA (Mail User Agent), which will create an SMTP session with the remote MSA (Mail Submission Agent) to dispatch the mail. The MSA can perform pre-specified adaptations of the message to conform to the SMTP-IMF standards [7]. Next, it delivers the mail either to a local user via an LDA (Local Delivery Agent), or to an MTA (Message Transfer Agent) who forwards the mail to its final recipient(s).

An SMTP mail object contains an envelope and content. The SMTP envelope is sent as a series of SMTP protocol units. It consists of an origin address (to which error reports are to be sent), one or more recipient addresses and optional protocol extension material. Historically, variants of the recipient address command {RCPT TO) could be used to indicate alternative delivery methods, such as immediate display; such variants are now of less interest.

The SMTP content is sent in the protocol unit SMTP DATA, and has two parts: header and body. If the content conforms to other applicable standards, the headers form a collection of field/value pairs, structured in accordance with the Internet Message Format; the body, if structured, is defined in accordance with MIME (Multipurpose Internet Mail Extensions).

The mail will then be sent from MTA to MTA and will finally arrive at the final delivery MTA which places the mail in the Message Store via an LDA. This ends the SMTP transmission of the message.

To send and/or forward mail, we must follow the protocol described in RFC2821 [4] . This command sequence is often called the "SMTP envelope".

SMTP Envelope - overwhelming message transfers

This is an example of a typical "SMTP Envelope" for sending a normal email message to two recipients. It is worth noting the overwhelming message transfers:

220 dusl2.nta.no ESMTP Exim 3.35 #1 Fri, 09 Apr 2004 15:57:01 +0200

BHLO dusl2.nta.no

250-dusl2.nta.no Hi jonfinng at localhost [127.0.0.1]

250-SIZE

250-PIPE LINING

250 HELP

MAIL FROM: <jonfinng@stud.ntnu.no>

250 <jonfinngSstud.ntnu.no> is syntactically correct

RCPT TO:<luser8dusl2.nta.no>

250 <luserGdusl2.nta.no> verified

RCPT TO: <jonfinnglfstud.ntnu.no>

250 <jonfinng8stud.ntnu.no> verified

RCPT TO: <jonfinng@dusl2.nta.no>

250 <jonfinng8dusl2.nta.no> verified

DATA

354 Enter message, ending with "." on a line by itself

X-header: Test message

Headers (header part of the message) goes here...

content (body part of the message) goes here...

attachments go here...

250 OK id=lBBwZ4-0000nZ-0O

QUIT

221 dusl2.nta.no closing connection

As can be seen from figure 3, at least 11 message transfers between client and server are required to send a single e-mail message. Two additional transfers are introduced for each additional recipient. When sending multiple e-mail messages using the same connection to the mail server, at least nine message transfers are required. This is not desirable, as the aim is to keep the number of message transfers to an absolute minimum. The reason is that message exchanges introduce additional overhead and delays that are especially important to keep to a minimum when using a low-bandwidth wireless connection.

IMF and MIME - unnecessary headers and complex body-text structures

IMF (Internet Message Format) and MIME (Multipurpose Internet Mail Extensions) [8] are standards used to represent the actual content of the e-mail message. The IMF defines which headings are required and how a standard message should be organised. MIME is an extension of IMF, which defines how complex email messages should be re-presented. These are typically emails that have file attachments, multiple alternative representation formats or even attached emails within the message itself.

The IMF version of an email message is quite efficient and does not introduce any significant overhead. This makes IMF a good starting point in an attempt to represent e-mail messages that are adapted to mobile terminals. The problem with the IMF is not the format itself, but how it is used. An email message usually contains a good deal of information within headers. Most of this information is not relevant to the end user. This information may include a list of mail servers that the message has visited on the way to its destination, and several so-called "X-headers"!. This information is usually not presented in the user agents and introduces a significant degree of overhead when sending email -headings for mobile agents.

This is an example of the headers in a typical email message:

The headings marked in bold are the headings that are usually presented in a user agent, because they contain the information most relevant to the end user. By skipping all other headers, the size of the header element in this e-mail message will shrink from 2351 to 323 bytes and thus significantly reduce the overall size of this e-mail message. Only a minimal set of headers should therefore be transmitted when it comes to mobile terminals with limited bandwidth and client functionality.

the content of a MIME e-mail message is arranged in two layouts: INLINE and ATTACHMENT. The parts marked INLINE will usually be displayed in the mail client when the email is opened for reading. The parts of the INLINE content are recoded as text. The parts marked as ATTACHMENTS consist of binary data and must be opened in an external application or with the help of a Plug-in in the mail reader that can interpret this particular attachment. The different parts of the message are separated by custom "delimiters". When a delimiter occurs in the message, this marks the beginning of a new section. Each part must be identified by a parameter with "Content-type"

{content-type), which indicates the MIME type of the part in question. Other parameters for a body text can be the transcoding and the file name of the attachment.

Here is a clipping from an email message that contains a normal text part as INLINE and an attached image as ATTACHMENT. The first header element included in this element states that this is an MlME message and that the mail reader must support MIME to understand this message. When the message contains parts with different content types, the basic content type is marked as "multipart/mixed", as in this message. Also note the delimiters in this message (—=_NextPart_000_2a6d_- 50cl_182a) that separate the two parts of this email message.

The first body part is of type "text/plain" and represents the text of this message. Parameters tells us that the body has the character set iso-8859. The second part of the message is an attached image with content type "ima-ge/pjpeg". In this section, the file name and the encoding are added as parameters.

This example of how the content of an email message can be organized is just one way among many possible ways of structuring a message. MIME messages also support nested content and so-called "multipart/alternative" body parts (among many other content types). A "multi-part/altemative" message contains different presentations of the same data in different formats, so that the client can choose which format is most suitable for presentation. Figure 4 shows some examples of how e-mail messages can be organized into different body parts.

MIME is a good and much needed extension of regular mail. However, the e-mail representations can become very complex, and can require time for processing on terminals with limited processing capacity. MIME requires end clients to have support for viewing or opening the attachments that are sent. In addition, there is no purpose in sending multiple representations of the message itself {multipart/alternative) if the client cannot present it to the user. In such cases, MlME body parts will end up as unnecessary overhead.

Access agents and firewalls

The access and processing of e-mail messages stored in the message store is opened by an Access Agent (Access Agent) that implements protocols such as IMAP (Internet Message Access Protocol) or POP (Post Office Protocol). The client's application will contain either an IMAP client or a POP client (or both) for e-mail retrieval and mailbox operations. This is of course in addition to the software required to send mail using SMTP.

In many cases, the clients and the server will be on an intranet protected by the company's firewall, which prevents access to the e-mail server from outside this network. This is done to protect the server from external attacks and hacking attempts, as well as to stop unwanted forwarding activity, which may include spamming. On the other hand, users are becoming increasingly mobile and want access to their e-mail accounts even when they are outside the company's intranet. This entails a conflict of interest between security and availability.

The problems with current postal systems when accessed from mobile terminals can be summarized as follows:

Overwhelming messaging.

Unnecessary overhead in different parts of the email message.

For complex representations of the email messages.

Presentation formats that are not supported.

Complex implementation of email clients. Different protocol implementations are required for sending and retrieving e-mail.

Problems in connection with mobile access, as a result of strict firewall measures.

Current alternative solutions and their limitations.

A lot. work has been done to solve the problem of firewall settings, which often block access to mail operations outside the company's intranet. Several more or less successful attempts have emerged. The solutions could work well with laptops or desktop computers, but so far the solutions have strong limitations when used to send email to mobile phones.

Virtual private network

In this solution, shown in Figure 5, a VPN client creates a secure channel from the remote computer via the Internet and through the firewall to the corporate intranet. The client is thus logically connected to the intranet, and the user can use a normal e-mail client to access their e-mail using standard protocols.

This solution is very suitable for a PC with sufficient processing power and storage options as well as a relatively stable connection with a considerable transfer speed. This solution is not suitable for mobile devices for several reasons, namely: Most mobile devices are not equipped with a VPN client.

Mobile phone devices do not have sufficient processing power to & offset the overhead resulting from the encryption and decryption.

The unstable wireless connection can introduce problems during the VPN session.

Sporadic mail access for the mobile user is not practical due to long setup time and possible VPN connection timeout.

Mobile phone devices are unlikely to have sufficient storage space for all email messages.

Mobile phone devices are unlikely to have sufficient processing power and storage capacity to house both an SMTP client and an IMAP/POP client.

Mobile devices have much more limited capabilities in terms of user interface, namely small screen, limited means of navigation as well as a small and limited keyboard.

Mobile phone devices come in a number of different types, which complicates the construction of interfaces.

Web/WAP mail

As shown in Figure 6, a Web/WAP mail server is now introduced. It is usually located in the DMZ {De-Militarised Zone - «demilitarized area»} between the Internet and the corporate intranet. The web application server synchronizes with the corporate mail server within the firewall when it comes to retrieving and sending mail. This server actually contains a Web application with the same core elements as an email client. Both versions use SMTP and IMAP/POP to communicate with the mail server. The user has access to their mail using a WWW browser.

The main advantage of this solution is that a mobile phone user needs nothing more than a WWW browser to access the mail. No other functionality is required in the mobile phone device. The mobile device can access the user's email account on the webmail server either directly using an HTML/xHTML browser or via WAP using a WML browser. It is worth noting that this alternative also applies to pure webmail services such as Hotmail, Ya-hoo, Online etc.

The shortcomings are:

The mail messages are not stored in the mobile phone device, but on the Web/WAP mail server. To read the same post twice, the user must access the Web/WAP server again. This is due to the relaxed html/WML standard where it is difficult to distinguish the real information content from the presentation packaging.

Reading the record can be time consuming and less flexible because the web/WAP pages are dynamically generated on the fly for each access. Intermediate storage on the mobile phone device is difficult and requires a lot of storage capacity, again thanks to the overwhelming amount of presentation data that comes with the information content.

The postal messages are not adapted to display on small screens.

Problems with known solutions

.As reviewed previously, the existing solutions for mobile access to e-mail suffer from the fact that they did not take into account the limitations of the mobile phone devices, namely limited processing and storage capacity, small screen, limited navigation ability, small keyboard. Neither limit-

nings in wireless networks, i.e. unstable connections and long waiting times, or unpredictable QoS are properly taken into account.

Field of the invention

The present invention consists of two elements:

An architecture based on XMMAP that enables the mobile user to access, send and process their own mail stored on a mail server located on the user's corporate intranet.

A protocol called XMMAP (XML Mobile Email Access Protocol) which consists of a set of procedures and a data model that eliminates the functional requirements of the mobile phone devices and reduces the amount of data that is sent to the mobile phone device.

Mobile mail access with SMTP and IMAP/POP web service

To allow mail access from mobile devices, the XML web service has proven to be well suited, thanks to the ubiquity of the Internet and the ability to pass through firewalls using SOAP (Simple Object Access Protocol) [2]. The most direct solution is to expose all of SMTP and IMAP/POP as web services, as shown in Figure 7. Each SMTP and IMAP/POP command is mapped to a web service method. In fact, each SMTP or IMAP/POP command is encapsulated in a SOAP message and transported to the WS client.

An advantage of this solution compared to the Web/WAP solutions is that there is no overhead data that indicates the appearance of the content. Compared to VPN, this solution is more robust thanks to the use of SOAP. SOAP has a more relaxed way of handling sessions. This includes allowing sessions to survive even if the connection is lost for a period of time.

The shortcoming is the many functional requirements that are placed on the mobile phone device. In order to access and retrieve mail, the WS client must be able to understand the SMTP/IMAP/POP languages and communicate correctly with the mail server. It must therefore be equipped with both an MUA (Mail User Agent) with full SMTP support and an IMAP/POP client. This functionality is added on top of the SOAP engine.

Other shortcomings are the large number of interactions, and also the large amount of downloaded data that this solution entails. This is definitely not suitable in wireless networks with limited bandwidth.

IMAP and SMTP are not pure request-response protocols. They also include the possibility of server-generated messages. If full compliance with SMTP and POP/IMAP is to be achieved, the clients must also be able to listen for method calls from the server. In this case, server-generated method invocation means a full web service implementation on the client. This is impractical due to the limited processing and storage capacity of mobile telephone devices. These do not have a static internet address, and the connection is often disconnected. In other words, mobile phone devices are designed to act as servers.

Mobile mail access with XMTP

The use of Web services in XML has been taken a little further with the introduction of XMTP (XML MIME transformation protocol) [1]. XMTP is a protocol for mapping IMF or MIME messages to an XML version.

By using XML, we are able to transport the entire message in XML (see Figure 8). This makes it easier for the client to parse the message. An XDS (XML Definition Schema) can be used to interpret the various fields in the message, whereby presentation of the record in the client is potentially faster.

XMTP contains no functionality apart from the IMF message mapping. This means that when using XMTP, all message exchanges and overhead must remain as in the previous procedure. XMTP itself can introduce a certain amount of overhead due to XML tags.

There is very little to be gained by using XMTP instead of direct mapping, it even entails further complexity on the server side by introducing a conversion routine between SMTP and XMTP. A solution using XMTP must therefore be rejected as suitable for use with mobi1 terminals.

Mobile mail access with XMMAP

The aim of introducing XMMAP (XML Mobile Email Access Protocol) is to solve some of the main problems concerning e-mail access from mobile devices, and to overcome the limitations and inadequacies of the previously proposed solutions.

As was evident from the message sequence map in Figure 3, at least 11 messages between client and server are required just to send an email message. This is highly undesirable when using a mobile phone device. If the radio link fails in the middle of a message sequence, the entire procedure must be repeated. Also, each message transfer will introduce unnecessary overhead from the underlying protocols. On top of this we have the consideration of overhead in headers and display as discussed earlier.

By introducing XMMAP, we reduce the number of message transfers to two for most IMAP/POP/SMTP operations. As shown in figure 9, we are down to one message from the mobile client to the web service and one message in return.

POP and IMAP do not have as many message transfers as SMTP. Often only one request and one response is required per implementation. On the other hand, these protocols require the user to identify himself before any operation is initiated on the account. This introduces session management and additional delay and overhead.

The main benefit of using XMMAP is that it both combines and simplifies the functionality and information provided by the MTA {SMTP), the access agent (IMAP(POP)) and the display format (SMTP-IMF/XMTP). This is achieved by mapping the information to an XML format and associate different parts of the format with specific requests and responses to SOAP methods.

Like XMTP, XMMAP uses the strength of XML to simplify the division of the received information. The terminal can use an XML parser to extract the information from the XMMAP message as well as to construct new XML documents. This makes implementing an XMMAP-compliant mail client a very simple matter, compared to a full-scale mail client that supports SMTP with a large variety of MIME types, as well as the client implementations of POP and IMAP.

XMMAP introduces a new concept in messaging. While traditional protocols require frequent message transfers with well-defined operations, XMMAP is more flexible and makes it possible to perform most operations in one exchange.

In its basic form, XMMAP is a representation of an entire mail account, covering everything from login credentials to flags in a specific message. This makes it possible to use parts of the XMMAP format to represent different parts of a postal account for different purposes. This is especially useful when XMMAP is used to call methods on the mail server. When calling a method, only the relevant parts of the format are sent, so that unnecessary overhead is avoided.

XMMAP data format

As mentioned, XMMAP is a representation of an entire postal account. This section contains a brief description of the format, including a number of examples, we get straight to the point by giving an example of how the most important part of an account, a single message itself, is represented in XMMAP:

The format is largely self-explanatory, as it contains elements from the aforementioned well-known protocols (SMTP, XMTP, P0P3 and IMAP). XMMAP preferentially maps to a standard SMTP-IMF message, with or without MIME extensions, and vice versa. In addition to this, an XMMAP message adds the necessary information provided by both POP3 and IMAP mail access protocols.

The <Message> element is the root of a MIME/RFC2822 message. A <Message> element contains the <BoxNumber>J <Headers>, <Flags>, <Body> and <Attachments> elements.

Explanation of elements in XMMAP

namespaces

"namespace" links to a dated URI containing relevant XML data to describe the current use of the XMMAP protocol.

The web:about attribute

This attribute is adopted from the XMTP format and contains the message identifier URI.

The <BoxNumber> element

A <BoxNumber> represents the number of a message in a mailbox. The mailbox in question can be given as a parameter when it is not apparent from the surrounding context.

The <Headers> element

<Headers> contains standard RFC 2822 headers with local names representing the header names. Parameters are represented by child elements.

A main point of using XMMAP is to avoid transmitting every single header present in the original SMTP-IMF message. Instead, it aims to use only a limited set of headers that convey information of importance to the end user. E.g. An SMTP message often contains several headers with "Received" and "X". This information could be relevant when tracing back message paths and for tasks in connection with system-specific processing (such as firewall blocking and spam filtering). However, this information is not relevant to the end user. To save storage space and transmission capacity in the mobile terminal, as many header elements as possible should be removed from the message. This is carried out by the SMTP->XMMAP portal before the message is delivered to the mobile terminal.

The <Flags> element

The <Flags> element adds the current flags in an email message as child elements. When retrieving with XMMAP flags that have been set previously, the set flags are sent and the tag has the value "1". When setting a flag, the value "1" means that the flag should be set, and "0" that the flag should not be set. The flags are mapped directly from the IMAP specification.

The <Body> element

The <Body> element (body) contains the body of the email message. The current character set is given as a parameter. If no parameter is given, "us-ascii" is assumed as in SMTP-IMF. The content of the <Body> element is always represented as "text/plain" MIME type. If the original message adds optional ways to represent the message, all but one of the options are removed from the message by the SMTP->XMMAP portal. If the body text is only represented in, for example, "text/html", the HTML tags are removed. The result after removal is delivered as "text/plain". This is done to reduce the amount of data to be sent, as well as to deliver the data in as simple a format as possible for use in connection with mobile terminals.

Optionally, the representation options can be added and the corresponding MIME types given as parameters to the element

<Body>. If the client cannot represent a body part, an error message will be delivered and displayed to the user.

Example of alternative representations of the element

<Body>:

The <Attachments> element

Only applicable if the message contains attachments. These are delivered within the <Attachments> element. MIME type and encoding are provided as attributes. Transcoding can be omitted, in which case base64 is assumed. In addition, an attachment element contains the elements <Filename>, <Size> and <Content> which respectively contain the file name, size and content in the form of binary encoded data.

attachments can be large, and in many cases the user is not interested in downloading such, but only wants to receive the text and description of the attachment. In such cases, the <Content> element may be empty (<Content/>). Even if the <Content> element is empty, the user receives information about the file type, file name and size of the file. Based on this information, the user can decide whether he wants to download the attachments later or not.

The elements described are sufficient to represent an email message. Including elements both from representation format SMTP-IMF and flag information used in access protocols. However, to represent an entire account, some additional elements are required. A representation of an entire account using XMMAP is shown below.

Account representation using XMMAP:

The <Account> element

The <Account> element represents an entire email account with all its meta-information and content. The account contains elements <Mailboxes> (mailboxes). Account elements may also include login credentials. This can be

<UserName>, <PassWord>, <Protocol> and <Port> (username, password, protocol and port). The <Account> element is only required when logging in to an account, and when receiving a list of available mailboxes from the server.

The <Mailboxes> element

An account can contain one or more mailboxes, these are listed within the mailbox item label as MailBox items.

The <Mailbox> element

Information about how many messages a mailbox contains, and how many of them are new messages, is often desirable. One way to obtain this information is to download all messages in a mailbox and check which of them have the correct flags set. This is not smart to do when it comes to mobile terminals with limited storage and processing capabilities. IMAP and POP have features that give you this information without having to download all the messages.

The mailbox element in the XMMAP format provides information typically provided by POP and IMAP. The element can also contain a full rendering of mailboxes with contents. <BoxName>, <Un-read>, <Total>, <Messages> and <Mailboxes> are sub-elements of a Mailbox element. <BoxName>, <Unread> and <Total> respectively contain the name of the mailbox, the number of unread messages in it, and the total number of messages.

The <Messages> element

The Messages element can contain one or more of the messages in this folder. It can also remain as an empty label if this information is not desired in the current request. A Mailboxes element within a Mailbox element contains sub-mailboxes of the current mailbox if any exist.

XMMAP-defined methods

The XMMAP data format is useful when it comes to representing an account in a minimalist way, and can also be a good fit for storage purposes. On the other hand, the data format lacks the link to specific methods related to mobile mail access. This coupling is achieved by defining SOAP methods that use XMMAP messages as parameters.

The following set of methods have been implemented so far:

Method list

loginMobileTarmXMMAP and loginProfileXMMAP

These are methods used for authentication. Required for mail retrieval, because remote IMAP and POP servers require authentication. It is recommended to use these methods of authentication, regardless of the ongoing operation. This is because authentication of users largely prevents abuse of the service and that it opens up better tracking possibilities when unwanted use is detected.

When these two methods are invoked, a session is created by the web service. It is recommended that this session be a SOAP session, but it can also be based on underlying protocols such as HTTP. The web service also manages a connection to the mail server related to each session. The session retrieves a previously saved profile or it creates a new one. The profile contains, among other things, information, special customization properties for the mobile terminal used in this session.

The difference between these two methods is that "loginProfileXMMAP" uses a pre-stored profile, while "loginMobileTermXMMAP" takes several input parameters required to form a new profile for use from now on. These parameters are typically related to the mobile terminal with support for screen size and maximum number of colors. These parameters are not part of the XMMAP message itself.

The response to a call to these methods is a session and profile ID in addition to the XMMAP message (see example below). The XMMAP message is a list of mailboxes in the requested account.

Example of request message:

Example of a response message:

getMailBoxes

This method fetches the mailboxes from an account when it is already logged in. The message exchange is quite similar to the login methods. However, the request can be reduced to

<Account /> or omitted entirely, since the user is already logged in and the account information is stored within the session.

getHeadersAsXMMAP and getNewHeadersAsXMMAP

These methods are used to retrieve headers from messages in a mailbox. It is often desirable to retrieve only information about unread mail, to avoid overflowing the screen on the mobile terminal with information about old e-mail. Therefore, a method called "getNewHeadersAsXMMAP" should be implemented in addition to "getHeadersAsXMMAP". Which headings should be sent and which should be cut off must be set as part of the user profile.

Example of request message:

<Mailbox>

<BoxName>INBOX.old</BoxName>

</Mailbox>

Example of a response message:

getMessagesAsXMMAP

As the name suggests, this is the message for retrieving mail message content. The request message must state the name of the mailbox and the number(s) of the message(s). Note that the contents of any attachments are not sent in the first instance, but only the information describing them. The user can then choose whether to download them later using the "getAttachmentsAsXMMAP" method.

Example of request message:

Example of a response message:

getAttachmen tAsXMMAP

This method can be called to get the contents of an attachment. The client will have received a description of the attachment {attachments) from a call to the method "getMessagesAsXM-MAP", and uses the attachment number(s) to identify which attachments to which message(s) he wants. Only attachments will be sent, the body content will be left out.

Example of request message:

Example of a response message:

setFlags

This method can be used to set message flags on the IMAP/POP server. The method returns nothing, except error messages if something goes wrong. Note: if the DELETE flag is set with setFlags, the message is marked as deleted, but keeps it in the mailbox. See the Delete method for permanent deletion.

Example of request message:

delete

This SOAP method marks a message as deleted, or deletes it permanently (also called expunging) from the IMAP/POP server. Whether expunge should be performed or not is given as a parameter to the method call. The default is not to expunge. The method returns nothing except error messages if something goes wrong.

Example of request message:

sendMail

This is the method that will be used to send mail from the mobile client. One message exchange is sufficient, as opposed to the minimum 11 that SMTP requires. If the IMAP protocol is used, the web service will send the final message to the user's "Sent" box and mark messages as "Requested" in the current mailbox if the message is a reply (given by a "ReplyNumber" element together with the headers). Inserting multiple <To>, <Cc> or <Bcc> headers in the request message adds multiple recipients to XMMAP. These headers are parsed by the web service and converted to SMTP on its outgoing interface. A message that follows RFC2822 is also created by the web service based on received information, before it is sent to the final destination by SMTP (see figure 11 which shows the message flow between participating components when sending an email message using XMMAP).

Example of request message:

This message does not need a response if the web service was successful in forwarding the mail to its final destination. A SOAP error describing the error is returned if the email could not be delivered for some reason.

log out

To log out, the server does not need more information than the session ID. The logout call is therefore a SOAP message with an empty body text field.

This will close all connections to the user's mail server and delete the session on the web service server.

Summary

The methods described briefly here constitute only a limited subset of the most important methods that can be implemented by connecting SOAP and XMMAP for e-mail access from mobile terminals. In principle, there are no restrictions on which methods can be implemented in addition. The XMMAP format is flexible and can be expanded with new elements in any part of the format, if found to be beneficial. There is no fixed order for how today's messages are sent after the user has logged in. When defining new methods, this principle should be followed so that the individual message is independent of both preceding and subsequent messages.

Architecture overview

Figure 10 shows our architecture and its various software layers and interfaces. The Web Service Client (WS Client) needs support for SOAP and J2ME [3] as for the other proposed solutions. In addition to the client, this solution only needs a Mail User Agent (MUA) capable of XML creation and sharing, as well as for sending and receiving XMMAP messages. In other words: No support for any other mail protocol is required. This makes client implementation much easier, compared to traditional solutions.

Any operation on the client needs only one XMMAP message sent to the web service, and one message in return, the ws engine (WS Engine) interprets the message with the client request, performs the necessary communication with the IMAP/POP/SMTP server, and converts the result into a XMMAP message, sent back to the client.

Figure 11 shows the interaction between some of the components from Figure 10 when a mobile client sends an email using the web service, we see how the SMTP interaction is reduced to one message for the client.

I nter n web service - f uriks j onal i te t

As mentioned briefly before, the web service will adapt the mail messages for mobile terminals such as mobile phones and PDAs. This is achieved by removing unnecessary message headers. Alternative renderings of the same content {e.g. both plain text and HTML representations of the body text) are reduced to one. By default, attachments are withheld until the user explicitly requests them. These measures keep the amount of data sent and the number of message exchanges to a minimum.

A summary of the internal functionality provided by the XML web service (see Figure 10):

SMTP-IMF to XMMAP portal and vice versa.

XMMAP to IMAP/POP portal and vice versa.

Authentication of users.

Storage and processing of user profiles.

Increased handling for all interfaces and related active connections.

Content customization. This includes everything from separating labels and attachments to resizing images.

Optional: Local buffering of messages and attachments.

Provide the necessary interfaces (see the section on interfaces).

Borderline

The XML web service should provide these interfaces: SMTP interface. The XML web service will carry out the necessary communication with MSA/MTA when sending e-mails. For this to work, it must perform all communication with the MTA using the SMTP protocol.

POP/IMAP interface. Necessary to collect mail and process the postal account. Should also have TSL/SSL support. SOAP/XMMAP interface. This interface is used for communication with the client and is described in detail in this document.

Optional: SOAP interface. One or more interfaces for communicating with other XML web services. Examples can be filtering services for special content, such as spam filters and virus filters.

The XML web service should have a fast connection with all interfaces, so that there are minimal delays in the communication between the web service and the mail server. All interfaces should support encrypted communication using SSL/TLS.

Benefits

Our solution provides fewer message transfers between client and server, and less interaction provides better performance for equipment with low bandwidth.

Because only information related to the message is sent to the client, messages can easily be stored in the mobile device. This is not practical when the email account is contacted via e.g. webmail.

The content is automatically adapted to fit the terminal, using information sent by the client software about screen size and color support, etc. Unnecessary information is stripped away by the web service before the response goes to the client.

Session timeouts are a problem when working with services that require authentication. Especially when accessing the Internet via a GPRS network, the GPRS/Internet portals will tend to have short timeout intervals. Timeout recovery often means assigning a different IP address, which invalidates the entire higher-layer session. This problem is solved when SOAP sessions are used, which ensures session mobility.

Firewalls are no longer a problem, because all mail traffic can pass via SOAP messages.

The present invention sets several requirements for mobile phone devices in terms of processing and storage capabilities.

It is highly aligned with standard techniques such as XML web services, IMAP, POP and SMTP.

Limitations and possible improvements

The solution as it currently exists still has some limitations. Here are some suggestions on how these could be solved: SOAP and XML themselves introduce overhead, and eat up much of the savings gained by using XMMAP. To make the amount of data even smaller, it may be an idea to compress the content of the SOAP message before transmission and decompress it on reception. However, this will require additional processing capacity at the client. This could potentially mean slow access for clients.

The XMMAP request XML document can become unnecessarily large. When, for example, there is only a need to send a post ID, additional XML tags are also sent in accordance with the XMMAP standard. A good solution to this problem is to offer multiple SOAP methods on the web service with the same functionality. Similar methods that take respectively XMMAP or simple SOAP data types as parameters.

There are currently no clients that support XMMAP, which can mean a large workload for pioneers implementing the first applications. This of course applies to everything that is new, but we believe that the simplicity and flexibility will still make XMMAP attractive.

Retrieving mail can be slow, as this is highly dependent on the connection with the remote mail server, which itself can be slow. As long as the connection with the mail server is faster than the connection to the client, buffering is possible. This can be intermediate storage of messages when the header is retrieved, and/or of attachments when retrieving the messages. The content will then be pre-processed and ready for transmission when the potential request for the content arrives.

Extension

Our e-mail service can interact with other web services in a corporate network with collaborative web services. An example of this is shown in Figure 13.

The e-mail web service can also be configured to act as an MTA, allowing e-mail messages to be forwarded between different instances of the web service.

Construction of Plug-in modules that utilize this XML web service for standard e-mail user agents that Microsoft Outlook will open for global e-mail access. This service will be as accessible as Web/WAP mail is today, but allow the user to use their favorite user agent instead of a special interface via a WWW browser.

Referrals

[1] XMTP (XML MIME Transformation Protocol) http://www.openhealth.org/documents/xmtp.htm

[2] SOAP (Simple Object Access Protocol) Specification http://www.w3.org/TR/soap/

[3] Java 2 Platform, Micro Edition http://java.sun.com/j2me/

[4] SMTP (Simple Mail Transfer Protocol) http://www.ietf.org/rfc/rfc2821.txt

[5] IMAP (Internet Message Access Protocol) http://www.ietf.org/rfc/rfc2060.txt

[6] POP (Post Office Protocol)

http://www.ietf.org/rfc/rfcl939.txt

[7] IMF {Internet Message Format) http://www.ietf.org/rfc/rfc2822.txt

[8] MIME (Multipurpose Internet Mail Extensions) http://www.ietf.org/rfc/rfc2045.txt

Claims (18)

1. Procedure for mobile e-mail communication between an e-mail server with a POP/IMAP/SMTP interface and a mobile terminal with an e-mail client with a SOAP interface, via a server for e-mail services with a POP/IMAP/SMTP interface as well as a SOAP interface, the said method is characterized by the following features: sending SOAP message requests from the mobile terminal to the server for e-mail services, which contain predefined method calls for logging in and authenticating the user, to retrieve a mailbox from an account, to retrieve the headers from messages in a mailbox, to retrieve mail message content such as information describing the content, to retrieve the contents of an attachment, to delete a message, to send mail from the mobile client, and which has as a parameter a message in XML protocol format, conversion of the requests in the mail service server for standard e-mail messages, and send said standard e-mail messages to the e-mail server, and return messages to the mobile terminal as SOAP messages with content in XML protocol format. 2. Procedure according to claim 1, in that the method calls loginMobileTermXMMAP and loginProfileXMMAP for logging in and authenticating the user include as parameters in the XML message at least the user's name, password and address, optionally also the protocol to be used against the e-mail server and the port on the e-mail server. 3. Method according to claim 1, in that the method call getMailBoxes is used to retrieve a mailbox from an account when the user has been logged on. 4. Method according to claim 1, in that the method calls getHeadersAsXMMAP and getNewHeadersASXMMAP used to retrieve the headers from messages in a mailbox include the name of the mailbox as an input parameter. 5. Method according to claim 1, in that the method call getMessagesAsXMMAP for retrieving mail message content as information describing the content includes the name of the mailbox and the mailbox number as input parameters. 6. Method according to claim 1, in that the method call getAttachmentAsXMMAP for retrieving the contents of an attachment includes the name of the mailbox, the number of the mailbox and the attachment number as input parameters. 7. Method according to claim 1, in that the delete method call to mark a message as deleted or to delete the message permanently from the e-mail server includes the name and number of the mailbox as input parameters. 8. Method according to claim 1, in that the method call sendMail for sending mail from the mobile client includes the name and address of the sender, the name and address of the recipient, the subject of the email and the body text content as input parameters. 9. Method according to claim 8, in that said method includes including a description of attachment content type, a file name of the attachment, a size of the attachment and the content of the attachment as input parameters. 10. Method according to claim 1, in that said method includes a method call for logging out, realized as a message with empty body text content. 11. Method according to any one of claims 1-10, including compression of the messages. 12. Method according to claim 1 or 5, including withholding attachments to e-mail messages in the e-mail server until the user of the mobile terminal sends a request for them. 13. Method according to any one of claims 1-10, wherein said method includes intermediate storage of all messages and attachments in said server for e-mail services. 14. Method according to claim 1, in that said method includes the removal of unnecessary email headers. 15. Method according to any one of claims 1-10, said method including encryption of all messages using SSL/TLS. 16. Communication protocol format for e-mail to transfer messages to and from a mobile terminal using the method according to claim 1, characterized in that the protocol format includes the following elements: a <Headers> element containing a user-defined reduced set of information relevant to the user of the mobile terminal, a <Flags> element mapped directly from the IMAP specification, a <Body> element of type «text/plain»-MlME. 17. Protocol format according to claim 16, in that said protocol comprises a <BoxNumber> element which represents the number of a message in a mailbox in the e-mail server. 18. Protocol format according to claim 16, in that said protocol comprises an <Attachment> element with a sub-element <Filename> which contains the name of an attached file, a <Size> subelement containing the size of an attached file, a <Content> subelement that is empty.