idnits 2.17.1 draft-ietf-lemonade-goals-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1871. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1848. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1855. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1861. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: IMAP 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 17, 2004) is 7042 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 1352, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1355, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1358, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1369, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1372, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1379, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1383, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1387, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1395, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1398, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1401, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1404, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1407, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1413, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1416, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 1426, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 1430, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 1433, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 1436, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 1442, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 1448, but no explicit reference was found in the text == Unused Reference: '31' is defined on line 1451, but no explicit reference was found in the text == Unused Reference: '32' is defined on line 1454, but no explicit reference was found in the text == Unused Reference: '33' is defined on line 1457, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 1460, but no explicit reference was found in the text == Unused Reference: '40' is defined on line 1481, but no explicit reference was found in the text == Unused Reference: '43' is defined on line 1491, but no explicit reference was found in the text == Unused Reference: '44' is defined on line 1495, but no explicit reference was found in the text == Unused Reference: '45' is defined on line 1498, but no explicit reference was found in the text == Unused Reference: '46' is defined on line 1502, but no explicit reference was found in the text == Unused Reference: '50' is defined on line 1516, but no explicit reference was found in the text == Unused Reference: '55' is defined on line 1537, but no explicit reference was found in the text == Unused Reference: '56' is defined on line 1540, but no explicit reference was found in the text == Unused Reference: '57' is defined on line 1543, but no explicit reference was found in the text == Unused Reference: '58' is defined on line 1546, but no explicit reference was found in the text == Unused Reference: '59' is defined on line 1550, but no explicit reference was found in the text == Unused Reference: '60' is defined on line 1554, but no explicit reference was found in the text == Unused Reference: '61' is defined on line 1557, but no explicit reference was found in the text == Unused Reference: '62' is defined on line 1560, but no explicit reference was found in the text == Unused Reference: '63' is defined on line 1565, but no explicit reference was found in the text == Unused Reference: '66' is defined on line 1575, but no explicit reference was found in the text == Unused Reference: '67' is defined on line 1579, but no explicit reference was found in the text == Unused Reference: '68' is defined on line 1583, but no explicit reference was found in the text == Unused Reference: '69' is defined on line 1586, but no explicit reference was found in the text == Unused Reference: '70' is defined on line 1589, but no explicit reference was found in the text == Unused Reference: '71' is defined on line 1594, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (ref. '1') (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (ref. '2') (Obsoleted by RFC 3979) -- Obsolete informational reference (is this intentional?): RFC 822 (ref. '5') (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 1891 (ref. '6') (Obsoleted by RFC 3461) -- Obsolete informational reference (is this intentional?): RFC 2048 (ref. '11') (Obsoleted by RFC 4288, RFC 4289) -- Obsolete informational reference (is this intentional?): RFC 2060 (ref. '13') (Obsoleted by RFC 3501) -- Obsolete informational reference (is this intentional?): RFC 2086 (ref. '14') (Obsoleted by RFC 4314) -- Obsolete informational reference (is this intentional?): RFC 2087 (ref. '15') (Obsoleted by RFC 9208) -- Obsolete informational reference (is this intentional?): RFC 2298 (ref. '17') (Obsoleted by RFC 3798) -- Obsolete informational reference (is this intentional?): RFC 2421 (ref. '18') (Obsoleted by RFC 3801) -- Obsolete informational reference (is this intentional?): RFC 2422 (ref. '19') (Obsoleted by RFC 3802) -- Obsolete informational reference (is this intentional?): RFC 2423 (ref. '20') (Obsoleted by RFC 3801) -- Obsolete informational reference (is this intentional?): RFC 2424 (ref. '21') (Obsoleted by RFC 3803) -- Obsolete informational reference (is this intentional?): RFC 2301 (ref. '22') (Obsoleted by RFC 3949) -- Obsolete informational reference (is this intentional?): RFC 2302 (ref. '23') (Obsoleted by RFC 3302) -- Obsolete informational reference (is this intentional?): RFC 2303 (ref. '24') (Obsoleted by RFC 3191) -- Obsolete informational reference (is this intentional?): RFC 2304 (ref. '25') (Obsoleted by RFC 3192) -- Obsolete informational reference (is this intentional?): RFC 2305 (ref. '26') (Obsoleted by RFC 3965) -- Obsolete informational reference (is this intentional?): RFC 2476 (ref. '28') (Obsoleted by RFC 4409) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '30') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. '31') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2822 (ref. '32') (Obsoleted by RFC 5322) Summary: 8 errors (**), 0 flaws (~~), 49 warnings (==), 27 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Lemonade Working Group J. Wong, Ed. 3 Internet-Draft Nortel Networks 4 Expires: June 17, 2005 December 17, 2004 6 Goals for Internet Messaging to Support Diverse Service Environments 7 draft-ietf-lemonade-goals-05 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 17, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 This document is a history capturing the background, motivation and 43 thinking during the LEMONADE definition and design process. 45 The LEMONADE Working Group -- Internet Messaging to support diverse 46 service environments -- is chartered to provide enhancements to 47 Internet mail to facilitate its use by more diverse clients. In 48 particular, by clients on hosts not only operating in environments 49 with high latency/bandwidth-limited unreliable links but also 50 constrained to limited resources. The enhanced mail must be 51 backwards compatible with existing Internet mail. 53 The primary motivation for this effort is -- by making Internet mail 54 protocols richer and more adaptable to varied media and environments 55 -- to allow mobile handheld devices tetherless access to Internet 56 mail using only IETF mail protocols. 58 The requirements for these devices drive a discussion of the possible 59 protocol enhancements needed to support multimedia messaging on 60 limited capability hosts in diverse service environments. A list of 61 general principles to guide the design of the enhanced messaging 62 protocols is documented. Finally, some issues around providing 63 seamless service between enhanced Internet mail and the existing 64 separate mobile messaging infrastructure are briefly listed. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2. Conventions used in this document . . . . . . . . . . . . . . 7 70 3. Messaging Terminology and Simple Model (Client to Server 71 aspect only) . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.1 Messaging Transaction Models . . . . . . . . . . . . . . . 8 73 3.2 Mobile Messaging Transactions . . . . . . . . . . . . . . 8 74 3.2.1 Submission . . . . . . . . . . . . . . . . . . . . . . 9 75 3.2.2 Notification . . . . . . . . . . . . . . . . . . . . . 9 76 3.2.3 Retrieval . . . . . . . . . . . . . . . . . . . . . . 10 77 4. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.1 Existing Profiles . . . . . . . . . . . . . . . . . . . . 11 79 4.1.1 Voice Messaging (VPIMv2) . . . . . . . . . . . . . . . 11 80 4.1.2 iFax . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 4.1.3 Internet Voice Mail (IVM) . . . . . . . . . . . . . . 11 82 4.2 Putative Client Profiles . . . . . . . . . . . . . . . . . 11 83 4.2.1 TUI . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 4.2.2 Multi-modal clients . . . . . . . . . . . . . . . . . 13 85 4.2.3 WUI . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 5. General Principles . . . . . . . . . . . . . . . . . . . . . . 16 87 5.1 Protocol Conservation . . . . . . . . . . . . . . . . . . 16 88 5.1.1 Reuse Existing Protocols . . . . . . . . . . . . . . . 16 89 5.1.2 Maintain Existing Protocol Integrity . . . . . . . . . 16 90 5.2 Sensible Reception/Sending Context . . . . . . . . . . . . 16 91 5.2.1 Reception Context . . . . . . . . . . . . . . . . . . 16 92 5.2.2 Sending Context . . . . . . . . . . . . . . . . . . . 16 93 5.3 Internet Infrastructure Preservation . . . . . . . . . . . 16 94 5.4 Voice Requirements (Near real-time delivery) . . . . . . . 17 95 5.5 Fax Requirements (guaranteed delivery) . . . . . . . . . . 17 96 5.6 Video Requirements (scalable message size) . . . . . . . . 17 97 6. Issues and Requirements: TUI subset of WUI . . . . . . . . . . 18 98 6.1 Requirements on the Message Retrieval protocol . . . . . . 18 99 6.1.1 Performance Issues . . . . . . . . . . . . . . . . . . 18 100 6.1.2 Functional Issues . . . . . . . . . . . . . . . . . . 19 101 6.2 Requirements on the Message Submission Protocol . . . . . 21 102 6.2.1 Forward without Download Support . . . . . . . . . . . 21 103 6.2.2 Quota by Context Enforcement . . . . . . . . . . . . . 22 104 6.2.3 Future Delivery Support with Cancel . . . . . . . . . 22 105 6.2.4 Support for Committed Message Delivery . . . . . . . . 23 106 6.3 Requirements on Message Notification . . . . . . . . . . . 23 107 6.3.1 Additional Requirements on Message Notification . . . 24 108 7. Issues and Requirements: WUI Mobility Aspects . . . . . . . . 25 109 7.1 Wireless Considerations on Email . . . . . . . . . . . . . 25 110 7.1.1 Transport Considerations . . . . . . . . . . . . . . . 25 111 7.1.2 Handset-Resident Client Limitations . . . . . . . . . 25 112 7.1.3 Wireless Bandwidth and Network Utilization 113 Considerations . . . . . . . . . . . . . . . . . . . . 25 115 7.1.4 Content Display Considerations . . . . . . . . . . . . 26 116 7.2 Requirements to Enable Wireless Device Support . . . . . . 27 117 7.2.1 Transport Requirements . . . . . . . . . . . . . . . . 27 118 7.2.2 Enhanced Mobile Email Functionality . . . . . . . . . 28 119 7.2.3 Client Requirements . . . . . . . . . . . . . . . . . 28 120 7.2.4 Bandwidth Requirements . . . . . . . . . . . . . . . . 28 121 7.2.5 Media Handling Requirements . . . . . . . . . . . . . 29 122 8. Interoperation with Existing Mobile Messaging . . . . . . . . 31 123 8.1 Addressing of mobile devices . . . . . . . . . . . . . . . 31 124 8.2 Push model of Message Retrieval . . . . . . . . . . . . . 31 125 8.3 Message Notification . . . . . . . . . . . . . . . . . . . 31 126 8.4 Operator Issues . . . . . . . . . . . . . . . . . . . . . 31 127 8.4.1 Support for end-to-end delivery reports and 128 message-read reports . . . . . . . . . . . . . . . . . 31 129 8.4.2 Support for Selective Downloading . . . . . . . . . . 31 130 8.4.3 Transactions and Operator Charging Units . . . . . . . 31 131 8.4.4 Network Authentication . . . . . . . . . . . . . . . . 32 132 8.5 LEMONADE and MMS . . . . . . . . . . . . . . . . . . . . . 32 133 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 134 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37 135 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 136 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 38 137 11.2 Informative References . . . . . . . . . . . . . . . . . . . 38 138 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 43 139 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44 140 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46 141 C. IAB Note: Unified Notification Protocol Considerations . . . . 47 142 Intellectual Property and Copyright Statements . . . . . . . . 51 144 1. Introduction 146 Historically, a number of separate electronic messaging systems 147 originated and evolved independently supporting different messaging 148 modes. E.g. 149 o Internet mail systems evolved to support networked computers with 150 messages consisting of rich text plus attachments. 151 o Voice mail systems utilized a client with a telephone-based or an 152 answering machine style of user interface. The telephone network 153 was used for transport of recorded voice messages. 154 o Fax store-and-forward users interface with a fax machine using a 155 modified telephone based interface. Fax machines use the 156 telephone network for transport of fax data via modems. 157 o SMS (Short Message Service)[64] enabled users to send short text 158 messages between their cellular phones using the SS7 call control 159 infrastructure for transport. 161 In the recent past, IETF mail standards have evolved to support 162 additional/merged functionality: 163 o With MIME([8] to [12]), Internet mail transport was enhanced to 164 carry any kind of digital data 165 o Internet mail protocols were extended and profiled by VPIM ([18] 166 to [21]) and iFAX ([22] to [27], [29]) so that enabled voice mail 167 systems and fax machines could use the common email infrastructure 168 to carry their messages over the Internet as an alternative to the 169 telephone network. These enhancements were such that the user's 170 experience of reliability, security and responsiveness were not 171 diminished by transport over the Internet. 173 These successes -- making Internet mail transport the common 174 infrastructure supporting what were separate messaging universes -- 175 have encouraged a new vision: to provide, over the Internet, a single 176 infrastructure, mailbox, and set of protocols for a user to get, 177 respond to, and manipulate all of his or her messages from a 178 collection of clients with varying capabilities, operating in diverse 179 environments ([52],[53]). 181 The LEMONADE effort -- Internet Messaging to support diverse service 182 environments -- realizes this vision further by enabling Internet 183 mail support for mobile devices and facilitating its interoperability 184 with the existing mobile messaging universe. 186 In the recent past, the evolution of messaging standards for resource 187 limited mobile devices has been rapid: 188 o In the cellular space, SMS was enhanced to EMS (Extended Message 189 Service)[65] allowing longer text messages, images and graphics. 190 With an even richer feature set, MMS (Multimedia Messaging 191 Service)[49] was developed as a lightweight access mechanism for 192 the transmission of pictures, audio, and motion pictures. MMS 193 protocols are based in part on Internet standards (both messaging 194 and web) as well as SMS. The cellular messaging universe is a 195 separate infrastructure adapted to deliver appropriate 196 functionality in a timely and effective manner to a special 197 environment. 198 o As well, the number of different mobile clients that need to be 199 supported keeps proliferating. (e.g. besides cellular phones 200 there are wireless enabled PDAs, tablet computers, etc.) 202 These resource-limited mobile devices are less powerful both in 203 processing speed and display capabilities than conventional 204 computers. They are also connected to the network by wireless links 205 whose bandwidth and reliability are lower, latency is longer, and 206 costs are higher than traditional wire-line links hence the stress on 207 the need to support adaptation to a whole different service 208 environment. 210 This document collects together a number the issues impeding Internet 211 mail protocols from directly supporting the mobile service 212 environment. Considerations arising from these issues are documented 213 and in some cases possible approaches to solutions are suggested. It 214 turns out that the enhancements to support mobile clients also offer 215 benefits for some terminals in other environments. In particular the 216 enhancements address the needs of the following diverse clients: 217 o A wireless handheld device with an email client -- a Wireless User 218 Interface (WUI) mode of user interaction is dictated by the 219 constraints of the mobile wireless handheld operating environment 220 o Telephone-based voice client -- a Telephone User Interface (TUI), 221 this is the user mode offered by a POTS set 222 * This is a subset of the WUI and is useful in other contexts 223 o A Multi-modal messaging client providing a coordinated messaging 224 session using display and audio modes simultaneously. (e.g. a 225 system consisting of a PC with a phone or a wireless phone with 226 both a voice circuit and data channel requiring coordination). 227 * This is also a subset of the WUI and is useful in other 228 contexts 230 The rest of this document is structured as follows: 231 o A brief survey of messaging profiles - both existing and proposed 232 o A list of principles to be used to guide the design of Internet 233 Messaging for diverse service environments 234 o Detailed discussion on enhancements to Internet mail protocols to 235 support WUIs. 236 o Some issues relating to the interoperation of enhanced Internet 237 mail and the existing mobile messaging services 239 2. Conventions used in this document 241 This document refers generically to the sender of a message in the 242 masculine (he/him/his) and the recipient of the message in the 243 feminine (she/her/hers). This convention is purely for convenience 244 and makes no assumption about the gender of a message sender or 245 recipient. 247 FORMATTING NOTE: 249 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 250 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 251 document are to be interpreted as described in RFC2119 [4]. 253 3. Messaging Terminology and Simple Model (Client to Server aspect 254 only) 256 In the client-server model prevalent in existing messaging 257 architectures, the client, also known as a "user agent", presents 258 messages to and accepts messages from the user. The server, also 259 known as a "relay/server" or a "proxy-relay", provides storage and 260 delivery of messages . 262 For a definitive description of Internet mail architecture, see [48]. 264 3.1 Messaging Transaction Models 266 There are two basic transactional models. In the "pull" model, the 267 component rather than the data flow initiates the transaction. E.g., 268 a client may initiate a connection to a server and issue requests to 269 the server to deliver incoming messages. Conventional email clients, 270 web-mail clients, and WAP-based mobile clients use the "pull" model. 272 The "push" model differs in that the component initiating the 273 transaction does so because of some data flow affecting it. E.g., 274 the arrival of a new message at the terminating server may cause a 275 notification to be sent ("pushed") to a messaging client. 277 3.2 Mobile Messaging Transactions 279 The most common functions are: "submission", "notification", and 280 "retrieval". There may be other functions, such as "delivery 281 reports", "read-reply reports", "forwarding", "view mailbox", "store 282 message", etc. Each of these transactions can be implemented in 283 either a pull or push model. However, some transactions are more 284 naturally suited to one model or another. 286 The following figure is a depiction of a simple client-server model 287 (no server to server interactions shown): 289 (1) Message submission 290 (2) Message notification 291 (3) & (4) Message retrieval 293 +-------+ +------+ +-------+ 294 |Mail |-------(1)------>| |-----------(2)-------->|Mail | 295 |Client | Submit msg | | Notification /|Client | 296 +-------+ | | / +--+----+ 297 | | / ^ 298 | |<----------(3)-----+ / 299 |Server| Retrieval request / 300 | | / 301 | | / 302 | |-----------(4)-------+ 303 | | Retrieval response 304 | | 305 +------+ 307 - Simple Messaging Model 309 3.2.1 Submission 311 "Submission" is the transaction between a client and a server by 312 which the user of the former sends a new message to another user. 313 Submission is a push from client to server. 315 3.2.2 Notification 317 "Notification" is the transaction by which the server notifies the 318 client that it has received messages intended for that client. 319 Notification is a push from server to client. 321 All of the larger mobile messaging systems implement a push model for 322 the notification because data can be presented to the user without 323 the user having to experience network/transport latencies, and 324 without tying up network resources for polling when there is no new 325 data. 327 Internet mail differs in that it has not seen the need so far for a 328 standardized notification protocol. 330 3.2.3 Retrieval 332 "Retrieval" is the transaction between a client and a server by which 333 the client can obtain one or more messages from the server. 334 Retrieval can be push or pull. 336 Implemented in some mobile systems as an option, the push model has 337 the advantage of the user not necessarily being aware of transport or 338 network latencies. 340 The pull model, implemented in most systems, mobile or conventional, 341 has the advantage that the user can control what data is actually 342 sent to and stored by the client. 344 4. Profiles 346 Internet messaging can be made to support a variety of client and 347 server types other than traditional email. The clients may be 348 adapted for host restrictions such as limited processing power, 349 message store, display window size, etc. Alternatively clients may 350 be adapted for different functionality (e.g. voice mail, fax, etc.). 351 Servers may support optional mail features that would allow better 352 handling of different media (e.g. voice mail, fax, video, etc.). A 353 number of Internet mail profiles supporting specific application 354 niches have been defined or proposed. 356 4.1 Existing Profiles 358 The following are examples of server-to-server profiles of SMTP and 359 MIME. They do not address client-to-server interactions except for 360 IVM. 362 4.1.1 Voice Messaging (VPIMv2) 364 These profiles RFC2421 [18] to RFC2424 [21] enable the transport of 365 voice messages using the Internet mail system. The main driver for 366 this work was support of IP transport for voice mail systems. As 367 voice mail clients are accustomed to a higher degree of 368 responsiveness and certainty as to message delivery, the 369 functionality added by VPIMv2 includes Message Disposition 370 Notification and Delivery Status Message as well as the addition of 371 voice media to multi-part message bodies. 373 4.1.2 iFax 375 This set of profiles RFC2301 [22] to RFC2306 [27] enables the 376 transport of fax using Internet mail protocols. This work defined 377 the image/tiff MIME type. Support for fax clients also required 378 extensions to Message Delivery Notification. 380 4.1.3 Internet Voice Mail (IVM) 382 This proposed mail enhancement (requirements described in RFC3773 383 [36]) targets support for the interchange of voice messaging between 384 the diverse components (clients as well as servers) in systems 385 supporting voice mail. 387 4.2 Putative Client Profiles 389 4.2.1 TUI 391 It is desirable to replace proprietary protocols between telephone 392 user interface clients and message stores with standards-based 393 interfaces. The proprietary protocols were created to provide 394 media-aware capabilities as well as provide the low-latency required 395 by some messaging applications. 397 An example of a TUI client is a voice mail client. Since a POTS 398 phone lacks any intelligence, the voice mail client functionality has 399 to be provided by a user agent networked to the mail server. The 400 main architectural difference between a conventional voice mail 401 system and an Internet messaging system supporting a TUI is that the 402 voice mail system uses a specialized message store and protocols. 404 Architecture of current voice mail systems implementing VPIMv2: 406 |-------------| 407 |-------| RFC-822/MIME | | 408 | | |---------------------------| MTA | 409 | | | mail submission -> | |(E)SMTP 410 Telephone--|TUI|TUA| |------| |-----to 411 | | | Proprietary Protocol | | |another 412 | | |---------------------------| MS | | email 413 |-------| < - mail retrieval | | | server 414 |-------------| 415 mail client email server 417 |----------------voice messaging system -------------| 419 Mail client consists of: TUI (Telephone User Interface) and 420 TUA (Telephone User Agent) 421 Communication between TUI and TUA is proprietary 422 Email server consists of: MS (Mail Store) and MTA (Message Transfer Agent) 423 Communication between MS and MTA is proprietary 425 It is proposed that the Proprietary Protocol be replaced with an IETF 426 standard protocol: 428 |-------------| 429 |-------| RFC-822/MIME | | 430 | | |---------------------------| MTA | 431 | | | mail submission -> | |(E)SMTP 432 Telephone--|TUI|TUA| |------| |-----to 433 | | | IETF protocol | | |another 434 | | |---------------------------| MS | | mail 435 |-------| <- mail retrieval | | | server 436 |-------------| 437 mail client email server 439 |- voice mail system-| |-mail server-| 441 Mail client consists of: TUI (Telephone User Interface) and 442 TUA (Telephone User Agent) 443 Communication between TUI and TUA is proprietary 444 Email server consists of: MS (Mail Store) and MTA (Message Transfer Agent) 445 Communication between MS and MTA is proprietary 447 4.2.2 Multi-modal clients 449 Multi-modal clients offer the advantage of coordinated voice and data 450 modes of user interaction. Architecturally, the multi-modal client 451 can be considered the union two user agent components -- one a TUI 452 client, the other a simple GUI client. See next figure. The 453 Graphical User Agent (GUA) helps maintain the text display while the 454 Telephone User Agent (TUA) acts on behalf of the TUI functionality. 456 This model is the norm with cellular devices supporting data access 457 since these evolved historically from cell phones to which a data 458 channel was added. The presentation of multiple complementary modes 459 of interaction gives end users their choice of the most convenient 460 and natural working mode for a particular task. There are other 461 situations where a multi-modal model is appropriate. (E.g., a 462 telephone sales unit needs to provide a voice (telephone) mode and 463 conventional desktop PC mode of interaction at the same time in an 464 integrated manner.) 466 A major issue in the design of multi-modal clients -- the need to 467 synchronize the component user agents making up a client -- is only 468 addressed by LEMONADE to a limited extent in Section 6.3. 470 4.2.3 WUI 472 The Wireless user interface is functionally equivalent to a 473 conventional email client on a personal workstation, but is optimized 474 for the limited memory, processing, latency, bandwidth, and 475 relatively high bandwidth cost. As already alluded to above, in many 476 cases (e.g. cellular devices), the mobile client is multi-modal. So 477 WUIs can be modeled as resource-and-link-limited multi-modal clients. 479 These terminals require the use of protocols that minimize the number 480 of over-the-air transactions and reduce the amount of data that need 481 be transmitted over the air overall. Such reduction in over-the-air 482 transmission is a combination of more efficient protocol interaction 483 and richer message presentation choices allowing a user to more 484 intelligently select what should be downloaded and what should remain 485 on the server. 487 While not an explicit goal, it is desirable to provide equivalent or 488 superior functionality to the wireless MMS service [49] as defined by 489 3GPP, 3GPP2, and the OMA. 491 Wireless User Interface(WUI)/Multi-modal Clients 493 Proposed: 495 |wireless GUI client| email server 497 (E)SMTP (client-server) |-------------| 498 |-------| RFC-822/MIME | | 499 | | |---------------------------| | 500 | | | mail submission -> | |(E)SMTP 501 -|GUI|GUA| | |-----to 502 | | | | IETF standard protocol |------------ |another 503 | | | |----------------------------to MS below| | mail 504 | |-------| <- mail retrieval |------------ | server 505 | | | | 506 Handheld | | | | 507 Device WUI | | MTA | 508 | | | | 509 | | | | 510 | |-------| RFC-822/MIME | | 511 | | | |---------------------------| | 512 | | | | mail submission -> | | 513 -|TUI|TUA| |------| | 514 | | | IETF standard protocol | | | 515 | | |---------------------------| MS | | 516 |-------| <- mail retrieval | | | 517 |-------------| 518 TUI client voice mail server 520 |----------------voice messaging system ----------------| 522 |------WUI-----| |---mail server---| 524 Wireless GUI client consists of: GUI (Graphical User Interface) 525 And GUA (Graphical User Agent) 526 Communication between UI and UA is proprietary 527 TUI client consists of: TUI (Telephone User Interface) and 528 TUA (Telephone User Agent) 529 Communication between TUI and TUA is proprietary 530 Communication between GUA and TUA is proprietary 532 Mail (email and voice mail) server consists of: MS (Mail Store) 533 and MTA (Message Transfer Agent) 534 Communication between MS and MTA is proprietary 536 5. General Principles 538 This is a list of principles to guide the design of extensions for 539 Internet Messaging systems and protocols to support diverse 540 endpoints. 542 5.1 Protocol Conservation 544 5.1.1 Reuse Existing Protocols 546 To the extent feasible, the enhanced messaging framework SHOULD use 547 existing protocols whenever possible. 549 5.1.2 Maintain Existing Protocol Integrity 551 In meeting requirement Reuse Existing Protocols (Section 5.1.1), the 552 enhanced messaging framework MUST NOT redefine the semantics of an 553 existing protocol. 555 Extensions, based on capability declaration by the server, will be 556 used to introduce new functionality where required. 558 Said differently, we will not break existing protocols. 560 5.2 Sensible Reception/Sending Context 562 5.2.1 Reception Context 564 When the user receives a message, that message SHOULD receive the 565 treatment expected by the sender. For example, if the sender 566 believes he is sending a voice message, voice message semantics 567 should prevail to the extent that the receiving client can support 568 such treatment. 570 5.2.2 Sending Context 572 When the user sends a message, he SHOULD be able to specify the 573 message context. That is, whether the network should treat the 574 message as an text message, voice message, video message, etc. 575 Again, this can only be complied with to the extent that the 576 infrastructure and receiving client can provide such treatment. In 577 practice, this would imply that the message should be in the form 578 desired by the sender up to delivery to the receiving client. 580 5.3 Internet Infrastructure Preservation 582 The infrastructure SHOULD change only where required for new 583 functionality. Existing functionality MUST be preserved on the 584 existing infrastructure, that is, all extensions must be backward 585 compatible so as to allow for the gradual introduction of the 586 enhancements. Messages created in an enhanced messaging context MUST 587 NOT require changes to existing mail clients. However, there may be 588 a degradation in functionality in certain circumstances. 590 The enhanced messaging framework MUST be able to handle messages 591 created in a non-enhanced messaging context, for example, a simple, 592 RFC822 [5] text message. 594 5.4 Voice Requirements (Near real-time delivery) 596 On the retrieval side, there are significant real-time requirements 597 for retrieving a message for voice playback. More than any other 598 media type, including video, voice is extremely sensitive to 599 variations in playback latency. The enhanced messaging framework 600 MUST address the real-time needs of voice. 602 5.5 Fax Requirements (guaranteed delivery) 604 Fax users have a particular expectation that is a challenge for 605 enhanced Internet messaging. When a person sends a fax, their 606 expectation is the user has received the message upon successful 607 transmission. This clearly is not the case for Internet Mail. 609 Addressing this need is not in the scope of LEMONADE. 611 5.6 Video Requirements (scalable message size) 613 Video mail has one outstanding feature: Video messages are 614 potentially large! The enhanced messaging framework MUST scale for 615 very large messages. Streaming from the server to the client, in 616 both directions, MUST be supported. 618 6. Issues and Requirements: TUI subset of WUI 620 6.1 Requirements on the Message Retrieval protocol 622 IMAP is the Internet protocol for rich message retrieval and 623 manipulation. The project MUST limit itself to extending IMAP where 624 necessary and MUST not create a new protocol. 626 6.1.1 Performance Issues 628 6.1.1.1 Real-Time Playback 630 The real-time playback of a voice message MUST be supported so that 631 the user experience does not differ noticeably from that of a 632 conventional voice messaging system. 634 Possible solutions for this include making use of the existing 635 incremental download capability of the IMAP protocol, or utilizing a 636 companion streaming protocol. 638 The IMAP protocol itself does not provide streaming by the strict 639 definition of the term. It does provide for the incremental download 640 of content in blocks. Most IMAP clients do not support this behavior 641 and instead download the entire contents into a temporary file to be 642 passed to the application. 644 There are several approaches to achieve real-time playback. The 645 first approach is to implement an IMAP client that can pass data 646 incrementally to the application as it is received from the network. 647 The application can then read bytes from the network as needed to 648 maintain a play buffer and not require the full download of contents. 649 This approach may require server-side development to efficiently 650 support partial download. (i.e. to avoid re-opening files and 651 positioning to the requested location) 653 Alternatively, the client can use the proposed IMAP channel extension 654 [38] to request that the server make the selected content available 655 via an alternate transport mechanism. A client can then ask the 656 server to make the voice data available to the client via a streaming 657 media protocol such as RTSP. This requires support on the client and 658 server of a common streaming protocol. 660 6.1.1.2 Avoid Content-Transfer-Encoding Data Inflation 662 Another important performance optimization is enabling the transport 663 of data using more efficient native coding rather than text-like 664 content-transfer-encodings such as "base 64" . 666 Standard IMAP4 uses a text-based data representation scheme where all 667 data is represented in a form that looks like text, that is, voice 668 data must be encoded using "base 64" into a transport encoding that 669 adds 30% to the size of a message. When downloading or appending 670 messages to the server, substantial additional bandwidth is utilized. 672 Possible Solutions: 674 Where IMAP channel is appropriate, the external channel may be binary 675 capable; that is, the external access may not require re-encoding. 676 Such mechanisms as HTTP, FTP, or RTSP are available for this 677 download. 679 The IMAP binary extension standards proposal [37] extends the IMAP 680 fetch command to retrieve data in the binary form. This is 681 especially useful for large attachments and other binary components. 682 Binary in conjunction with a streaming client implementation may be 683 an attractive alternative to the channel extension. 685 6.1.2 Functional Issues 687 6.1.2.1 Mailbox Summary Support 689 The common TUI prompt, "you have two new voice messages, six unheard 690 messages, and one new fax message" requires more information than is 691 conveniently made available by current message retrieval protocols. 693 The existing IMAP protocol's mailbox status command does not include 694 a count by message context. A possible solution is have the mail 695 server keep track of these current counters and provide a status 696 command that returns an arbitrary mailbox summary. The IMAP status 697 command provides a count of new and total messages with standardized 698 attributes extracted from the message headers. This predetermined 699 information does not currently include information about the message 700 type. Without additional conventions to the status command, a client 701 would have to download the header for each message to determine its 702 type, a prohibitive cost where latency or bandwidth constraints 703 exist. 705 6.1.2.2 Sort by Message Context Support 707 This functionality is required to present new voice messages first 708 and then new fax messages within a single logical queue as voice 709 mailboxes commonly do. Again this is a question of convenience and 710 performance. Adequate performance may only be possible if the mail 711 server provides a sort by context or maintains a set of virtual 712 mailboxes (folders) corresponding to message types as for Mailbox 713 Summary Support Section 6.1.2.1. 715 IMAP does not support this directly. A straightforward solution is 716 to define an extensible sort mechanism for sorting on arbitrary 717 header contents. 719 6.1.2.3 Status of Multiple Mailboxes Support 721 Extension mailbox support requires the ability to efficiently status 722 a mailbox other than the one currently logged into. This facility is 723 required to support sub-mailboxes, where a common feature is to check 724 whether other sub-mailboxes in the same family group have new 725 messages. 727 Current mechanisms are limited to logging into each of set of 728 mailboxes, checking status, logging out, and repeating until all 729 sub-mailboxes are processed. 731 6.1.2.4 Specialized Mailbox Support 733 Applications that provide features such as check receipt, deleted 734 message recovery, resave, and others require the ability to access 735 messages in predetermined mailboxes with specific behaviors. (E.g. 736 Outbox, Sent Items, Delete Items, Expired items, Drafts) 738 IMAP provides only a single standardized folder, the inbox. This 739 functionality does not require new protocol additions per-se, but 740 standardized usage and naming conventions necessary for 741 interoperability. It required that the server provide the underlying 742 logic to support these special folders including automatic insertion, 743 scheduled copying, and periodic deletion. 745 6.1.2.5 CLID Restriction indication/preservation 747 Many calling features are dependent upon collected caller-ID 748 information. Trusted clients such as the TUI, and other service 749 supporting user agents such as WEB and WAP servers may have access to 750 restricted caller-ID information for such purposes as callback. 751 Untrusted clients must not receive this information. A mechanism for 752 communicating "trust" between the client and the server is required 753 to deliver this information to the end-user when appropriate. 755 Further, when sending messages between servers within a network, a 756 means of communicating trust is needed such that the identity of the 757 sender can be preserved for record-keeping and certain features while 758 ensuring the identity is not disclosed to the recipient in an 759 inappropriate way. 761 6.1.2.6 Support for Multiple Access to Mailbox 763 If the telephone answering application client uses IMAP4 for greeting 764 access and message deposit, it is essential that the server provide 765 support for simultaneous login. It is common in voicemail for an 766 incoming call to be serviced by the telephone answering application 767 client at the same time the subscriber is logged into their mailbox. 768 Further, new applications such as WEB and WAP access to voicemail may 769 entail simultaneous login sessions, one from the TUI client and one 770 from the visual client. 772 The existing standard does not preclude multiple accesses to a 773 mailbox, but it does not explicitly require support of the practice. 774 The lack of explicit support requires the server and client to adhere 775 to a common set of practices and behaviors to avoid undesirable and 776 unpredictable behaviors. RFC2180 [35] describes a candidate set of 777 conventions necessary to support this multiple-access technique. It 778 or some other method MUST be standardized as part of LEMONADE. 780 6.2 Requirements on the Message Submission Protocol 782 6.2.1 Forward without Download Support 784 It is common to forward messages or to reply to messages with a copy 785 of their attached content. Today such forwarding requires the sender 786 to download a complete copy of the original message, attach it to the 787 reply or forward message, and resubmit the result. For large 788 messages, this represents a substantial amount of bandwidth and 789 processing. For clients connected via long-thin pipes, alternatives 790 are required. 792 One approach is to define an extension to message submission to 793 request the submission server to resolve embedded URL's within a 794 message before relaying the message to the final destination. This 795 approach is refered to as the pull approach because the message 796 submission server must pull data from the IMAP server. 798 Another approach is to add a limited message assembly and submission 799 capability to the IMAP server. This approach muddies the distinction 800 between the message submission protocol and the message store and 801 retrieval one (IMAP) since now message submission may be a side 802 effect of message store commands. This approach is referred to as 803 the push approach because in this case the IMAP server pushes data to 804 the Message Submission Server. 806 A detailed analysis of which of the two approaches is preferable as 807 well as implementation details of both can be found in references 808 [42] to [47]. 810 6.2.2 Quota by Context Enforcement 812 It is common in a unified messaging system to offer separate quotas 813 for each of several message contexts to avoid the condition where a 814 flood of email fills the mailbox and prevents the subscriber from 815 receiving voice messages via the telephone. It is necessary to 816 extend the protocols to support the reporting of the "mailbox full" 817 status based on the context of the submitted message. 819 Clear security issues are involved to prevent the misidentification 820 of a message context for the purpose of intentionally filling a 821 subscriber's mailbox. It is envisioned that the message submission 822 protocol will support authentication of trusted submission agents 823 authorized to submit distinguished messages. 825 Voice mail system mailboxes commonly contain voice and fax messages. 826 Sometimes, such systems also support email messages (text, text with 827 attachments, and multimedia messages) in addition to voice messages. 828 Similarly to the requirement for sort by message context -- quota 829 management is also required per message context. 831 One possible use-case is the prevention of multiple (large) messages 832 of one type (e.g. email messages) from consuming all available quota 833 so that messages of another type (e.g. voice or fax messages) cannot 834 be further deposited to the mailbox. 836 One possible approach is to define a mechanism whereby a trusted 837 client can declare the context of a message for the purpose of 838 utilizing a protected quota. This may be by extensions to the 839 SMTP-submit or LMTP[41] protocols. 841 6.2.3 Future Delivery Support with Cancel 843 Traditionally messages sent with "future delivery" are held in the 844 recipients client "outbox" or equivalent until the appointed 845 submission time. Thin clients used with TUIs do not have such 846 persistent storage or may be intermittently connected and must rely 847 upon server-based outbox queues. 849 Such support requires extensions to message submission protocols to 850 identify a message as requiring queuing for future delivery. 851 Extensions to IMAP4 or SMTP are required to view and manipulate the 852 outbound queue, for such purposes as canceling a future message. 853 Server support for managing such a queue is required such that 854 messages are sent when they are intended. 856 Some of the architectural issues here are the same as the ones for 857 Forward without Download (Section 6.2.1). 859 6.2.4 Support for Committed Message Delivery 861 Voice messaging service has provided a high degree of reliability and 862 performance for telephone answering messages. The expectation is 863 that once the caller has hung-up, the message is in the mailbox and 864 available for review. The traditional Internet mail architecture 865 suggests these messages should be sent to the mailbox via SMTP. This 866 approach has two limitations. The first and most manageable is that 867 the message forwarding may take more time than is tolerable by the 868 subscriber. The second is that the message may fail to be delivered 869 to the mailbox, and because there is no way to return notice to the 870 caller that the message is "lost". 872 The standards community is working on an alternative to SMTP called 873 Local Message Transport Protocol(LMTP[41]). This protocol addresses 874 a number of limitations in SMTP when used to provide atomic delivery 875 to a mailbox. The failure modes in this proposal are carefully 876 controlled, as are issues of per-message quota enforcement and 877 message storage quota-override for designated administrative 878 messages. 880 An alternative approach is to misuse the IMAP protocol and use an 881 IMAP based submission mechanism to deposit a message directly into 882 the recipient's inbox. This append must be done by a special 883 super-user with write permissions into the recipient mailbox. 884 Further, the message store must be able to trigger notification 885 events upon insertion of a message into the mailbox via the Append 886 command. The historic limitation on using IMAP4 for message sending 887 involves the inability of IMAP to communicate a full SMTP envelope. 888 For telephone answering, these limitations are not significant. 889 However, the architectural issues raised by this approach are 890 significant. See Forward without Download (Section 6.2.1). 892 6.3 Requirements on Message Notification 894 Clients keep local information about the IMAP store. This 895 information must be kept synchronized with the state of the store. 897 E.g. Voicemail systems traditionally notify subscribers of certain 898 events happening in their mailbox. It is common to send an SMS, or a 899 pager notification for each message arrival event, message read 900 event, mailbox full event, etc. 902 When implemented over IMAP-based message stores, the voice mail 903 client needs to be notified about these events. Furthermore, when 904 other applications access/manipulate the store, these events need to 905 be communicated to the mail client. In some cases, the client needs 906 to notify the user immediately. In most cases it is a question of 907 maintaining client/application consistency. In the case of a 908 multimodal client, it is especially important providing a means of 909 coordinating the client's different modal views of the state of the 910 store. 912 E-mail systems have traditionally polled to update this information. 913 There may be advantages to an event driven approach in some cases. 915 The standards community is working on a standard for bulk 916 server-to-client status notification. An example of such work is the 917 Simple Notification and Alarm Protocol (SNAP)[51] that defines the 918 expected behavior of the message store for various events, much of 919 them triggered by IMAP commands. 921 6.3.1 Additional Requirements on Message Notification 923 A format for message notification for servers reporting status 924 information to other servers (e.g. IMAP4 server to SMS or pager 925 server) MUST be defined. The method for delivery of these 926 notifications MUST also be specified. 928 The design for this MUST take into account the IAB note: Unified 929 Notification Protocol Considerations (Appendix C). 931 7. Issues and Requirements: WUI Mobility Aspects 933 7.1 Wireless Considerations on Email 935 7.1.1 Transport Considerations 937 Compared to a LAN/WAN configuration or even to a wire-line dial-up 938 connection, the probability of an interruption to a wireless 939 connection is very high. 941 Interruptions can be due to hand-off, signal fading, or stepping 942 beyond cell coverage. 944 In addition, since the mobile handset is also used for other types of 945 communications, there is relatively high probability that the data 946 session will be interrupted either by incoming voice calls or by 947 "pushed" messages from services such as SMS, MMS and WAP. 949 It is also common in these environments that the device's IP address 950 change within a session. 952 7.1.2 Handset-Resident Client Limitations 954 Although the capabilities of wireless handsets are rapidly improving, 955 the wireless handset remains limited in its capability to host email 956 clients. Currently, email access is restricted to only high-end 957 wireless handsets. 959 These limitations include: 960 o Client size 961 * Handset-resident clients are limited in size because either the 962 handset has limited storage space or the handset vendor/network 963 operator has set a limit on the size of client application that 964 can reside on the handset. 965 o Runtime memory 966 * Wireless handsets have limited runtime memory for the use of 967 the mobile email client. 968 o CPU Speed 969 * Wireless handsets have CPUs that are inferior to those in 970 conventional systems (PCs) that run email clients. 971 o User Interface 972 * Handsets have very limited input and output capabilities. Most 973 of them have only a rudimentary keyboard (a keypad) and a 974 rudimentary pointing device (a text cursor). 976 7.1.3 Wireless Bandwidth and Network Utilization Considerations 977 7.1.3.1 Low Bandwidth 979 2G mobile networks enabled wireless data communications but only at 980 very low bandwidths using circuit-switched data. 2.5G and 3G 981 networks improve on this. However, existing email clients require 982 very large (up to several MBs) files -- encountered in multi-media 983 attachments such as presentations, images, voice and video -- to be 984 downloaded even though mobiles can not exploit most of the data 985 (because of color depth and screen size limitations). Transferring 986 such large files over the air is of questionable value even when 987 higher wireless bandwidth is available. 989 7.1.3.2 Price Sensitivity 991 In many cases, users of mobile data services are charged by the 992 amount of data (e.g. kilobytes) downloaded to the handset. Most 993 users currently experience a higher per-kilobyte data charge with a 994 wireless service than over a wire-line service. Users are sensitive 995 to the premium for wireless service. This results in an 996 unwillingness to download large amounts of unnecessary data to the 997 handset and the desire to be able to download only selected content. 999 7.1.3.3 File Size Limitations 1001 In some cases, the size of file -- that can be transmitted over the 1002 air to the handset -- is limited. This is a consequence of handset 1003 limitations (Section 7.1.2), wireless media and bandwidth issues 1004 (Section 7.1.1,Section 7.1.3.1) and price sensitivity (Section 1005 7.1.3.2). 1007 7.1.4 Content Display Considerations 1009 7.1.4.1 Display Size and capabilities 1011 Wireless terminals are currently limited in their display size, color 1012 depth, and ability to present multimedia elements (i.e. if multiple 1013 pictures are sent, the mobile can usually present only one 1014 reduced-sized picture element at a time rather than the several 1015 picture elements at once in the same display that a conventional PC 1016 email client would be able to show). Therefore many email 1017 attachments destined for a mobile may require changes in size, color 1018 depth and presentation method to be suitably displayed. 1020 7.1.4.2 Supported Media Formats 1022 Wireless handsets can only display a limited set of media format 1023 types. While PC clients support a large variety of document types 1024 (and allow on-demand "codec"/player download), mobiles have very 1025 limited support. (e.g., most only support WAV audio and cannot play 1026 other formats such as AU, MP3 and AIFF.) Furthermore, although almost 1027 all new handsets sold today can display images and sound in some 1028 advanced format, support for displaying other media or 1029 application-specific formats, such as MS-Office (TM) is not expected 1030 to be widespread in the near future. 1032 7.1.4.3 Handset Type Variety 1034 As mentioned above, there are many handset types available in the 1035 market and each has different display capabilities, screen 1036 characteristics and processing capabilities. The mobile email 1037 service should be able to support as many handset types as possible. 1039 7.1.4.4 Specific Attachment Display Scenarios 1041 Handsets are unsuited for perusing entire lengthy documents or 1042 presentations. A mobile user is more likely to look at several pages 1043 of a document or several slides of a presentation and then take 1044 action accordingly (e.g., forward the email message to another 1045 recipient, print it, or leave the document for later retrieval from 1046 another device) rather than go through the whole document. 1048 Therefore, there is a need to enable users to download not the entire 1049 attachment but rather just a selected part of it. For example, users 1050 should be able to download the "Table of Contents" of a document; to 1051 search within a document; to download the first slide of a 1052 presentation; the next slide of this presentation; a range of slides, 1053 etc. 1055 7.2 Requirements to Enable Wireless Device Support 1057 The following requirements are derived from the considerations 1058 mentioned above. 1060 7.2.1 Transport Requirements 1062 The mobile email protocol must anticipate transient losses of 1063 connectivity and allow clients to quickly and easily recover (restore 1064 state) from interrupted connections. 1066 IMAP4 Context 1068 An IMAP4 connection requires the communication socket to remain up 1069 continuously during an email session. In case of transient loss of 1070 communications, the connection must be reestablished. It is up to 1071 the client to reconnect to the server and return to an equivalent 1072 state in the session. This overhead of restoring connections is very 1073 costly in response time and additional data transmission. 1075 7.2.2 Enhanced Mobile Email Functionality 1077 7.2.2.1 Forward Without Fetch 1079 To minimize the downloading of data over the air, the user MUST be 1080 able to forward a message without initially downloading it entirely 1081 or at all to the handset. 1083 The mobile email protocol MUST support the ability to forward a 1084 message without retrieving it. 1086 This requirement is identical to the TUI requirement that is 1087 described in Forward Without Download (Section 6.2.1). 1089 7.2.2.2 Media Streaming 1091 The mobile email protocol MUST provide a solution that will enable 1092 media streaming to the wireless handset. 1094 This requirement is similar to the TUI requirement that is described 1095 in Real-Time Playback (Section 6.1.1.1). 1097 7.2.3 Client Requirements 1099 IMAP4 clients are large because IMAP4 already consists of a complex 1100 set of functions (e.g., parsing of a broad variety of MIME formats). 1102 The mobile email client should be: 1103 o Small in size 1104 o Efficient in CPU consumption 1105 o Efficient in runtime memory consumption 1107 To enable such extremely thin clients, in developing the mobile email 1108 protocol we should consider simplifying the IMAP functionality that 1109 handsets need support. However, any such simplification MUST NOT 1110 limit interoperability with full IMAP servers. 1112 7.2.4 Bandwidth Requirements 1114 The mobile email solution should minimize the amount of data 1115 transmitted over the air. There are several ways of pursuing this 1116 goal which can be used in conjunction. 1118 One way is the use of content transcoding and media adaptation by the 1119 server before message retrieval in order to optimize it for the 1120 capabilities of the receiving handset. 1122 Another possible optimization is to make the mobile email protocol 1123 itself simple containing as little overhead as possible. 1125 A third approach is to minimize the bandwidth usage as described in 1126 Avoid Content-Transfer-Encoding Data Inflation (Section 6.1.1.2). 1128 7.2.5 Media Handling Requirements 1130 As described above, wireless devices have limited ability to handle 1131 media. Therefore, the server may be have to perform media 1132 manipulation activities to enable the terminal to display the data 1133 usefully. 1135 7.2.5.1 Device Capabilities Negotiation 1137 In order to correctly support the different characteristics and 1138 capabilities of the various handset types available in the market, 1139 the mobile email protocol must include provision for email content 1140 adaptation. For example, the choice of supported file formats, color 1141 depth and screen size. Work on ESMTP transcoding (CONNEG[39]) may 1142 address this issue. 1144 7.2.5.2 Adjusting Message Attachments for Handset Abilities 1146 To support wireless handsets, the server could transcode the message 1147 attachments into a representation that is more suitable for that 1148 device. This behavior should be based on the device capabilities 1149 negotiation as described in Device Capabilities Negotiation (Section 1150 7.2.5.1). For example, a device that cannot display GIF format but 1151 only WBMP should get a WBMP image. Devices that cannot display a PDF 1152 file should get a text version of the file. 1154 The handset should control what or any transcoding is desired. It 1155 should be able to retrieve the original attachment without any 1156 changes. In addition, the device should be able to choose between 1157 "flavors" of the transcoding ("Present the content as thumbnail 1158 image" is an example of such a specific media manipulation.) 1160 Again work on ESMTP transcoding (CONNEG[39]) may address this issue. 1162 7.2.5.3 Handling Attachment Parts 1164 A desirable feature to have (but out of scope for the current 1165 LEMONADE charter) is to enable users the choice of retrieving parts 1166 of an attachment file not just the entire attachment. The mobile 1167 email protocol should include the ability for the retrieving client 1168 to specify selected elements of an attachment for download. Such 1169 elements can be, for example, specific pages of a document, the 1170 "table of contents" of a document or specific slides of a 1171 presentation. 1173 8. Interoperation with Existing Mobile Messaging 1175 LEMONADE's charter includes the specification of how enhanced 1176 Internet Mail will interoperate with existing mobile messaging 1177 services (e.g. MMS) to deliver messages to mobile clients. 1179 8.1 Addressing of mobile devices 1181 E.164 addressing is prevalent in mobile messaging services to address 1182 recipient mobiles. Consideration should be given to supporting E.164 1183 addressing for mobile devices in addition to RFC822 addressing. 1185 8.2 Push model of Message Retrieval 1187 MMS provides a "push" option for message retrieval. The option hides 1188 network latencies and reduces the need for user-handheld interaction. 1189 If a level of support for mobiles comparable MMS is desired, this 1190 mode of operation should be considered. 1192 8.3 Message Notification 1194 Message notification was alluded to in Requirements on Message 1195 Notification (Section 6.3). Internet mail has not so far 1196 standardized a server-to-client notification protocol although most 1197 existing wireless mail systems use notification to avoid needless 1198 polling. Client-to-server notification is not within the LEMONADE 1199 charter. 1201 8.4 Operator Issues 1203 8.4.1 Support for end-to-end delivery reports and message-read reports 1205 Support for committed delivery is described in Section 6.2.4 but this 1206 is different. 1208 8.4.2 Support for Selective Downloading 1210 Especially important, if a push model of message retrieval is 1211 supported, is the need for selective downloading and SPAM control. 1213 8.4.3 Transactions and Operator Charging Units 1215 Mobile network providers often operate on a "pay for use" service 1216 model. This brings in requirements for clearly delineated service 1217 transactions that can be reported to billing systems, and for 1218 positive end-to-end acknowledgement of delivery or non-delivery of 1219 messages already mentioned Section 8.4.1. Note that billing is 1220 specifically outside the scope of the IETF. 1222 8.4.4 Network Authentication 1224 Some mobile networks require network authentication as well as 1225 application authentication. 1227 8.5 LEMONADE and MMS 1229 The 3GPP MMS Reference Architecture [54] defines seven interfaces 1230 labelled MM1 to MM7 as below: 1232 3GPP MMS Reference Architecture (subset) 1234 |---------| |------------| 1235 wireless ||-------|| | | 1236 device || MMS || | |<- MM2 -> 1237 || USER |---------------------------| |--------- 1238 || AGENT |<- MM1 ->| | to 1239 ||-------|| | | another 1240 |---------| | | MMS 1241 | | relay/ 1242 |--------| | | server 1243 e.g. | | | | 1244 E-mail,|EXTERNAL| | | 1245 Fax, or| SERVER |--------------------------| | 1246 UMS | |<- MM3 ->| | 1247 |--------| | | 1248 | | 1249 |---------| | | 1250 |"FOREIGN"| | | 1251 | MMS |-------------------------| | 1252 | relay/ |<- MM4 ->| | 1253 | server | | | 1254 |---------| | | 1255 | MMS | 1256 |-------| |relay/server| 1257 | | | | 1258 | HLR |---------------------------| | 1259 | |<- MM5 ->| | 1260 |-------| | | 1261 | | 1262 |-------| | | 1263 | MMS | | | 1264 | USER |---------------------------| | 1265 | DBs |<- MM6 ->| | 1266 |-------| | | 1267 | | 1268 |-------| | | 1269 | MMS | | | 1270 | VAS |---------------------------| | 1271 | APPs |<- MM7 ->| | 1272 |-------| |------------| 1274 MMS - Multimedia Messaging Service 1275 UMS - Unified Messaging Service 1276 HLR - Home Location Register 1277 DB - Data Base 1278 VAS - Value Added Service 1279 APP - Application 1281 The LEMONADE profile provides an enhanced IMAP mail retrieval 1282 protocol suitable for use at interfaces MM1 and MM3. 1284 In addition, if the wireless device uses a LEMONADE-enhanced IMAP 1285 user agent, the enhanced IMAP protocol can be used to directly access 1286 Internet mail as below. 1288 3GPP MMS Reference Architecture (subset) 1290 |---------| |------------| 1291 wireless ||-------|| | | 1292 device || IMAP || | |<- MM2 -> 1293 || USER || | |--------- 1294 || AGENT || | | to 1295 ||---^---|| | | another 1296 |----|---|| | | MMS 1297 | LEMONADE Enhanced IMAP and | | relay/ 1298 |---V----| SMTP | | server 1299 e.g. | | | | 1300 E-mail,|EXTERNAL| | | 1301 Fax, or| SERVER |--------------------------| | 1302 UMS | |<- MM3 ->| | 1303 |--------| | | 1304 | | 1305 |---------| | | 1306 |"FOREIGN"| | | 1307 | MMS |-------------------------| | 1308 | relay/ |<- MM4 ->| | 1309 | server | | | 1310 |---------| | | 1311 | MMS | 1312 |-------| |relay/server| 1313 | | | | 1314 | HLR |---------------------------| | 1315 | |<- MM5 ->| | 1316 |-------| | | 1317 | | 1318 |-------| | | 1319 | MMS | | | 1320 | USER |---------------------------| | 1321 | DBs |<- MM6 ->| | 1322 |-------| | | 1323 | | 1324 |-------| | | 1325 | MMS | | | 1326 | VAS |---------------------------| | 1327 | APPs |<- MM7 ->| | 1328 |-------| |------------| 1330 MMS - Multimedia Messaging Service 1331 UMS - Unified Messaging Service 1332 HLR - Home Location Register 1333 DB - Data Base 1334 VAS - Value Added Service 1335 APP - Application 1337 9. Security Considerations 1339 Security will be a very important part of enhanced messaging. The 1340 goal, wherever possible, is to preserve the semantics of existing 1341 messaging systems and meet the (existing) expectations of users with 1342 respect to security and reliability. 1344 10. IANA Considerations 1346 This document has no actions for IANA. 1348 11. References 1350 11.1 Normative References 1352 [1] Bradner, S., "IETF Rights in Contributions", RFC 3667, BCP 78, 1353 February 2004. 1355 [2] Bradner, S., "Intellectual Property Rights in IETF Technology", 1356 RFC 3668, BCP 79, February 2004. 1358 [3] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 1359 2026, BCP 9, October 1996. 1361 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1362 Levels", RFC 2119, BCP 14, March 1997. 1364 11.2 Informative References 1366 [5] Crocker, D., "Standard for the format of ARPA Internet text 1367 messages", RFC 822 (obsolete), August 1982. 1369 [6] Moore, K., "SMTP Service Extension for Delivery Status 1370 Notifications", RFC 1891, January 1996. 1372 [7] Myers, J. and M. Rose, "Post Office Protocol - Version 3", RFC 1373 1939, STD 53, May 1997. 1375 [8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1376 Extensions (MIME) Part One: Format of Internet Message Bodies", 1377 RFC 2045, November 1996. 1379 [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1380 Extensions (MIME) Part Two: Media Types", RFC 2046, November 1381 1996. 1383 [10] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part 1384 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 1385 BCP 14, November 1996. 1387 [11] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet 1388 Mail Extensions (MIME) Part Four: Registration Procedures", RFC 1389 2048, November 1996. 1391 [12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1392 Extensions (MIME) Part Five: Conformance Criteria and 1393 Examples", RFC 2049, November 1996. 1395 [13] Crispin, M., "Internet Message Access Protocol - Version 1396 4rev1", RFC 2060, December 1996. 1398 [14] Myers, J., "IMAP4 ACL extension", RFC 2086, Status PROPOSED 1399 STANDARD, January 1997. 1401 [15] Myers, J., "IMAP4 QUOTA extension", RFC 2087, Status PROPOSED 1402 STANDARD, January 1997. 1404 [16] Gahrns, M., "IMAP4 Login Referrals", RFC 2221, Status PROPOSED 1405 STANDARD, October 1997. 1407 [17] Fajman, R., "An Extensible Message Format for Message 1408 Disposition Notifications", RFC 2298, March 1998. 1410 [18] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail 1411 - version 2", RFC 2421, September 1998. 1413 [19] Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32 kbit/s 1414 ADPCM MIME Sub-type Registration", RFC 2422, September 1998. 1416 [20] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME Sub-type 1417 Registration", RFC 2423, September 1998. 1419 [21] Vaudreuil, G. and G. Parsons, "Content Duration MIME Header 1420 Definition", RFC 2424, September 1998. 1422 [22] McIntyre, L., Zilles, S., Buckley, R., Venable, D., Parsons, G. 1423 and J. Rafferty, "File Format for Internet Fax", RFC 2301, 1424 March 1998. 1426 [23] Parsons, G., Rafferty, J. and S. Zilles, "Tag Image File Format 1427 (TIFF) - image/tiff MIME Sub-type Registration", RFC 2302, 1428 March 1998. 1430 [24] Allocchio, C., "Minimal PSTN address format in Internet Mail", 1431 RFC 2303, March 1998. 1433 [25] Allocchio, C., "Minimal FAX address format in Internet Mail", 1434 RFC 2304, March 1998. 1436 [26] Toyodar, K., Ohno, H., Murai, J. and D. Wing, "A Simple Mode of 1437 Facsimile Using Internet Mail", RFC 2305, March 1998. 1439 [27] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - F 1440 Profile for Facsimile", RFC 2306, March 1998. 1442 [28] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, 1443 Status PROPOSED STANDARD, December 1998. 1445 [29] Masinter, L. and D. Wing, "Extended Facsimile Using Internet 1446 Mail", RFC 2532, March 1999. 1448 [30] Fielding, Gettys, Berners-Lee and others, "Hypertext Transfer 1449 Protocol - HTTP 1.1", RFC 2616, June 1999. 1451 [31] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, 1452 April 2001. 1454 [32] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 1455 2001. 1457 [33] Burger, E., Candell, E., Eliot, C. and G. Klyne, "Message 1458 Context for Internet Mail", RFC 3458, January 2003. 1460 [34] Burger, E., "Critical Content Multi-purpose Internet Mail 1461 Extensions (MIME) Parameter", RFC 3459, January 2003. 1463 [35] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180, 1464 July 1997. 1466 [36] Candell, E., "High-Level Requirements for Internet Voice Mail", 1467 RFC 3773, June 2004. 1469 [37] Nerenberg, "IMAP4 Binary Content Extension", Internet Draft 1470 work in progress, January 2002, 1471 . 1473 [38] Nerenberg, "IMAP4 Channel Transport Mechanism", Internet Draft 1474 work in progress, November 2001, 1475 . 1477 [39] Toyoda, K. and D. Crocker, "SMTP Service Extensions for Fax 1478 Content Negotiation", Internet Draft work in progress, February 1479 2003, . 1481 [40] McRae, S., "Internet Voice Messaging", Internet Draft work in 1482 progress, . 1484 [41] Murchison, K. and L. Greenfield, "LMTP Service Extension for 1485 Ignoring Recipient Quotas", Internet Draft work in progress, 1486 June 2002, . 1488 [42] Crispin, M., "Message Submission", Internet Draft work in 1489 progress, February 2004, . 1491 [43] Newman, C., "Message Submission with Composition", Internet 1492 Draft work in progress, February 2004, 1493 . 1495 [44] Gellens, R., "IMAP Message Submission", Internet Draft work in 1496 progress, December 2003, . 1498 [45] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE 1499 Extension", Internet Draft work in progress, December 2003, 1500 . 1502 [46] Crispin, M. and C. Newman, "Internet Message Access (IMAP) - 1503 URLAUTH Extension", Internet Draft work in progress, July 2004, 1504 . 1506 [47] Newman, D., "Message Submission BURL Extension", Internet Draft 1507 work in progress, July 2004, 1508 . 1510 [48] Crocker, D., "Internet Mail Architecture", Internet Draft work 1511 in progress, July 2004, . 1513 [49] Leuca, I., "Multimedia Messaging Service", Presentation to the 1514 VPIM WG, IETF53 Proceedings , April 2002. 1516 [50] Mahy, R., "A Message Summary and Message Waiting Indication 1517 Event Package for the Session Initiation Protocol (SIP)", 1518 Internet Draft work in progress, 1519 . 1521 [51] Shapira, N. and E. Aloni, "Simple Notification and Alarm 1522 Protocol (SNAP)", Internet Draft work in progress, December 1523 2001, . 1525 [52] Vaudreuil, G., "Messaging profile for telephone-based Messaging 1526 clients", Internet Draft work in progress, February 2002, 1527 . 1529 [53] Burger, E., "Internet Unified Messaging Requirements", Internet 1530 Draft work in progress, February 2002, 1531 . 1533 [54] OMA, "Multimedia Messaging Service Architecture Overview 1534 Version 1.1", Open Mobile Alliance (OMA) 1535 OMA-WAP-MMS-ARCH-v1_1-20021101-C, November 2002. 1537 [55] OMA, "Push Architectural Overview", Open Mobile Alliance (OMA) 1538 WAP-250-PushArchOverview-20010703-a, July 2001. 1540 [56] OMA, "Push Access Protocol Specification", Open Mobile Alliance 1541 (OMA) WAP-247-PAP-20010429-a, April 2001. 1543 [57] OMA, "Push Proxy Gateway Service Specification", Open Mobile 1544 Alliance (OMA) WAP-249-PPGService-20010713a, July 2001. 1546 [58] OMA, "Multimedia Messaging Service; Client Transactions Version 1547 1.1", Open Mobile Alliance (OMA) 1548 OMA-WAP-MMS-CTR-v1_1-20021031-C, October 2002. 1550 [59] OMA, "Multimedia Messaging Service; Encapsulation Protocol 1551 Version 1.1", Open Mobile Alliance (OMA) 1552 OMA-MMS-ENC-v1_1-20021030-C, October 2002. 1554 [60] OMA, "User Agent Profile, Version 1.1", Open Mobile Alliance 1555 (OMA) OMA-UAProf-v1_1-20021212-C, December 2002. 1557 [61] OMA, "Email Notification Version 1.0", Open Mobile Alliance 1558 (OMA) OMA-EMN-v1_0-20021031-C, October 2002. 1560 [62] 3GPP, "Third Generation Partnership Project; Technical 1561 Specification Group Services and System Aspects; Service 1562 aspects; Functional description; Stage 1 Multimedia Messaging 1563 Service", 3GPP TS 22.140, 2001. 1565 [63] 3GPP, "Third Generation Partnership Project; Technical 1566 Specification Group Terminals; Multimedia Messaging Service 1567 (MMS); Functional description; Stage 2", 3GPP TS 23.140, 2001. 1569 [64] 3GPP2, "Short Message Service (SMS)", 3GPP2 TSG C.S0015-0, 1570 December 1999. 1572 [65] 3GPP2, "Enhanced Message Service (EMS) Stage 1 Description", 1573 3GPP2 TSG S.R0051-0 v1.0, July 2001. 1575 [66] CCITT, "Recommendations Q.700-Q.716: Specifications of 1576 Signalling System No. 7", CCITT White Book, Volume VI, Fascicle 1577 VI.7. 1579 [67] CCITT, "Recommendations Q.721-Q.766: Specifications of 1580 Signalling System No.7", CCITT White Book, Volume VI, Fascicle 1581 VI.8. 1583 [68] ITU, "E.164: The international public telecommunication 1584 numbering plan", ITU-T Recommendations Series E, May 1997. 1586 [69] ITU, "Specifications of Signalling System Number 7", ITU White 1587 Book, ITU-T Recommendation Q.763. 1589 [70] ITU, "Interface between Data Terminal Equipment (DTE) and Data 1590 Circuit-terminating Equipment (DCE) for terminals operating in 1591 the packet mode and connected to public data networks by 1592 dedicated circuit", ITU-T Recommendation X.25, October 1996. 1594 [71] BELLCORE, "Specifications of Signalling System Number 7", 1595 GR-246-CORE Issue 1, December 1994. 1597 Author's Address 1599 Jin Kue Wong (editor) 1600 Nortel Networks 1601 P.O. Box 3511 Station C 1602 Ottawa, ON K1Y 4H7 1603 Canada 1605 Phone: +1 613 763-2515 1606 EMail: j.k.wong@sympatico.ca 1608 Appendix A. Contributors 1610 Eric Burger 1611 Brooktrout Technology, Inc. 1612 18 Keewaydin Dr. 1613 Salem, MA 03079 1614 USA 1616 Phone: +1 978 367-8400 1617 Email: e.burger@ieee.org 1619 Yair Grosu 1620 Comverse 1621 29 Habarzel St. 1622 Tel-Aviv 69710 1623 Israel 1625 Email: Yair.Grosu@comverse.com 1627 Glenn Parsons 1628 Nortel Networks 1629 P.O. Box 3511 Station C 1630 Ottawa, ON K1Y 4H7 1631 Canada 1633 Phone: +1 613 763-7582 1634 Email: gparsons@nortelnetworks.com 1636 Milt Roselinsky 1637 Openwave Systems, Inc. 1638 530 E. Montecito St. 1639 Santa Barbara, CA 93103 1640 USA 1642 Phone: +1 805 884-6207 1643 Email: milt.roselinsky@openwave.com 1645 Dan Shoshani 1646 Comverse 1647 29 Habarzel St. 1648 Tel-Aviv 69710 1649 Israel 1651 Email: Dan.Shoshani@comverse.com 1653 Alan K. Stebbens 1654 Openwave Systems, Inc. 1655 530 E. Montecito St. 1656 Santa Barbara, CA 93103 1657 USA 1659 Phone: +1 805 884-3162 1660 Email: alan.stebbens@openwave.com 1662 Gregory M. Vaudreuil 1663 Lucent Technologies 1664 7291 Williamson Rd. 1665 Dallas, TX 75214 1666 USA 1668 Phone: +1 214 823-9325 1669 Email: GregV@ieee.org 1671 Appendix B. Acknowledgements 1673 Ari Erev and Noam Shapira (both from Comverse) contributed 1674 substantial requirements for IMAP to support a telephone-based (TUI) 1675 messaging client. Meir Mendelovich (Comverse) helped in merging the 1676 wireless requirements section. Benjamin Ellsworth (Openwave) 1677 contributed to mobile messaging architectures and requirements. 1678 Yaacov(Jerry) Weingarten (Comverse) and Stephane Maes (Oracle) 1679 provided detailed comments on the final draft. 1681 Appendix C. IAB Note: Unified Notification Protocol Considerations 1683 Note: dated July 10, 2003 1685 This note was formulated in response to an informal IESG request to 1686 look at the architectural issues surrounding a unified notification 1687 protocol. The following materials were used as reference: 1688 * draft-dusseault-s2s-event-reqs-00.txt (notification 1689 requirements) 1690 * meeting notes for the LEMONADE WG from IETF 56. 1691 * draft-shapira-snap-05.txt (protocol design for SNAP which has 1692 some aspects of a generic notification protocol) 1693 * the LEMONADE WG charter 1694 * Recent email on the Lemonade list 1695 * A few presentations from the 1998 UCI workshop on Internet-wide 1696 notification 1697 * The Web pages for KnowHow, a company founded by Rohit Khare 1698 which has a proprietary Internet-wide notification system. 1700 Thanks to Lisa Dusseault for providing these references. 1702 Note that this opinion does not represent IAB concensus, it is just 1703 the opinion of the author after having reviewed the references. 1705 After the reviewing the material, it seemed that the same kinds of 1706 functionality are being asked from a generic notification protocol as 1707 are asked of desktop application integration mechanisms, like 1708 OLAY/COM on Windows or like Tooltalk was on Solaris, but at the level 1709 of messaging across the Internet. The desire is that various 1710 distributed applications with different application specific 1711 mechanisms should be able to interoperate without having an n x n 1712 problem of having each application interact with each other 1713 application. The cannonical example, which is in a presentation by 1714 Lisa Dusseault to LEMONADE from IETF 56, is sending a notification 1715 from one application, like XMPP Instant Messaging, and having it 1716 delivered on whatever device the recipient happened to be using at 1717 the time, like SMS on a cell phone. 1719 The usual problem with application intergration mechanisms on the 1720 desktop is how to get the various applications to actually use the 1721 mechanism. For Windows, this is relatively easy, since most 1722 application developers see major value-added in their applications 1723 being able to play nicely with Microsoft Office. For Tooltalk, 1724 unfortunatly, Solaris developers didn't see the 10x improvement, and 1725 so it was not used outside of Sun's internally maintained 1726 applications and a few flagship applications like Framemaker. If the 1727 generic notification mechanism requires application developers and 1728 other notification protocol designers to make a major effort to 1729 utilize it, including modifying their applications or protocols in 1730 some way, the protocol could become "just another notification 1731 mechanism" rather than a unifying device, because most application 1732 developers and other protocol designers could ignore it. 1734 So the first architectural consideration is how do clients of a 1735 particular protocol (and the word "client" is used here here to mean 1736 "any entity using the protocol", they may peers or they may be 1737 client/server) actually utilize the generic notification protocol? Is 1738 there some code change required in the client or can a legacy client 1739 interoperate without change? 1741 If you look at Fig. 1 in draft-shapira-snap-05.txt, the answer seems 1742 to be that the notifying client uses the generic protocol, SNAP in 1743 this case, to a functional entity (server? module on the receiving 1744 client?) called the "Notification Service" that processes the generic 1745 notification into an application specific notification and sends that 1746 notification to the client. From this figure it looks as if the 1747 notifying client would require modification but the receiving client 1748 wouldn't. 1750 Another characteristic of application integration mechansims is that 1751 they typically focus on very simple operations, the semantics of 1752 which are shared between different applications. Examples are 1753 "here's a rectangle, display yourself in it" or "put this styled text 1754 object into the clipboard", and applications agree on what styled 1755 text means. More complicated semantics are hard to share because 1756 each application has its own particular twist on the meaning of a 1757 particular sequence of operations on a collection of objects. The 1758 result is a "least common denominator" collection of integration 1759 mechanisms, primarily focussed on display integration and, to a 1760 lesser extent, cut and paste integration. 1762 In the context of a generic notification protocol, this raises 1763 several possible issues. One is addressing, which is identified 1764 draft-dusseault- s2s-event-reqs-00.txt, but in a sense this is the 1765 easiest to resolve, by using existing and perhaps newly defined URIs. 1766 A more complex problem is matching the semantics of what 1767 preconditions constitute the trigger for an event across different 1768 application notification mechanisms. This is of course necessary for 1769 translating notifications between the different event notification 1770 mechanisms and the generic mechanism, but, more problematically, it 1771 is also required for a subscription service whereby subscriptions can 1772 be made to filter events using the generic notification mechanism and 1773 the subscriptions can be translated to different application specific 1774 mechanisms. Any language for expressing generic subscriptions is 1775 unlikely to support expressing the fine points in the different 1776 application notification semantics. Note that SNAP does not seem to 1777 support a subscription service so perhaps this isn't an issue for 1778 SNAP. 1780 Another architectural issue, which was discussed earlier this year on 1781 the LEMONADE list w.r.t. some other topics, is gatewaying. The 1782 cannonical example above (message sent using XMPP and arriving via 1783 SMS on a cell phone) is actually a gateway example, because it would 1784 require translation between an IP-based messaging mechanism (XMPP) to 1785 a PSTN based mechanism (SMS). The problem with using a unified 1786 notification mechanism for this purpose is that if there are other 1787 functions common between the two, it is likely that a gateway will be 1788 built anyway. In fact, one of the work items for LEMONADE is to 1789 investigate such gateways. The value of a generic notification 1790 mechanism therefore needs to be assessed in the light of this. 1792 These are the primary architectural issues, but there are a few 1793 others that need consideration in any major system development 1794 effort. End to end security is one, 1795 draft-dusseault-s2s-event-reqs-00.txt talks about this quite 1796 extensively, so it won't be repeated here. The major issue is how to 1797 ensure that the end to end security properties are maintained in the 1798 face of movement of the notification through the generic intermediary 1799 protocol. Another issue is scalability. Peer to peer v.s. server 1800 based mechanisms have implications for how scalable the notification 1801 mechanism would be, and this needs consideration. Extensibility 1802 needs careful consideration. What is required to integrate a new 1803 application? Ideally, with time, application developers will stop 1804 "rolling their own" notification service and simply use the generic 1805 service, but this ideal may be extremely hard to achieve, and may 1806 depend to a large extent on market acceptance. 1808 Finally, there are some considerations that aren't architectural but 1809 may impact the ultimate success of a generic notification protocol, 1810 in the sense that the protocol becomes widely deployed and used. The 1811 author's experience is that IETF has not had particular success in 1812 introducing mechanisms that unify or supplant existing proprietary 1813 mechanisms unless strong vendor and service provider by-in is there. 1814 Two examples are instant messaging and service discovery. With 1815 instant messaging, it seems that a standarized, unified instant 1816 messaging protocol has been delayed by the lack of committment from 1817 major service providers. With service discovery, weak commitment 1818 from vendors has resulted in the continued introduction of vendor 1819 specific service discovery solutions even after an IETF standard is 1820 in place. The situation with service discovery (with which the 1821 author is most familiar) resulted from a lack of major vendor 1822 committment during the end phases of the standarization process. 1824 Applying these lessions to a generic notification protocol, having 1825 important players with proprietary notification protocols on board 1826 and committed until the conclusion of the design process will be 1827 crucial. Major committment is needed from various application 1828 notification protocols before a generic mechanism could succeed. 1829 Given the amount of time and effort required in any IETF 1830 standardization work, assessing these with an objective eye is 1831 critical, otherwise, regardless of how technically well designed the 1832 protocol is, deployment success may be lacking. Having an elegently 1833 design solution that nobody deploys is an outcome that might be wise 1834 to avoid. 1836 James Kempf 1837 July 2003 1839 Intellectual Property Statement 1841 The IETF takes no position regarding the validity or scope of any 1842 Intellectual Property Rights or other rights that might be claimed to 1843 pertain to the implementation or use of the technology described in 1844 this document or the extent to which any license under such rights 1845 might or might not be available; nor does it represent that it has 1846 made any independent effort to identify any such rights. Information 1847 on the procedures with respect to rights in RFC documents can be 1848 found in BCP 78 and BCP 79. 1850 Copies of IPR disclosures made to the IETF Secretariat and any 1851 assurances of licenses to be made available, or the result of an 1852 attempt made to obtain a general license or permission for the use of 1853 such proprietary rights by implementers or users of this 1854 specification can be obtained from the IETF on-line IPR repository at 1855 http://www.ietf.org/ipr. 1857 The IETF invites any interested party to bring to its attention any 1858 copyrights, patents or patent applications, or other proprietary 1859 rights that may cover technology that may be required to implement 1860 this standard. Please address the information to the IETF at 1861 ietf-ipr@ietf.org. 1863 Disclaimer of Validity 1865 This document and the information contained herein are provided on an 1866 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1867 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1868 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1869 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1870 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1871 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1873 Copyright Statement 1875 Copyright (C) The Internet Society (2004). This document is subject 1876 to the rights, licenses and restrictions contained in BCP 78, and 1877 except as set forth therein, the authors retain all their rights. 1879 Acknowledgment 1881 Funding for the RFC Editor function is currently provided by the 1882 Internet Society.