WinCE OS architecture supports a "local message store" which can be used by any application to send/retrieve messages through a set of defined APIs.
Each message in the local message store has many attributes associated with it, such as the "Mail Folder" it belongs to (Inbox, Sent Items, ...), the "Mail Transport Service" responsible for handling the message (SMTP/POP3, Fax, EMSD,...), and other miscellaneous attributes.
WinCE OS architecture also supports the concept of a "Mail Transport Service Provider" which works as an abstraction layer and handles sending/receiving of messages marked as handled by that "Mail Transport Service."
The "MSInetEmail" Mail Transport Service Provider, which implements the POP3/SMTP message retrieval/submission protocols, is included with the base WinCE system. Consequently, for users with mailboxes on ISPs, Intranets, etc., WinCE offers a plug-and-play e-mail solution over dial-up IP connections.
The "Inbox" application allows the user to choose which Mail Transport Service should be selected as the default one at any given time. In the WinCE architecture, the EMSD software would be just another "Mail Transport Service" next to "SMTP/POP3", "IMAP", "Fax" and so on.
EMSD is layered on top of UDP datagram service offered by the IP stack and as such, is oblivious to the how the IP connectivity is achieved. In other words, whether a direct serial link, a wireline modem or a CDPD modem is used is transparent to the EMSD layer. In fact, much of EMSD development and testing is done over LAN and direct serial links by simply adjusting a few tunable parameters.
The following block diagram illustrates the components involved as well as the layering of services.
As illustrated in Figure 15.1, upper and lower interfaces used by the EMSD user agent correspond to fully published WinCE APIs defined in WinCE development environment (SDK). It is also visible that the EMSD Mail Service Transport Provider is a peer to the Microsoft provided MSInetMail Mail Service Transport Provider. The WinCE published APIs enable any third party to develop a Mail Service Transport Provider.
Today, all CDPD modems, including the PCMCIA types, expose a "SLIP" interface on the serial port they are associated with. Some newer CDPD modems have started supporting the "PPP" interface as well. Manufacturers of existing modems are also developing new firmware to add PPP support to their modems. WinCE comes with a built-in IP stack and offers Winsock v1.1 subset functionality. Today, off-the-shelf, WinCE supports only "PPP" over serial links, however add-on drivers for SLIP support are appearing from third parties.
For those CDPD modems supporting PPP, WinCE integration is straightforward. As far as WinCE is concerned, there is no difference between connecting to the CDPD network via that CDPD modem and connecting to an Internet ISP using a standard PCMCIA wireline modem: the same PPP interface is used.
There are many scenarios in which EMSD can be used to provide messaging services, but for the purposes of this paper, we will consider only the scenario where the following are true:
In all cases, the "EMSD Mail Transport Service Provider" in the WinCE will communicate directly with an EMSD Message Transfer Agent (MTA) which functions as a gateway between EMSD and SMTP. In other words, messages exchanged between the WinCE and the EMSD MTA are in the efficient EMSD format (in the airlink where EMSD's attributes are needed). The EMSD MTA handles translating EMSD format messages to the Internet format (RFC-822) and sending them on, or translating incoming Internet messages destined at the EMSD WinCE node to EMSD format and handing them over using EMSD protocols.
The EMSD MTA can reside anywhere on the Internet, including the CDPD service provider, at an ISP or as Customer Premise Equipment (CPE) at the customer site. Because EMSD MTAs maintain their own subscriber base, all of the above schemes can be deployed simultaneously. For example, The Neda Customer Premise Message Center (http://www.neda.com/products/ETWP/DataSheets/etwp-cpmc-solaris.fm5.pdf) was designed as a CPE MTA.
When a user is going mobile, he/she can initiate forwarding of all or certain classes of messages (for example all URGENT messages) to the assigned EMSD address. A mailbox sorter scheme similar to the "Procmail" utility fits well into this model.
If the system where the user's mailbox resides is EMSD-aware or is the node where the EMSD-MTA entity is running, then a variety of features can be included. An example would be setting up the attributes of EMSD forwarding on the fly and delivering a message to a user only once...
All messages originated from the mobile WinCE unit would simply be sent via EMSD to the EMSD-MTA without any secondary filter processing. Filter processing at the user mailbox level is relevant only for delivery of messages coming from the Internet destined to the EMSD user.
