1. Intellectual Property Rights
OMA-MEM R01-Mobile_ _RD_Pres_Lemonade Overview of Mobile RD
Submitted To: OMA - MEM
Date: 23 Sep 2005
Availability: Public OMA Confidential
Contact: Stéphane H. Maes,
Source: OMA - MEM X
USE OF THIS DOCUMENT BY NON-OMA MEMBERS IS SUBJECT TO ALL OF THE TERMS AND CONDITIONS OF THE USE AGREEMENT (located at AND IF YOU HAVE NOT AGREED TO THE TERMS OF THE USE AGREEMENT, YOU DO NOT HAVE THE RIGHT TO USE, COPY OR DISTRIBUTE THIS DOCUMENT.
THIS DOCUMENT IS PROVIDED ON AN "AS IS" "AS AVAILABLE" AND "WITH ALL FAULTS" BASIS.
Intellectual Property Rights
Members and their Affiliates (collectively, "Members") agree to use their reasonable endeavours to inform timely the Open Mobile Alliance of Essential IPR as they become aware that the Essential IPR is related to the prepared or published Specification. This obligation does not imply an obligation on Members to conduct IPR searches. This duty is contained in the Open Mobile Alliance application form to which each Member's attention is drawn. Members shall submit to the General Manager of Operations of OMA the IPR Statement and the IPR Licensing Declaration. These forms are available from OMA or online at the OMA website at

2. Reasons for Contribution
This contribution provides an overview of the mobile enabler RD (Requirement Document) to be presented at the OMA MEM / IETF Lemonade joint workshop.

3. OMA Mobile E-mail Enabler Status
The latest version of mobile enabler RD is OMA-RD-Mobile -V1_ D
It can be found at
Status:
Updated since the previous liaison with Lemonade WG
Completed formal review
Comments / questions received from IETF Lemonade (OMA-MEM ILS-regarding-MWG-MEM-RD) have considered and addressed.
Submitted for agreement by REQ WG (Target Sept 29, 2005):
See for package (including RDRR).
Will be submitted for Candidate approval to OMA TP (R&A) after REQ agreement (before Sydney meeting – October 17-21, 2005)
RD is still subject to revisions. Comments are still welcome

4. Scope and definitions
Mobile is defined as an enabler optimized to support usage in mobile devices and wireless networks.
The RD focuses on requirements for the enabler specifications rather than for particular implementations of those:
Some feedback from LEMONADE addressed implementations
The RD does not design the solution:
Some feedback from LEMONADE addressed technical solutions
Mobile Enabling technologies that facilitate end-to-end application level interoperable transactions (e.g. submission, retrieval, notification etc) to and from mobile devices.
Target both consumer and corporate mobile
Enabler focus:
Between client and server

5. Main Use Cases (1/4)
Note: OMA RDs do not expect an exhaustive list of use cases
Receiving an on the go:
Some highlights:
New arrives in servers
It is received on mobile client quasi-instantaneously based on settings preferences (whole or portions of ; adapted or not)
Enterprise and Non-enterprise users
Receiving a server event on the go:
events from the server
Viewing attachments on the go:
Attachment adaptation / transcoding (known by server or requested by client)
View attachment

6. Main Use Cases (2/4) Sending emails on the go:
Some highlights:
Sending an from correct SMTP server
Offline / intermittent connectivity
Filtering rule changes while mobile:
User dynamically changes a filter (add a sender from who notifications / new s should be received)
DS synchronization between clients:
3-way pair wise synchronization (e.g. Phone, laptop and server)

7. Main Use Cases (3/4) Email with Attachment:
Some highlights:
Details about attachments
Selectively download part or all of attachments if not yet downloaded
Download more
Forwarding without Downloading Attachments:
Forward without download with server-side re-composition including edits
Selection of what attachment to forward
Configuring additional accounts to be accessed:
Support multiple accounts possibly from different service providers

8. Main Use Cases (4/4)
Replying to messages that are retrieved from different accounts:
Some highlights:
Determines what account / server to use to send

9. Additional Use Cases (1/2)
Replying to messages that are retrieved from different accounts:
Some highlights:
Determines what account / server to use to send
Client Events:
Reflecting client events to server
Offline / intermittent connectivity
Filtering Rules:
Filtering rules on:
Events

10. Additional Use Cases (2/2)
Replying or Forwarding to s 'On the Go':
Some highlights:
User can edit text and attachments
Can edit any portion including address
Can send to server only differences
Configuring Auto-Reply Message:
Set auto-reply for accounts while mobile

11. High-Level Functional Requirements (1/2)
Label
Description
Comment
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:·
Events sent from the server to the client or accessed by the client to announce or describe new
Exchanges to deliver new from the server to the client
Events sent from the server to the client to announce or describe events on the server
Events accessed by the client from the server to announce or describe events on the server
Exchanges to reconcile the client after a event on the server
Exchanges to access or manipulate attachments
Sending from an assigned server
Sending events on the client to the server
Editorial

12. High-Level Functional Requirements (2/2)
HLF-2
The mobile enabler MUST support both push ( events are pushed to the client) and pull (client accesses events)
New
HLF-3
The mobile enabler SHOULD define a minimum set of interoperable media types and formats
HLF-4
The mobile enabler MUST support optimizations for wireless environments

13. Security Requirements (1/2)
Label
Description
Comments
SEC-1
The mobile enabler MUST support integrity and confidentiality between client and server when exchanging data and event notifications
Editorial combination.No statement on how
SEC-2
Exchanges to provide new arrived on server to the client MUST support confidentiality and integrity
Remove end to end
SEC-3
Exchanges to reconcile the client after an event on the server MUST support confidentiality and integrity
SEC-4
Exchanges to access or manipulate attachments MUST support confidentiality and integrity
SEC-5
Exchanges to send from the assigned server MUST support confidentiality and integrity
SEC-6
events sent from the client to the server MUST support confidentiality and integrity
SEC-7
The client MUST be able to be authenticated by the server
Editorial

14. Security Requirements (2/2)
The server MUST be able to be authenticated by the client
Editorial
SEC-9
The mobile enabler MUST support content screening
SEC-10
The mobile enabler MUST support spam protection
Re-phrased
SEC-11
The mobile enabler MUST support virus protection
New (re-org/clarification of others)
SEC-12
The mobile enabler MUST support protection against denial of service (DoS) attacks
SEC-13
It MUST be possible to prevent unauthorized applications from requesting s to be sent from the mobile client
New
SEC-14
It MUST be possible to protect data in the mobile enabler from unauthorized access (user or device)
Re-org

15. Charging Requirements
Label
Description
Comments
CHRG-1
In order to support charging for traffic, the mobile enabler SHOULD provide ways to identify mobile exchanges (events, access, sending and synchronization) as data exchanges, even when there is a secure connection between the client and server
Editorial
CHRG-2
In order to support charging for traffic, the mobile enabler SHOULD provide ways to identify mobile data exchange characteristics (e.g. message sizes, number of recipients, etc.)., even when there is a secure connection between the client and server
New

16. Administration and Configuration Requirements
Label
Description
Enabler Release
ADMIN-1
It MUST be possible to provision the mobile client, based on any combination of who the user is and what the device is
Re-phrased / editorial
ADMIN-2
It SHOULD be possible for user preferences/filters/settings to follow the user across devices, when used sequentially
Re-phrased / split
ADMIN-3
It MAY be possible for user references/filters/settings to follow the user across devices, when used simultaneously
New as result of split
ADMIN-4
Authorized principals MUST be able to configure the settings of the user preferences/filters/configurable settings for a particular user -
ADMIN-5
The mobile enabler MUST support the deletion by a remote, authorized principal of data on a mobile device
Rephrased
ADMIN-6
The mobile enabler MUST support administration of authorized users and devices
New
ADMIN-7
It MUST be possible for a user to view, edit and reset settings of a mobile client

17. Usability Requirements (1/5)
Label
Description
Comments
USAB-1
The mobile enabler SHOULD minimize event propagation delays and MUST NOT impose excessive delays
Editorial
USAB-2
The mobile enabler SHOULD minimize delays in accessing messages and MUST NOT impose excessive delays
USAB-3
When downloading an attachment, the mobile enabler MUST allow the client to be able to provide an indication of the estimated download time needed to complete the download of the attachment
Re-phrased
USAB-4
When network connectivity is available, s SHALL be sent from the client to the server according to user preference or client settings, if configurable
USAB-5
When connectivity is not available or drops, the user MUST be able to compose the message and have it stored on the device
USAB-6
When connectivity is re-established stored messages MUST be sent as soon as possible
New
USAB-7
When network connectivity is available, events on the client SHALL be sent to the server according to user preferences if configurable, or client settings
USAB-8
When connectivity is not available or drops, events on the client that may take place MUST be stored on the client until connectivity becomes available and then sent to the server as soon as possible.

18. Usability Requirements (2/5)
The mobile enabler MUST allow the user to set filtering rules based on
header fields
Mailbox folder options.
Spam score.
This is a non exhaustive list and for example only.
Rephrased
USAB-10
The mobile enabler MUST allow the user to change filtering rules on his mobile client.
USAB-11
The mobile enabler MUST support:
Different methods for notifying the client about new s based on capabilities of the network
The ability for the user to select the transport method based on the capabilities of the client and network (e.g. SMS, Push, MMS etc)
The ability for the user to select if, when and how events are accessed by the client
Significant re-phrasing
USAB-12
The mobile enabler MUST support the use of a number of different means to transport notifications this could include SMS, MMS, WAP Push, SIP Notification, UDP, in band, polled)
Re-phrased
USAB-13
The user MUST have control of the result of new events on the client, e.g. the client could download:
Meta-data only
Portion of the
The whole without attachment
The whole with attachment
USAB-14
The user MUST be able to manually initiate access to that has arrived on the server but is not yet on the client
Editorial

19. Usability Requirements (3/5)
The user MUST be able to manually access more 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 with all attachments)
Editorial
USAB-16
Authorized principals MUST be able to select the ways that events are sent to or accessed by the mobile client and other settings that may affect the server behaviour
USAB-17
The mobile enabler SHOULD NOT require repetitive actions by the user for robustness to intermittent or unreliable connectivity
Re-phrased
USAB-18
The mobile enabler MUST enable the user to forward an partially downloaded (e.g. without attachment) without having to download the remainder to the client
USAB-19
The mobile enabler SHOULD minimize the amount of information that a user must provide to provision an client to access the assigned server
USAB-20
The mobile client MUST allow the user to reply to an partially downloaded without first having to download any part of the remainder of the to the client. It should be possible to include all of portions of the original whether downloaded or not in the reply message
Re-phrased (Qualified)
USAB-21
The mobile client MUST allow the user to edit a partially downloaded , for reply and/or forward and have the server send all the portions of the edited while minimizing the amount of data that is sent to the server (e.g. sending the differences)
USAB-22
The mobile client MUST be able to download all or portions of a message thereof that the user wants to edit when replying and/or forwarding an partially downloaded to the client while minimizing the amount of data that is sent to the server (e.g. sending the differences)
USAB-23
The mobile enabler MUST support selecting the account to which messages are submitted

20. Usability Requirements (4/5)
When replying to a list of addressees, the Mobile client MUST allow the user to edit the addresses without downloading or uploading the whole list of addresses and minimize the amount of data that is sent to the server
Re-phrased (clarification)
USAB-25
The mobile Enabler SHOULD support multiple accounts provided by the same or different service providers
USAB-26
The mobile Enabler MUST support configuration of account information for connection and filtering on a per-account basis
Editorial
USAB-27
The mobile Enabler SHOULD support definition of auto-reply messages for each filtered messages. Automatically generated replies should avoid mail loops (RFC 2821 and related RFCs)
Rephrased (English)
USAB-28
The mobile enabler SHOULD support activation/deactivation of auto-reply from the client. Automatically generated replies should avoid mail loops (RFC 2821 and related RFCs)
Rephrased (qualification)
USAB-29
The mobile enabler MUST support replying to messages by using the account that the original message was received on.
USAB-30
The mobile enabler SHOULD support identification of the source account of retrieved messages
Re-phrased (English)
USAB-31
The mobile enabler MUST support the user ability to forward only a selection of the attachments of an with attachments, without downloading the attachments to the client
USAB-32
The mobile enabler MUST provide mechanisms to access any desirable part even when the size is beyond the limit imposed on the size of the s that can be delivered to mobile devices while remaining within the size constraints of the part to be downloaded

21. Usability Requirements (5/5)
The mobile enabler SHOULD enable the user to recall an message
New
USAB-34
The mobile user MAY receive notifications of a success or failure of a recall request.
USAB-35
The mobile enabler MUST be able to estimate the size of each individual attachment (s)
USAB-36
It SHALL be possible to manually refresh the “inbox” to see if new s have been received
USAB-37
It SHALL be possible for an authorized principal to limit the refresh rate (accessing the inbox on the server to see if new s have been received)
USAB-38
The mobile enabler SHALL be able to identify URIs in messages
USAB-39
The mobile enabler SHOULD notify end-users of any processing errors
USAB-40
The mobile enabler MAY support multiple devices simultaneously

22. Interoperability Requirements (1/2)
Label
Description
Comments
IOP-1
Data exchanges between the client and server, such as events, sending , reconciliation, attachment manipulation MUST be compatible in the presence of intermediary network elements (e.g. firewalls, proxies) between the mobile client and the users servers
Re-phrased
IOP-2
When used, events sent from the server to the client to announce or describe new MUST be network neutral
Editorial
IOP-3
When used, events accessed by the client from the server to announce or describe new MUST be network neutral
IOP-4
Exchanges to provide arrived on server to the client MUST be network neutral
IOP-5
Exchanges to reconcile the client after an 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 from the server assigned to the user (e.g. not another server in another domain)

23. Interoperability Requirements (2/2)
IOP-8
Sending from an assigned server MUST be network neutral
Editorial
IOP-9
Sending events on the client to the server MUST be network neutral
IOP-10
If multiple mobile clients are synchronized with the mobile server, the mobile enabler MUST allow multiple-way synchronisation between the mobile server and all synchronised clients
Re-phrased significantly (same intent)
IOP-11
The 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 enabler specifications SHALL support interoperability with relevant standards (e.g. IMAP4, PoP3 and SMTP)
Re-phrased (clarification)
IOP-14
Server-side adaptation MUST preserve the ability of accessing via other channels (e.g. via other clients)
IOP-15
Server-side adaptation MUST preserve the original s and attachment stored in the server

24. Privacy Requirements PRIV-1
Label
Description
Comments
PRIV-1
The mobile 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 , read/unread notice interception)
Editorial
PRIV-2
The mobile enabler MUST support the use of privacy tools that require user’s confirmation before allowing some events to take place
PRIV-3
The mobile enabler MUST comply with OMA Privacy document as applicable
New

25. Overall System Requirements
Label
Description
Comments
SYSREQ-1
The mobile enabler MUST be robust enough to operate normally and useably when there is an intermittent or unreliable connection between the client and server
Editorial
SYSREQ-2
The mobile 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 enabler MUST NOT rely on the storage of data in intermediate systems outside the server domain or the terminal.
SYSREQ-4
The mobile enabler MUST permit scalable (e.g. to the number of users) end-to-end implementations
Re-phrased (clarification)
SYSREQ-5
The mobile enabler SHOULD allow optimized implementations on constrained devices (e.g. power consumption, CPU overhead, memory and storage requirements). See also OMA-RPT-ApplicationPerformance-v A for additional informative details

26. Additional Considerations
Technology implications are analyzed as part of the AD phase by MEM SWG.
AD phase is started with:
Logical architecture
Technology option analysis
Identification of dependencies