Mobile Email Requirements
April 26, 2012Scope (Informative)
Mobile e-mail is defined as an e-mail service optimized to support e-mail usage in mobile devices and mobile networks. This document describes various use cases to illustrate key mobile e-mail usage patterns and will also provide a comprehensive set of high level requirements that can be derived from the use cases. High-level requirements can be used as a basis for more detailed architecture definition work.
Use cases and high level requirements are defined and described in a technology agnostic way and as such no specific technology implementation is suggested.
This Requirements Document focuses on requirements for the enabler specifications rather than for particular implementations of those. Whether the described features are optional or mandatory for implementations will be decided at a later stage.
References
Normative References
| [RFC2119] | “Key words for use in RFCs to Indicate Requirement Levels”, S. Bradner, March 1997, URL:http://www.ietf.org/rfc/rfc2119.txt |
| [RFC2822] | “IETF Internet Message Format” (http://www.ietf.org/rfc/rfc2822.txt) |
| [RFC2045] | “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies (http://www.ietf.org/rfc/rfc2045.txt) |
Terminology and Conventions
Conventions
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].
All sections and appendixes, except “Scope” and “Introduction”, are normative, unless they are explicitly indicated to be informative.
Definitions
| Mobile E-Mail | Enabling technologies that facilitate end-to-end application level interoperable e-mail transactions (e.g. submission, retrieval, notification etc) to and from mobile devices. |
| E-Mail Events | Changes to the status of an e-mail (e.g. read/unread, flagged, deleted, etc…) that result for example from reading, moving, deleting etc an e-mail. They may be server or client side events depending on where the change takes place |
| Email Message | A sequence of data containing a Header and optionally: A Body, Meta data Email Message Headers and Bodies are defined in [RFC2822] “Internet Message Format” |
| Header | A sequence of lines of characters whose syntax includes a field name followed by a colon (“:”) and followed by a field body. Mandatory Headers included in e-mails are ‘To:’ and ‘From:’ Headers can also include additional custom end-to-end message headers Source: IETF [RFC2822] “Internet Message Format”. |
| Body | A body consists of one or more parts that follow the header. A body could include a combination of some or all of the following: [RFC2822] defined plain text parts [RFC2045] defined MIME parts, e.g. inline multimedia content (e.g. SMIL, HTML) Attachment(s) |
| Attachment | A special body part within the message body. Attachments can be displayed in-line or separately based on the indicated presentation semantic, e.g. graphics or word processing files. |
| Meta Data | Machine-generated attributes applied at delivery time appearing in [RFC2822] header fields. Examples include “RESENT” header field, Message Context (voicemail, email, MMS, SMS) and Processing Rules results. |
| Filtering Rules | A set of actions and conditions where the conditions are evaluated to determine what e-mail events and what e-mail notifications should be sent from the client to the server or the server to the client. They also include rules to select what new e-mails should be delivered from the server to the mobile client. This may be based on several criteria like subject, date, sender, folder where it is located etc… |
| Processing Rules | Actions and conditions that are applied on new e-mail. They include: spam prevention, filtering rule, antivirus processing and other scans, attachment removal |
| Server to Client Notification | A means by which the server informs the client of status changes, e.g. a new message has arrived. |
Requirements
Unless otherwise stated, all requirements apply to the Mobile E-mail Enabler
High-Level Functional Requirements
| Label | Description |
| HLF-1 | It MUST be possible to minimize delays and bandwidth requirements (e.g. by minimizing the number of roundtrips between client and server, the bytes to exchange between client and server, etc…) for the following: o Events sent from the server to the client or accessed by the client to announce or describe new e-mail o Exchanges to deliver new e-mail from the server to the client o Events sent from the server to the client to announce or describe e-mail events on the server o Events accessed by the client from the server to announce or describe e-mail events on the server o Exchanges to reconcile the client after a e-mail event on the server o Exchanges to access or manipulate attachments o Sending e-mail from an assigned e-mail server o Sending e-mail events on the client to the e-mail |
Table 1: High-Level Functional Requirements
Security
| Label | Description |
| SEC-1 | Events sent from the e-mail server to the client to announce or describe new e-mail MUST support confidentiality and integrity. |
| SEC-2 | When used, events accessed by the client from the server to announce or describe new e-mail MUST be end-to-end confidential when desired. |
| SEC-3 | Exchanges to provide new e-mail arrived on server to the client MUST be end to en d confidential when desired. |
| SEC-4 | When used, events sent from the server to the client to announce or describe e-mail events on the server MUST be end-to-end confidential when desired. |
| SEC-5 | When used, events accessed by the client from the server to announce or describe w-mail events on the server MUST be end-to-end confidential when desired. |
| SEC-6 | Exchanges to reconcile the client after an e-mail event on the server MUST be end to end confidential when desired. |
| SEC-7 | Exchanges to access or manipulate attachments MUST be end to end confidential when desired. |
| SEC-8 | Exchanges to send e-mail from the assigned e-mail server MUST be end to end confidential when desired. |
| SEC-9 | E-mail events sent from the client to the e-mail server MUST be end-to-end confidential when desired. |
| SEC-10 | The client MUST be able to be authenticated by the server when requesting data from the e-mail server. |
| SEC-11 | The server MUST be able to be authenticated by the client. |
| SEC-12 | Mobile email MUST support content screening. |
| SEC-13 | The mobile e-mail enabler MUST allow the mobile client to be protected by the same spam protection solutions as applied on the server. |
Table 2: High-Level Functional Requirements – Security Items
NOTE: When desired is used in the mobile e-mail RD in association to security requirements to emphasize the fact that seeking confidentiality of the exchanges between the client and the server MUST be supported when mandated by the actors BUT that it may be okay not to support them in cases where such additional confidentiality assurance is not required or desired.
For example, consumer internet email does not provide such extra confidentiality. In such cases, it may not be needed to provide it with mobile e-mail. Corporate e-mail requires such confidentiality. Therefore the requirement on the enabler is a MUST.
Charging
Charging is not intrinsic to the mobile e-mail enabler.
| Label | Description |
| CHRG-1 | In order to support charging for e-mail traffic, the mobile e-mail enabler SHOULD provide ways to identify mobile e-mail exchanges (events, access, sending, synchronization) as e-mail data exchanges, even when the exchanges are end-to-end secure. |
Table 3: High-Level Functional Requirements – Charging Items
Administration and Configuration
| Label | Description |
| ADMIN-1 | It MUST be possible to provision the mobile client from the server upon authentication and authorization of the user and pairing with a device. |
| ADMIN-2 | It SHOULD be possible for user preferences/filters/settings to follow the user across devices, when desired by the user or administrator. |
| ADMIN-3 | Authorized principals MUST be able to configure the settings of the user preferences/filters/configurable settings for a particular user. |
| ADMIN-4 | The mobile email enabler MUST support preventing or remotely revoking unauthorized usage of and access to e-mail data of a mobile device. |
Table 4: High-Level Functional Requirements – Administration and Configuration Items
Usability
| Label | Description |
| USAB-1 | Mobile email SHOULD minimize event propagation delays and must not impose excessive delays according to user preferences. |
| USAB-2 | Mobile email SHOULD minimize delays in accessing email messages and must not impose excessive delays according to user preferences. |
| USAB-3 | When / if downloading an attachment, the client SHOULD be able to provide indication of the download and to estimate of the time needed to complete the download. |
| USAB-4 | E-mail sent from client MUST be sent to the e-mail server according to user preference if configurable or client settings otherwise, when network connectivity is available. |
| USAB-5 | When connectivity is not available or drops, if it is possible to compose and sent e-mail, it MUST be stored on the client until connectivity becomes available and then sent to the e-mail server as soon as possible. |
| USAB-6 | E-mail events on the client to the e-mail server MUST be sent to the e-mail server according to user preferences if configurable or client settings otherwise, when network connectivity is available. |
| USAB-7 | When connectivity is not available or drops, email events on the client that may take place MUST be stored on the client until connectivity becomes available and then sent to the e-mail server as soon as possible. |
| USAB-8 | The mobile email enabler MUST provide support for the user to be able to set filtering rules for the delivery of email based on: o Email header fields o Mailbox folder options. o Server-determined spam score, Other criteria as needed. |
| USAB-9 | The mobile email enabler MUST provide support for the user to be able to change filtering rules from his mobile client. |
| USAB-10 | Rules (like filtering rules, processing rules, attachment removal, spam prevention, …) applied on the server MUST still apply to the repository on the client for what the user has selected to synchronize on the client. |
| USAB-11 | The mobile email enabler MUST provide support for the user to be able to select the default or available ways to be notified about new e-mails based on capabilities of client and network: o what notification is used (e.g. SMS, Push, MMS, …) o if events are accessed by client (when, how, what is initially part of the event) |
| USAB-12 | The mobile e-mail enabler MUST support the use of a number of different means to transport notifications (e.g. SMS, MMS, WAP Push, SIP Notification, UDP, in band, polled, …). This will allow. deployment on any target networks. |
| USAB-13 | The User MUST be able to select how e-mail server should present new e-mail events to the client and to select how the client reacts to such events and therefore how the new e-mail is reflected in the client repository: o A few meta-data, no stored e-mail o A given size of the e-mail o The whole e-mail without attachment o The whole e-mail with attachment |
| USAB-14 | The user MUST be able to manually initiate access to e-mail that has arrived on the server but is not yet on the client. |
| USAB-15 | The user MUST be able to manually access more e-mail data when only a portion is stored on the client (e.g. more of the body, a specific attachment, more of a specific attachment, the rest of the body, the whole e-mail with all attachments). |
| USAB-16 | Authorized principals MUST be able to select the default or available ways that -mail events are sent to or accessed by the client and other e-mail settings that may affect the server behaviour. |
| USAB-17 | The mobile e-mail enabler SHOULD NOT require repetitive actions by the user to provide robustness to intermittent or unreliable connectivity (e.g. loss of connectivity, loss of network transport packets and reconnect) (e.g. having to initiate client reconnect, initiation of synchronization, password entry for server authentication, VPN re-establishment, etc…). |
| USAB-18 | The mobile email enabler MUST enable the user to forward an e-mail with attachment without downloading the attachment to the client. |
| USAB-19 | The mobile email enabler MUST enable the user to forward an e-mail partially downloaded without having to download the remainder to the client. |
| USAB-20 | The mobile e-mail enabler SHOULD minimize the amount of information that a user must provide to provision an e-mail client to access the appropriate e-mail server. |
| USAB-21 | The client MUST allow the user to reply to an e-mail partially downloaded without first having to download the remainder of the e-mail to the client. |
| USAB-22 | The client MUST allow the user to edit a partially downloaded e-mail, for reply and have the resulting e-mail sent from the server. |
| USAB-23 | The client MUST allow the user to edit a partially downloaded e-mail , for forward and have the resulting e-mail sent from the server. |
| USAB-24 | The client MUST be able to download body parts or parts thereof that the user wants to edit when replying to an e-mail partially downloaded to the client. |
| USAB-25 | The client MUST be able to download body parts or parts thereof that the user wants to edit when forwarding an e-mail partially downloaded to the client. |
| USAB-26 | When replying to a long list of addressees, the client MUST allow the user to edit the addresses. |
| USAB-27 | Mobile-email Enabler SHOULD support multiple email accounts. |
| USAB-28 | Mobile-email Enabler MUST support configuration of email account information for connection and filtering on a per-account basis. |
| USAB-29 | Mobile-email Enabler SHOULD support definition of auto-reply messages for filtered messages. Automatically generated replies MUST conform to RFC 2821 and related RFCs and MUST NOT lead to mail loops. |
| USAB-30 | Mobile-email Enabler SHOULD support activation/deactivation of auto-reply from the client. Automatically generated replies MUST conform to RFC 2821 and related RFCs and MUST NOT lead to mail loops. |
| USAB-31 | Mobile-email Enabler MUST support replying to messages by using the email account that the original message was received on. |
| USAB-32 | Mobile-email Enabler SHOULD support organization of the retrieved email messages according to their source email account. |
| USAB-33 | The mobile enabler MUST support the user ability to forward only a selection of the attachments of an e-mail with attachments, without downloading the attachments to the client. |
| USAB-34 | The mobile e-mail enabler MUST provide mechanisms to access any desirable email part even when the email size is beyond the limit imposed on the size of the emails that can be delivered to mobile devices while remaining within the size constraints of the part to be downloaded |
Table 5: High-Level Functional Requirements – Usability Items
Interoperability
| Label | Description |
| IOP-1 | Data exchanges between the client and server, such as Events, sending Mail, reconciliation, attachment manipulation MUST remain functional in the presence of firewalls between the mobile e-mail client and the users e-mail servers. |
| IOP-2 | When used, events sent from the server to the client to announce or describe new e-mail MUST be network neutral. |
| IOP-3 | When used, events accessed by the client from the server to announce or describe new e-mail MUST be network neutral. |
| IOP-4 | Exchanges to provide e-mail arrived on server to the client MUST be network neutral. |
| IOP-5 | Exchanges to reconcile the client after a e-mail event on the server MUST be network neutral. |
| IOP-6 | Exchanges to access or manipulate attachments MUST be network neutral. |
| IOP-7 | It MUST be possible to send e-mail from the e-mail server assigned to the user (e.g. not another SMTP server in another domain). |
| IOP-8 | Sending e-mail from an assigned e-mail server MUST be network neutral. |
| IOP-9 | Sending e-mail events on the client to the e-mail server MUST be network neutral. |
| IOP-10 | The mobile e-mail enabler MUST allow the e-mail repository on the mobile client to be synchronized with the appropriate backend server: · Sometimes via the OMA Mobile e-mail enabler specifications (between client and server) · Sometimes via the OMA DS specifications for e-mail between the client and another client, that it be o Connected to the server o Previously synchronized with the server and later re-synchronized with the server |
| IOP-11 | The e-mail enabler MUST support server-side adaptation of attachment to the device user by user. |
| IOP-12 | The server-side adaptation MUST be capable of being controlled by the client (e.g., with smart or intermediate clients). |
| IOP-13 | The design of the mobile e-mail enabler specifications SHOULD consider and aim at interoperability or gracefully degradation with relevant e-mail standards. |
| IOP-14 | The number of optional features in the Mobile E-mail enabler specifications SHOULD be minimised, while allowing efficient implementation of both consumer and enterprise mobile e-mail solutions. |
| IOP-15 | Server-side adaptation MUST preserve the ability of accessing e-mail via other channels (e.g. via other e-mail clients). |
| IOP-16 | Server-side adaptation MUST preserve the original e-mails and attachment stored in the e-mail server |
Table 6: High-Level Functional Requirements – Interoperability Items
Privacy
| Label | Description |
| PRIV-1 | The mobile e-mail enabler MUST allow the mobile client to be protected by the same privacy protection rules / solutions as applied on the server (e.g. filtering rules, privacy alert detections on outgoing e-mail, read/unread notice interception). |
| PRIV-2 | The mobile e-mail enabler MUST support the use of privacy tools that require user’s confirmation before allowing some e-mail events to take place. |
Table 7: High-Level Functional Requirements – Privacy Items
Overall System Requirements
| Label | Description |
| SYSREQ-1 | The mobile e-mail enabler MUST be robust enough to operate normally and useably when there is a intermittent or unreliable connection between the client and server. |
| SYSREQ-2 | The mobile e-mail enabler security (authentication, authorization, confidentiality, integrity) MUST operate and be usable in the presence of intermittent or unreliable connectivity (loss of connectivity, loss of network transport packets and reconnect). |
| SYSREQ-3 | The mobile e-mail enabler MUST NOT rely on the storage of email data in intermediate systems outside the e-mail server domain or the terminal. |
| SYSREQ-4 | Mobile e-mail enabler MUST permit highly scalable end-to-end implementations. |
| SYSREQ-5 | The mobile e-mail enabler SHOULD allow optimized implementations on constrained devices (e.g. power consumption, CPU overhead, memory and storage requirements). |