Network Working Group J. Wong, Ed. Request for Comments: 4416 Nortel Networks Category: Informational February 2006 Goals for Internet Email to Support Diverse Service Environments Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006).
AbstractThis document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process. The LEMONADE Working Group -- Internet email to support diverse service environments -- is chartered to provide enhancements to Internet mail to facilitate its use by more diverse clients. In particular, by clients on hosts not only operating in environments with high latency/bandwidth-limited unreliable links but also constrained to limited resources. The enhanced mail must be backwards compatible with existing Internet mail. The primary motivation for this effort is -- by making Internet mail protocols richer and more adaptable to varied media and environments -- to allow mobile handheld devices tetherless access to Internet mail using only IETF mail protocols. The requirements for these devices drive a discussion of the possible protocol enhancements needed to support multimedia messaging on limited-capability hosts in diverse service environments. A list of general principles to guide the design of the enhanced messaging protocols is documented. Finally, additional issues of providing seamless service between enhanced Internet mail and the existing separate mobile messaging infrastructure are briefly listed.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 6 3. Messaging Terminology and Simple Model (Client-to-Server Aspect Only) . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Messaging Transaction Models . . . . . . . . . . . . . . . 6 3.2. Mobile Messaging Transactions . . . . . . . . . . . . . . 7 3.2.1. Submission . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. Notification . . . . . . . . . . . . . . . . . . . . . 7 3.2.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . 8 4. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Existing Profiles . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Voice Messaging (VPIMv2) . . . . . . . . . . . . . . . 8 4.1.2. iFax . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.3. Internet Voice Mail (IVM) . . . . . . . . . . . . . . 9 4.2. Putative Client Profiles . . . . . . . . . . . . . . . . . 9 4.2.1. TUI . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. Multi-Modal Clients . . . . . . . . . . . . . . . . . 11 4.2.3. WUI . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. General Principles . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Protocol Conservation . . . . . . . . . . . . . . . . . . 13 5.1.1. Reuse Existing Protocols . . . . . . . . . . . . . . . 13 5.1.2. Maintain Existing Protocol Integrity . . . . . . . . . 13 5.2. Sensible Reception/Sending Context . . . . . . . . . . . . 13 5.2.1. Reception Context . . . . . . . . . . . . . . . . . . 13 5.2.2. Sending Context . . . . . . . . . . . . . . . . . . . 13 5.3. Internet Infrastructure Preservation . . . . . . . . . . . 14 5.4. Voice Requirements (Near Real-Time Delivery) . . . . . . . 14 5.5. Fax Requirements (Guaranteed Delivery) . . . . . . . . . . 14 5.6. Video Requirements (Scalable Message Size) . . . . . . . . 14 6. Issues and Requirements: TUI Subset of WUI . . . . . . . . . . 14 6.1. Requirements on the Message Retrieval Protocol . . . . . . 14 6.1.1. Performance Issues . . . . . . . . . . . . . . . . . . 15 6.1.2. Functional Issues . . . . . . . . . . . . . . . . . . 16 6.2. Requirements on the Message Submission Protocol . . . . . 18 6.2.1. Forward without Download Support . . . . . . . . . . . 18 6.2.2. Quota by Context Enforcement . . . . . . . . . . . . . 19 6.2.3. Future Delivery Support with Cancel . . . . . . . . . 19 6.2.4. Support for Committed Message Delivery . . . . . . . . 20 6.3. Requirements on Message Notification . . . . . . . . . . . 20 6.3.1. Additional Requirements on Message Notification . . . 21 7. Issues and Requirements: WUI Mobility Aspects . . . . . . . . 21 7.1. Wireless Considerations on Email . . . . . . . . . . . . . 21 7.1.1. Transport Considerations . . . . . . . . . . . . . . . 21 7.1.2. Handset-Resident Client Limitations . . . . . . . . . 22 7.1.3. Wireless Bandwidth and Network Utilization Considerations . . . . . . . . . . . . . . . . . . . . 22
7.1.4. Content Display Considerations . . . . . . . . . . . . 23 7.2. Requirements to Enable Wireless Device Support . . . . . . 24 7.2.1. Transport Requirements . . . . . . . . . . . . . . . . 24 7.2.2. Enhanced Mobile Email Functionality . . . . . . . . . 24 7.2.3. Client Requirements . . . . . . . . . . . . . . . . . 25 7.2.4. Bandwidth Requirements . . . . . . . . . . . . . . . . 25 7.2.5. Media Handling Requirements . . . . . . . . . . . . . 25 8. Interoperation with Existing Mobile Messaging . . . . . . . . 27 8.1. Addressing of Mobile Devices . . . . . . . . . . . . . . . 27 8.2. Push Model of Message Retrieval . . . . . . . . . . . . . 27 8.3. Message Notification . . . . . . . . . . . . . . . . . . . 27 8.4. Operator Issues . . . . . . . . . . . . . . . . . . . . . 27 8.4.1. Support for End-to-End Delivery Reports and Message-Read Reports . . . . . . . . . . . . . . . . . 27 8.4.2. Support for Selective Downloading . . . . . . . . . . 27 8.4.3. Transactions and Operator Charging Units . . . . . . . 27 8.4.4. Network Authentication . . . . . . . . . . . . . . . . 28 8.5. LEMONADE and MMS . . . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 10.2. Informative References . . . . . . . . . . . . . . . . . . 32 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 37 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 38 Appendix C. IAB Note: Unified Notification Protocol Considerations . . . . . . . . . . . . . . . . . . . 38
4], , ) evolved to support networked computers with messages consisting of rich text plus attachments. o Voice mail systems utilized a client with a telephone-based or an answering machine style of user interface. The telephone network was used for transport of recorded voice messages. o Fax store-and-forward users interface with a fax machine using a modified telephone-based interface. Fax machines use the telephone network for transport of fax data via modems. o SMS (Short Message Service)  enabled users to send short text messages between their cellular phones using the SS7 call control infrastructure (, , , , ) for transport. In the recent past, IETF mail standards have evolved to support additional/merged functionality: o With MIME (, , , , , ), Internet mail transport was enhanced to carry any kind of digital data o Internet mail protocols were extended and profiled by VPIM (, , , ) and iFAX (, , , , , , ) so that enabled voice mail systems and fax machines could use the common email infrastructure to carry their messages over the Internet as an alternative to the telephone network. These enhancements were such that the user's experience of reliability, security, and responsiveness was not diminished by transport over the Internet. These successes -- making Internet mail transport the common infrastructure supporting what were separate messaging universes -- have encouraged a new vision: to provide, over the Internet, a single infrastructure, mailbox, and set of protocols for a user to get, respond to, and manipulate all of his or her messages from a collection of clients with varying capabilities, operating in diverse environments (,). The LEMONADE effort -- Internet email to support diverse service environments -- realizes this vision further by enabling Internet mail support for mobile devices and facilitating its interoperability with the existing mobile messaging universe.
In the recent past, the evolution of messaging standards for resource-limited mobile devices has been rapid: o In the cellular space, SMS was enhanced to EMS (Extended Message Service)  allowing longer text messages, images, and graphics. With an even richer feature set, MMS (Multimedia Messaging Service) (, , , , ) was developed as a lightweight access mechanism for the transmission of pictures, audio, and motion pictures. MMS protocols are based in part on Internet standards (both messaging and web ) as well as SMS. The cellular messaging universe is a separate infrastructure adapted to deliver appropriate functionality in a timely and effective manner to a special environment. o As well, the number of different mobile clients that need to be supported keeps proliferating. (e.g., besides cellular phones there are wireless-enabled PDAs, tablet computers, etc.) These resource-limited mobile devices are less powerful both in processing speed and display capabilities than conventional computers. They are also connected to the network by wireless links whose bandwidth and reliability are lower, latency is longer, and costs are higher than those of traditional wire-line links, hence the stress on the need to support adaptation to a whole different service environment. This document collects a number the issues impeding Internet mail protocols from directly supporting the mobile service environment. Considerations arising from these issues are documented, and in some cases possible approaches to solutions are suggested. It turns out that the enhancements to support mobile clients also offer benefits for some terminals in other environments. In particular, the enhancements address the needs of the following diverse clients: o A wireless handheld device with an email client -- a Wireless User Interface (WUI) mode of user interaction is dictated by the constraints of the mobile wireless handheld operating environment. o Telephone-based voice client -- a Telephone User Interface (TUI), this is the user mode offered by a POTS set * This is a subset of the WUI and is useful in other contexts. o A multi-modal messaging client providing a coordinated messaging session using display and audio modes simultaneously. (e.g., a system consisting of a PC with a phone, or a wireless phone with both a voice circuit and data channel requiring coordination). * This is also a subset of the WUI and is useful in other contexts.
The rest of this document is structured as follows: o A brief survey of messaging profiles - both existing and proposed. o A list of principles to be used to guide the design of Internet Messaging for diverse service environments. o Detailed discussion on enhancements to Internet mail protocols to support WUIs. o Some issues relating to the interoperation of enhanced Internet mail and the existing mobile messaging services. RFC2119 . 42].
figure depicts a simple client-server model (no server- to-server interactions are shown): (1) Message submission (2) Message notification (3) & (4) Message retrieval +-------+ +------+ +-------+ |Mail |-------(1)------>| |-----------(2)-------->|Mail | |Client | Submit msg | | Notification /|Client | +-------+ | | / +--+----+ | | / ^ | |<----------(3)-----+ / |Server| Retrieval request / | | / | | / | |-----------(4)-------+ | | Retrieval response | | +------+ Simple Messaging Model
All the larger mobile messaging systems implement a push model for the notification because data can be presented to the user without the user's experiencing network/transport latencies, and without tying up network resources for polling when there is no new data. Internet mail differs in that it has not yet seen the need for a standardized notification protocol. RFC3801  to RFC3803 , enable the transport of voice messages using the Internet mail system. The main driver for this work was support of IP transport for voice mail systems. As voice mail clients are accustomed to a higher degree of responsiveness and certainty as to message delivery, the functionality added by VPIMv2 includes Message Disposition
Notification and Delivery Status Message (, ). Voice media has also been added to multi-part message bodies. 16], , , , , ) enables the transport of fax using Internet mail protocols. This work defined the image/tiff MIME type. Support for fax clients also required extensions to Message Delivery Notification. RFC 3773 ) targets support for the interchange of voice messaging between the diverse components (clients as well as servers) in systems supporting voice mail. figure depicts the architecture of current voice mail systems implementing VPIMv2:
|-------------| |-------| RFC-822/MIME | | | | |---------------------------| MTA | | | | mail submission -> | |(E)SMTP Telephone--|TUI|TUA| |------| |-----to | | | Proprietary Protocol | | |another | | |---------------------------| MS | | email |-------| < - mail retrieval | | | server |-------------| mail client email server |----------------voice messaging system -------------| 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. It is proposed that the Proprietary Protocol be replaced with an IETF standard protocol: |-------------| |-------| 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.
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. 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.
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.
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.
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 , FTP, or RTSP are available for this download. The IMAP binary extension standards proposal  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. 26] . 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. Section 188.8.131.52. IMAP does not support this directly. A straightforward solution is to define an extensible sort mechanism for sorting on arbitrary header contents.
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 protocols.
Some of the architectural issues here are the same as those in "Forward without Download Support" (Section 6.2.1). 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).
When implemented over IMAP-based message stores, the voice mail client needs to be notified about these events. Furthermore, when other applications access/manipulate the store, these events need to be communicated to the mail client. In some cases, the client needs to notify the user immediately. In most cases, it is a question of maintaining client/application consistency. In the case of a multimodal client, it is especially important to provide a means of coordinating the client's different modal views of the state of the store. Email systems have traditionally polled to update this information. There may be advantages to an event-driven approach in some cases. The standards community is working on a standard for bulk server-to-client status notification. An example of such work is the Simple Notification and Alarm Protocol (SNAP) , which defines the expected behavior of the message store for various events, many of them triggered by IMAP commands. Appendix C).
It is also common in these environments that the device's IP address change within a session.
sensitive to the premium for wireless service. This results in an unwillingness to download large amounts of unnecessary data to the handset and the desire to be able to download only selected content. Section 7.1.2), wireless media and bandwidth issues (Section 7.1.1 and Section 184.108.40.206), and price sensitivity (Section 220.127.116.11).
This requirement is identical to the TUI requirement described in "Forward Without Download Support" (Section 6.2.1). Section 18.104.22.168). Section 22.214.171.124).
33]) may address this issue. Section 126.96.36.199). For example, a device that cannot display GIF format, and can only display WBMP, should get a WBMP image. Devices that cannot display a PDF file should get a text version of the file. The handset should control what transcoding, if any, is desired. It should be able to retrieve the original attachment without any changes. In addition, the device should be able to choose between "flavors" of the transcoding. ("Present the content as thumbnail image" is an example of such a specific media manipulation.) Again, work on ESMTP transcoding (CONNEG) may address this issue.
62] is prevalent in mobile messaging services to address recipient mobiles. Consideration should be given to supporting E.164 addressing for mobile devices in addition to RFC822 addressing. Section 6.3). Internet mail has not so far standardized a server-to-client notification protocol although most existing wireless mail systems use notification to avoid needless polling. Client-to-server notification is not within the LEMONADE charter. Section 6.2.4, but this is different.
positive end-to-end acknowledgement of delivery or non-delivery of messages already mentioned in Section 8.4.1. Note that billing is specifically outside the scope of the IETF. 48] ) defines seven interfaces labelled MM1 to MM7, as below:
3GPP MMS Reference Architecture (subset) |---------| |------------| wireless ||-------|| | | device || MMS || | |<- MM2 -> || USER |---------------------------| |--------- || AGENT |<- MM1 ->| | to ||-------|| | | another |---------| | | MMS | | relay/ |--------| | | server e.g., | | | | Email, |EXTERNAL| | | Fax, or| SERVER |--------------------------| | UMS | |<- MM3 ->| | |--------| | | | | |---------| | | |"FOREIGN"| | | | MMS |-------------------------| | | relay/ |<- MM4 ->| | | server | | | |---------| | | | MMS | |-------| |relay/server| | | | | | HLR |---------------------------| | | |<- MM5 ->| | |-------| | | | | |-------| | | | MMS | | | | USER |---------------------------| | | DBs |<- MM6 ->| | |-------| | | | | |-------| | | | MMS | | | | VAS |---------------------------| | | APPs |<- MM7 ->| | |-------| |------------| MMS - Multimedia Messaging Service UMS - Unified Messaging Service HLR - Home Location Register DB - Data Base VAS - Value Added Service APP - Application
The LEMONADE profile provides an enhanced IMAP mail retrieval protocol suitable for use at interfaces MM1 and MM3. In addition, if the wireless device uses a LEMONADE-enhanced IMAP user agent, the enhanced IMAP protocol can be used to access Internet mail directly, as below.
3GPP MMS Reference Architecture (subset) |---------| |------------| wireless ||-------|| | | device || IMAP || | |<- MM2 -> || USER || | |--------- || AGENT || | | to ||---^---|| | | another |----|---|| | | MMS | LEMONADE Enhanced IMAP and | | relay/ |---V----| SMTP | | server e.g., | | | | Email, |EXTERNAL| | | Fax, or| SERVER |--------------------------| | UMS | |<- MM3 ->| | |--------| | | | | |---------| | | |"FOREIGN"| | | | MMS |-------------------------| | | relay/ |<- MM4 ->| | | server | | | |---------| | | | MMS | |-------| |relay/server| | | | | | HLR |---------------------------| | | |<- MM5 ->| | |-------| | | | | |-------| | | | MMS | | | | USER |---------------------------| | | DBs |<- MM6 ->| | |-------| | | | | |-------| | | | MMS | | | | VAS |---------------------------| | | APPs |<- MM7 ->| | |-------| |------------| MMS - Multimedia Messaging Service UMS - Unified Messaging Service HLR - Home Location Register DB - Data Base VAS - Value Added Service APP - Application
 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.  Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.  Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.  Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.  Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, November 1996.  Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.  Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
 Myers, J., "IMAP4 QUOTA extension", RFC 2087, January 1997.  Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.  Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.  Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub- type Registration", RFC 3802, June 2004.  Vaudreuil, G. and G. Parsons, "Content Duration MIME Header Definition", RFC 3803, June 2004.  Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J. Rafferty, "File Format for Internet Fax", RFC 3949, February 2005.  Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration", RFC 3302, September 2002.  Allocchio, C., "Minimal GSTN address format in Internet Mail", RFC 3191, October 2001.  Allocchio, C., "Minimal FAX address format in Internet Mail", RFC 3192, October 2001.  Toyoda, K., Ohno, H., Murai, J., and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 3965, December 2004.  Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - F Profile for Facsimile", RFC 2306, March 1998.  Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.  Masinter, L. and D. Wing, " Extended Facsimile Using Internet Mail", RFC 2532, March 1999.  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
 Resnick, P., "Internet Message Format", RFC 2822, April 2001.  Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.  Burger, E., "Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter", RFC 3459, January 2003.  Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180, July 1997.  Candell, E., "High-Level Requirements for Internet Voice Mail", RFC 3773, June 2004.  Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, April 2003.  Nerenberg, "IMAP4 Channel Transport Mechanism", Work in Progress, November 2001.  Toyoda, K. and D. Crocker, "SMTP Service Extensions for Fax Content Negotiation", Work in Progress, February 2003.  McRae, S. and G. Parsons, "Internet Voice Messaging (IVM)", RFC 4239, November 2005.  Murchison, K. and L. Greenfield, "LMTP Service Extension for Ignoring Recipient Quotas", Work in Progress, June 2002.  Crispin, M., "Message Submission", Work in Progress, February 2004.  Newman, C., "Message Submission with Composition", Work in Progress, February 2004.  Gellens, R., "IMAP Message Submission", Work in Progress, December 2003.  Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", Work in Progress, December 2003.  Crispin, M. and C. Newman, "Internet Message Access (IMAP) - URLAUTH Extension", Work in Progress, July 2004.  Newman, D., "Message Submission BURL Extension", Work in Progress, July 2004.
 Crocker, D., "Internet Mail Architecture", Work in Progress, July 2004.  Leuca, I., "Multimedia Messaging Service", Presentation to the VPIM WG, IETF53 Proceedings , April 2002.  Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.  Shapira, N. and E. Aloni, "Simple Notification and Alarm Protocol (SNAP)", Work in Progress, December 2001.  Vaudreuil, G., "Messaging profile for telephone-based Messaging clients", Work in Progress, February 2002.  Burger, E., "Internet Unified Messaging Requirements", Work in Progress, February 2002.  OMA, "Multimedia Messaging Service Architecture Overview Version 1.1", Open Mobile Alliance (OMA) OMA-WAP-MMS-ARCH-v1_1- 20021101-C, November 2002.  OMA, "Push Architectural Overview", Open Mobile Alliance (OMA) WAP-250-PushArchOverview-20010703-a, July 2001.  OMA, "Push Access Protocol Specification", Open Mobile Alliance (OMA) WAP-247-PAP-20010429-a, April 2001.  OMA, "Push Proxy Gateway Service Specification", Open Mobile Alliance (OMA) WAP-249-PPGService-20010713a, July 2001.  OMA, "Multimedia Messaging Service; Client Transactions Version 1.1", Open Mobile Alliance (OMA) OMA-WAP-MMS-CTR-v1_1-20021031-C, October 2002.  OMA, "Multimedia Messaging Service; Encapsulation Protocol Version 1.1", Open Mobile Alliance (OMA) OMA-MMS-ENC-v1_1- 20021030-C, October 2002.  OMA, "User Agent Profile, Version 1.1", Open Mobile Alliance (OMA) OMA-UAProf-v1_1-20021212-C, December 2002.  OMA, "Email Notification Version 1.0", Open Mobile Alliance (OMA) OMA-EMN-v1_0-20021031-C, October 2002.
 3GPP, "Third Generation Partnership Project; Technical Specification Group Services and System Aspects; Service aspects; Functional description; Stage 1 Multimedia Messaging Service", 3GPP TS 22.140, 2001.  3GPP, "Third Generation Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS); Functional description; Stage 2", 3GPP TS 23.140, 2001.  3GPP2, "Short Message Service (SMS)", 3GPP2 TSG C.S0015-0, December 1999.  3GPP2, "Enhanced Message Service (EMS) Stage 1 Description", 3GPP2 TSG S.R0051-0 v1.0, July 2001.  CCITT, "Recommendations Q.700-Q.716: Specifications of Signalling System No. 7", CCITT White Book, Volume VI, Fascicle VI.7.  CCITT, "Recommendations Q.721-Q.766: Specifications of Signalling System No.7", CCITT White Book, Volume VI, Fascicle VI.8.  ITU, "E.164: The international public telecommunication numbering plan", ITU-T Recommendations Series E, May 1997.  ITU, "Specifications of Signalling System Number 7", ITU White Book, ITU-T Recommendation Q.763.  ITU, "Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit", ITU-T Recommendation X.25, October 1996.  BELLCORE, "Specifications of Signalling System Number 7", GR- 246-CORE Issue 1, December 1994.
Alan K. Stebbens Openwave Systems, Inc. 530 E. Montecito St. Santa Barbara, CA 93103 USA Phone: +1 805 884-3162 EMail: email@example.com Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd. Dallas, TX 75214 USA Phone: +1 214 823-9325 EMail: GregV@ieee.org
* The Web pages for KnowHow, a company founded by Rohit Khare which has a proprietary Internet-wide notification system. Thanks to Lisa Dusseault for providing these references. Note that this opinion does not represent IAB concensus, it is just the opinion of the author after having reviewed the references. After the reviewing the material, it seemed that the same kinds of functionality are being asked from a generic notification protocol as are asked of desktop application integration mechanisms, like OLAY/ COM on Windows or like Tooltalk was on Solaris, but at the level of messaging across the Internet. The desire is that various distributed applications with different application specific mechanisms should be able to interoperate without having an n x n problem of having each application interact with each other application. The cannonical example, which is in a presentation by Lisa Dusseault to LEMONADE from IETF 56, is sending a notification from one application, like XMPP Instant Messaging, and having it delivered on whatever device the recipient happened to be using at the time, like SMS on a cell phone. The usual problem with application intergration mechanisms on the desktop is how to get the various applications to actually use the mechanism. For Windows, this is relatively easy, since most application developers see major value-added in their applications being able to play nicely with Microsoft Office. For Tooltalk, unfortunatly, Solaris developers didn't see the 10x improvement, and so it was not used outside of Sun's internally maintained applications and a few flagship applications like Framemaker. If the generic notification mechanism requires application developers and other notification protocol designers to make a major effort to utilize it, including modifying their applications or protocols in some way, the protocol could become "just another notification mechanism" rather than a unifying device, because most application developers and other protocol designers could ignore it. So the first architectural consideration is how do clients of a particular protocol (and the word "client" is used here to mean "any entity using the protocol", they may peers or they may be client/server) actually utilize the generic notification protocol? Is there some code change required in the client or can a legacy client interoperate without change? If you look at Fig. 1 in draft-shapira-snap-05.txt, the answer seems to be that the notifying client uses the generic protocol, SNAP in this case, to a functional entity (server? module on the receiving client?) called the "Notification Service" that processes the generic
notification into an application specific notification and sends that notification to the client. From this figure it looks as if the notifying client would require modification but the receiving client wouldn't. Another characteristic of application integration mechansims is that they typically focus on very simple operations, the semantics of which are shared between different applications. Examples are "here's a rectangle, display yourself in it" or "put this styled text object into the clipboard", and applications agree on what styled text means. More complicated semantics are hard to share because each application has its own particular twist on the meaning of a particular sequence of operations on a collection of objects. The result is a "least common denominator" collection of integration mechanisms, primarily focussed on display integration and, to a lesser extent, cut and paste integration. In the context of a generic notification protocol, this raises several possible issues. One is addressing, which is identified draft-dusseault-s2s-event-reqs-00.txt, but in a sense this is the easiest to resolve, by using existing and perhaps newly defined URIs. A more complex problem is matching the semantics of what preconditions constitute the trigger for an event across different application notification mechanisms. This is of course necessary for translating notifications between the different event notification mechanisms and the generic mechanism, but, more problematically, it is also required for a subscription service whereby subscriptions can be made to filter events using the generic notification mechanism and the subscriptions can be translated to different application specific mechanisms. Any language for expressing generic subscriptions is unlikely to support expressing the fine points in the different application notification semantics. Note that SNAP does not seem to support a subscription service so perhaps this isn't an issue for SNAP. Another architectural issue, which was discussed earlier this year on the LEMONADE list w.r.t. some other topics, is gatewaying. The cannonical example above (message sent using XMPP and arriving via SMS on a cell phone) is actually a gateway example, because it would require translation between an IP-based messaging mechanism (XMPP) to a PSTN based mechanism (SMS). The problem with using a unified notification mechanism for this purpose is that if there are other functions common between the two, it is likely that a gateway will be built anyway. In fact, one of the work items for LEMONADE is to investigate such gateways. The value of a generic notification mechanism therefore needs to be assessed in the light of this.
These are the primary architectural issues, but there are a few others that need consideration in any major system development effort. End to end security is one, draft-dusseault-s2s-event-reqs-00.txt talks about this quite extensively, so it won't be repeated here. The major issue is how to ensure that the end to end security properties are maintained in the face of movement of the notification through the generic intermediary protocol. Another issue is scalability. Peer to peer v.s. server based mechanisms have implications for how scalable the notification mechanism would be, and this needs consideration. Extensibility needs careful consideration. What is required to integrate a new application? Ideally, with time, application developers will stop "rolling their own" notification service and simply use the generic service, but this ideal may be extremely hard to achieve, and may depend to a large extent on market acceptance. Finally, there are some considerations that aren't architectural but may impact the ultimate success of a generic notification protocol, in the sense that the protocol becomes widely deployed and used. The author's experience is that IETF has not had particular success in introducing mechanisms that unify or supplant existing proprietary mechanisms unless strong vendor and service provider by-in is there. Two examples are instant messaging and service discovery. With instant messaging, it seems that a standarized, unified instant messaging protocol has been delayed by the lack of committment from major service providers. With service discovery, weak commitment from vendors has resulted in the continued introduction of vendor specific service discovery solutions even after an IETF standard is in place. The situation with service discovery (with which the author is most familiar) resulted from a lack of major vendor committment during the end phases of the standarization process. Applying these lessions to a generic notification protocol, having important players with proprietary notification protocols on board and committed until the conclusion of the design process will be crucial. Major committment is needed from various application notification protocols before a generic mechanism could succeed. Given the amount of time and effort required in any IETF standardization work, assessing these with an objective eye is critical, otherwise, regardless of how technically well designed the protocol is, deployment success may be lacking. Having an elegently design solution that nobody deploys is an outcome that might be wise to avoid. James Kempf July 2003
Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).