|-------| RFC-822/MIME | |
| | |---------------------------| MTA |
| | | mail submission -> | |(E)SMTP
Telephone--|TUI|TUA| |------| |-----to
| | | IETF protocol | | |another
| | |---------------------------| MS | | mail
|-------| <- mail retrieval | | | server
|-------------|
mail client email server
|- voice mail system-| |-mail server-|
Mail client consists of: TUI (Telephone User Interface) and
TUA (Telephone User Agent)
Communication between TUI and TUA is proprietary.
Email server consists of: MS (Mail Store) and
MTA (Message Transfer Agent)
Communication between MS and MTA is proprietary.
4.2.2. Multi-Modal Clients
Multi-modal clients offer the advantage of coordinated voice and data
modes of user interaction. Architecturally, the multi-modal client
can be considered the union two user agent components -- one a TUI
client, the other a simple GUI client. See the next figure. The
Graphical User Agent (GUA) helps maintain the text display while the
Telephone User Agent (TUA) acts on behalf of the TUI functionality.
This model is the norm with cellular devices supporting data access
because historically they evolved from cell phones to which a data
channel was added. The presentation of multiple complementary modes
of interaction gives end-users their choice of the most convenient
and natural working mode for a particular task. There are other
situations where a multi-modal model is appropriate. (For example, a
telephone sales unit needs to provide a voice (telephone) mode and
conventional desktop PC mode of interaction at the same time in an
integrated manner.)
A major issue in the design of multi-modal clients -- the need to
synchronize the component user agents making up a client -- is only
addressed by LEMONADE to a limited extent in Section 6.3.
4.2.3. WUI
The Wireless User Interface is functionally equivalent to a
conventional email client on a personal workstation, but is optimized
for clients on handheld tetherless devices. Factors needing
consideration include limited memory and processing power. Limited
bandwidth is also relatively high cost. As already alluded to above,
in many cases (e.g., cellular devices), the mobile client is
multi-modal. So WUIs can be modeled as resource-and-link-limited
multi-modal clients.
These terminals require the use of protocols that minimize the number
of over-the-air transactions and reduce the amount of data that need
be transmitted over the air overall. Such reduction in over-the-air
transmission is a combination of more efficient protocol interaction
and richer message presentation choices, whereby a user may more
intelligently select what should be downloaded and what should remain
on the server.
Although not an explicit goal, providing equivalent or superior
functionality to the wireless MMS service [43] (as defined by 3GPP,
3GPP2, and the OMA) is desirable.
Proposed Wireless User Interface (WUI)/Multi-modal Clients
|wireless GUI client| email server
(E)SMTP (client-server) |-------------|
|-------| RFC-822/MIME | |
| | |---------------------------| |
| | | mail submission -> | |(E)SMTP
-|GUI|GUA| | |-----to
| | | | IETF standard protocol |------------ |another
| | | |----------------------------to MS below| | mail
| |-------| <- mail retrieval |------------ | server
| | | |
Handheld | | | |
Device WUI | | MTA |
| | | |
| | | |
| |-------| RFC-822/MIME | |
| | | |---------------------------| |
| | | | mail submission -> | |
-|TUI|TUA| |------| |
| | | IETF standard protocol | | |
| | |---------------------------| MS | |
|-------| <- mail retrieval | | |
|-------------|
TUI client voice mail server
|----------------voice messaging system ----------------|
|------WUI-----| |---mail server---|
Wireless GUI client consists of: GUI (Graphical User Interface) and
GUA (Graphical User Agent)
Communication between UI and UA is proprietary.
TUI client consists of: TUI (Telephone User Interface) and
TUA (Telephone User Agent)
Communication between TUI and TUA is proprietary.
Communication between GUA and TUA is proprietary.
Mail (email and voice mail) server consists of:
MS (Mail Store) and
MTA (Message Transfer Agent)
Communication between MS and MTA is proprietary.
5. General Principles
This is a list of principles to guide the design of extensions for
Internet Messaging systems and protocols to support diverse
endpoints.
5.1. Protocol Conservation
5.1.1. Reuse Existing Protocols
To the extent feasible, the enhanced messaging framework SHOULD use
existing protocols whenever possible.
5.1.2. Maintain Existing Protocol Integrity
In meeting the requirement "Reuse Existing Protocols"
(Section 5.1.1), the enhanced messaging framework MUST NOT redefine
the semantics of an existing protocol.
Extensions, based on capability declaration by the server, will be
used to introduce new functionality where required.
Said differently, we will not break existing protocols.
5.2. Sensible Reception/Sending Context
5.2.1. Reception Context
When the user receives a message, that message SHOULD receive the
treatment expected by the sender. For example, if the sender
believes he is sending a voice message, voice message semantics
should prevail to the extent that the receiving client can support
such treatment.
5.2.2. Sending Context
When the user sends a message, he SHOULD be able to specify the
message context. That is, whether the network should treat the
message as an text message, voice message, video message, etc.
Again, this can only be complied with to the extent that the
infrastructure and receiving client can provide such treatment. In
practice, this would imply that the message should be in the form
desired by the sender up to delivery to the receiving client.
5.3. Internet Infrastructure Preservation
The infrastructure SHOULD change only where required for new
functionality. Existing functionality MUST be preserved on the
existing infrastructure; that is, all extensions must be backward
compatible to allow for the gradual introduction of the enhancements.
Messages created in an enhanced messaging context MUST NOT require
changes to existing mail clients. However, there may be a
degradation in functionality in certain circumstances.
The enhanced messaging framework MUST be able to handle messages
created in a non-enhanced messaging context; for example, a simple,
RFC822 [2] text message.
5.4. Voice Requirements (Near Real-Time Delivery)
On the retrieval side, there are significant real-time requirements
for retrieving a message for voice playback. More than any other
media type, including video, voice is extremely sensitive to
variations in playback latency. The enhanced messaging framework
MUST address the real-time needs of voice.
5.5. Fax Requirements (Guaranteed Delivery)
Fax users have a particular expectation that is a challenge for
enhanced Internet messaging. A person who sends a fax expects the
recipient to receive the fax upon successful transmission. This
clearly is not the case for Internet Mail.
Addressing this need is not in the scope of LEMONADE.
5.6. Video Requirements (Scalable Message Size)
Video mail has one outstanding feature: Video messages are
potentially large! The enhanced messaging framework MUST scale for
very large messages. Streaming from the server to the client, in
both directions, MUST be supported.
6. Issues and Requirements: TUI Subset of WUI
6.1. Requirements on the Message Retrieval Protocol
IMAP [10] is the Internet protocol for rich message retrieval and
manipulation. The project MUST limit itself to extending IMAP where
necessary and MUST not create a new protocol.
6.1.1. Performance Issues
6.1.1.1. Real-Time Playback
The real-time playback of a voice message MUST be supported so that
the user experience does not differ noticeably from that of a
conventional voice messaging system.
Possible solutions for this include making use of the existing
incremental download capability of the IMAP protocol, or utilizing a
companion streaming protocol.
The IMAP protocol itself does not provide streaming by the strict
definition of the term. It does provide for the incremental download
of content in blocks. Most IMAP clients do not support this behavior
and instead download the entire contents into a temporary file to be
passed to the application.
There are several approaches to achieve real-time playback. The
first approach is to implement an IMAP client that can pass data
incrementally to the application as it is received from the network.
The application can then read bytes from the network as needed to
maintain a play buffer. Thus, it would not require the full download
of contents. This approach may require server-side development to
support partial download efficiently (i.e., to avoid re-opening files
and positioning to the requested location).
Alternatively, the client can use the proposed IMAP channel extension
[32] to request that the server make the selected content available
via an alternate transport mechanism. A client can then ask the
server to make the voice data available to the client via a streaming
media protocol such as RTSP. This requires support on the client and
server of a common streaming protocol.
6.1.1.2. Avoid Content-Transfer-Encoding Data Inflation
Another important performance optimization is enabling the transport
of data using more efficient native coding rather than text-like
content-transfer encodings such as "base 64".
Standard IMAP4 uses a text-based data representation scheme where all
data is represented in a form that looks like text; that is, voice
data must be encoded using "base 64" into a transport encoding that
adds 30% to the size of a message. Downloading or appending large
messages to the server already uses substantial bandwidth.
Possible Solutions:
Where IMAP channel is appropriate, the external channel may be binary
capable; that is, the external access may not require re-encoding.
Mechanisms such as HTTP [24], FTP, or RTSP are available for this
download.
The IMAP binary extension standards proposal [31] extends the IMAP
fetch command to retrieve data in the binary form. This is
especially useful for large attachments and other binary components.
Binary in conjunction with a streaming client implementation may be
an attractive alternative to the channel extension.
6.1.2. Functional Issues
6.1.2.1. Mailbox Summary Support
The common TUI prompt, "you have two new voice messages, six unheard
messages, and one new fax message", requires more information than is
conveniently made available by current message retrieval protocols.
The existing IMAP protocol’s mailbox status command does not include
a count by message context [26] [27]. A possible solution is for the
mail server to keep track of these current counters and provide a
status command that returns an arbitrary mailbox summary. The IMAP
status command provides a count of new and total messages with
standardized attributes extracted from the message headers. This
predetermined information does not currently include information
about the message type. Without additional conventions to the status
command, a client would have to download the header for each message
to determine its type, a prohibitive cost where latency or bandwidth
constraints exist.
6.1.2.2. Sort by Message Context Support
This functionality is required to present new voice messages first
and then new fax messages within a single logical queue as voice
mailboxes commonly do. Again, this is a question of convenience and
performance. Adequate performance may only be possible if the mail
server provides a sort by context or maintains a set of virtual
mailboxes (folders) corresponding to message types as for "Mailbox
Summary Support", Section 6.1.2.1.
IMAP does not support this directly. A straightforward solution is
to define an extensible sort mechanism for sorting on arbitrary
header contents.
6.1.2.3. Status of Multiple Mailboxes Support
Extension mailbox support requires the ability to efficiently status
a mailbox other than the one currently logged into. This facility is
required to support sub-mailboxes, where a common feature is to check
whether other sub-mailboxes in the same family group have new
messages.
Current mechanisms are limited to logging into each of set of
mailboxes, checking status, logging out, and repeating until all
sub-mailboxes are processed.
6.1.2.4. Specialized Mailbox Support
Applications that provide features such as check receipt, deleted
message recovery, resave, and others, require the ability to access
messages in predetermined mailboxes with specific behaviors (e.g.,
Outbox, Sent Items, Deleted Items, Expired Items, Drafts).
IMAP provides only a single standardized folder, the inbox. This
functionality does not require new protocol additions per se, but
standardized usage and naming conventions are necessary for
interoperability. This functionality requires that the server
provide the underlying logic to support these special folders,
including automatic insertion, scheduled copying, and periodic
deletion.
6.1.2.5. CLID Restriction Indication/Preservation
Many calling features are dependent on collected caller-ID
information. Clients -- such as the TUI and other service supporting
user agents (e.g., WEB and WAP servers) -- may need trusted access to
restricted caller-ID information for such purposes as callback.
Untrusted clients must not be permitted to receive this information.
A mechanism for establishing "trust" between appropriate clients and
the server is required to restrict delivery of this information to
the end-user only as allowed.
Further, when messages are sent between servers within a network, a
means of communicating trust is needed so that the identity of the
sender can be preserved for record-keeping and certain features while
ensuring that the identity is not disclosed to the recipient in an
inappropriate way.
6.1.2.6. Support for Multiple Access to Mailbox
If the telephone answering application client uses IMAP4 for greeting
access and message deposit, it is essential that the server provide
support for simultaneous login. It is common in voice mail for an
incoming call to be serviced by the telephone answering application
client at the same time the subscriber is logged into her mailbox.
Further, new applications such as WEB and WAP access to voice mail
may entail simultaneous login sessions, one from the TUI client and
one from the visual client.
The existing standard does not preclude multiple accesses to a
mailbox, but it does not explicitly require support of the practice.
The lack of explicit support requires the server and client to adhere
to a common set of practices and behaviors to avoid undesirable and
unpredictable behaviors. RFC2180 [29] describes a candidate set of
conventions necessary to support this multiple-access technique. It
or some other method MUST be standardized as part of LEMONADE.
6.2. Requirements on the Message Submission Protocol [22]
6.2.1. Forward without Download Support
It is common to forward messages or to reply to messages with a copy
of their attached content. Today such forwarding requires the sender
to download a complete copy of the original message, attach it to the
reply or forward message, and resubmit the result. For large
messages, this represents a substantial amount of bandwidth and
processing. For clients connected via long-thin pipes, alternatives
are required.
One approach is to define an extension to message submission to
request the submission server to resolve embedded URLs within a
message before relaying the message to the final destination. This
approach is referred to as the pull approach because the message
submission server must pull data from the IMAP server.
Another approach is to add a limited message assembly and submission
capability to the IMAP server. This approach muddies the distinction
between the message submission protocol and that for message storage
and retrieval (IMAP) because now message submission may be a side
effect of message store commands. This approach is referred to as
the push approach because in this case the IMAP server pushes data to
the message submission server.
A detailed analysis of which of the two approaches is preferable as
well as implementation details of both can be found in references
[36], [37], [38], [39], [40], and [41].
6.2.2. Quota by Context Enforcement
It is common in a unified messaging system to offer separate quotas
[11] for each of several message contexts to avoid the condition
where a flood of email fills the mailbox and prevents the subscriber
from receiving voice messages via the telephone. It is necessary to
extend the protocols to support the reporting of the "mailbox full"
status based on the context of the submitted message.
An obvious security issue needing consideration is the prevention of
the deliberate misidentification of a message context with the
intention of overflowing a subscriber’s mailbox. It is envisioned
that the message submission protocol will require the authentication
of trusted submission agents allowing only those so authorized to
submit distinguished messages.
Voice mail system mailboxes commonly contain voice and fax messages.
Sometimes, such systems also support email messages (text, text with
attachments, and multimedia messages) in addition to voice messages.
Similar to the required sort by message context, quota management is
also required per message context.
One possible use case is the prevention of multiple (large) messages
of one type (e.g., email messages) from consuming all available
quota. Consumption of all quota by one type prevents the delivery of
other types (e.g., voice or fax messages) to the mailbox.
One possible approach is to define a mechanism whereby a trusted
client can declare the context of a message for the purpose of
utilizing a protected quota. This may be by extensions to the
SMTP-submit or LMTP[35] protocols.
6.2.3. Future Delivery Support with Cancel
Traditionally messages sent with "future delivery" are held in the
recipient’s client "outbox" or its equivalent until the appointed
submission time. Thin clients used with TUIs do not have such
persistent storage or may be intermittently connected and must rely
upon server-based outbox queues.
Such support requires extensions to message submission protocols to
identify a message as requiring queuing for future delivery.
Extensions to IMAP4 or SMTP are required for viewing and manipulating
the outbound queue, for such purposes as canceling a future message.
Server support for managing such a queue is required so that messages
are sent when they are intended.
Some of the architectural issues here are the same as those in
"Forward without Download Support" (Section 6.2.1).
6.2.4. Support for Committed Message Delivery
Voice messaging service has provided a high degree of reliability and
performance for telephone answering messages. The expectation is
that once the caller has hung up, the message is in the mailbox and
available for review. The traditional Internet mail architecture
suggests these messages should be sent to the mailbox via SMTP. This
approach has two limitations. The first and most manageable is that
the message forwarding may take more time than is tolerable by the
subscriber. The second is that the message may fail to be delivered
to the mailbox. Because there is no way to return notice to the
caller, the message is "lost".
The standards community is working on an alternative to SMTP called
Local Message Transport Protocol (LMTP[35]). This protocol addresses
a number of limitations in SMTP when used to provide atomic delivery
to a mailbox. The failure modes in this proposal are carefully
controlled, as are issues of per-message quota enforcement and
message storage quota-override for designated administrative
messages.
An alternative approach is to misuse the IMAP protocol and use an
IMAP-based submission mechanism to deposit a message directly into
the recipient’s inbox. This append must be done by a special
super-user with write permissions into the recipient mailbox.
Further, the message store must be able to trigger notification
events upon insertion of a message into the mailbox via the Append
command. The historic limitation on using IMAP4 for message sending
involves the inability of IMAP to communicate a full SMTP envelope.
For telephone answering, these limitations are not significant.
However, the architectural issues raised by this approach are
significant. See "Forward without Download Support" (Section 6.2.1).
6.3. Requirements on Message Notification
Clients keep local information about the IMAP store. This