idnits 2.17.1 draft-ietf-lemonade-notify-s2s-00.txt: -(279): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(299): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(325): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 7 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 5) being 68 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 19 instances of too long lines in the document, the longest one being 17 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 29, 2004) is 7211 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) -- Looks like a reference, but probably isn't: '1' on line 55 -- Looks like a reference, but probably isn't: '2' on line 89 -- Looks like a reference, but probably isn't: '3' on line 126 -- Looks like a reference, but probably isn't: '4' on line 184 -- Looks like a reference, but probably isn't: '5' on line 246 -- Looks like a reference, but probably isn't: '6' on line 302 -- Looks like a reference, but probably isn't: '7' on line 345 -- Looks like a reference, but probably isn't: '8' on line 395 -- Looks like a reference, but probably isn't: '9' on line 436 -- Looks like a reference, but probably isn't: '10' on line 476 == Unused Reference: 'RFC-URI' is defined on line 442, but no explicit reference was found in the text == Unused Reference: 'RFC-IMAP4' is defined on line 449, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2396 (ref. 'RFC-URI') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 1738 (ref. 'RFC-URL') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 3501 (ref. 'RFC-IMAP4') (Obsoleted by RFC 9051) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Gev Decktor 3 Document: draft-ietf-lemonade-notify-s2s-00.txt Comverse Technology 4 Category: Standards Track 5 Expires: January 29, 2005 6 July 29, 2004 8 Server To Server Notification Protocol Requirements 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or made obsolete by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Discussion of this and related drafts are on the LEMMONADE list. To 32 subscribe, send the message "subscribe" to 33 lemonade-request@ietf.org. 35 Abstract 36 This memo suggests a set of requirements for the implementation 37 of a protocol in which a messaging system (e.g. email server, 38 voice mail system, etc.) submit alerts, which describe 39 potential notification events, regarding an end user mailbox status 40 change (e.g. new message has arrived, mailbox is full, etc.). 41 These alerts are sent to a notification service, which may, 42 in turn, generate an end user alert notification. 44 The protocol facilitates a solution where the messaging system initiates 45 an end user notification, while allowing the messaging system, 46 not to be familiar with the end user's notification preferences. 47 The notification service is the entity which is familiar with the end 48 user's notification preferences. 50 Using this protocol, would allow the messaging system to provide the 51 end user, a unified notification experience (the same look and feel for 52 all messaging systems' accounts), while allowing smooth integration of 53 additional Messaging systems. 55 Decktor Expires January 2005 Page [1] 56 Table of Contents 58 1. Introduction ................................................ 3 59 1.1. Scope .................................................. 3 60 1.2. Basic Operation ........................................ 4 61 1.3. Terminology ............................................ 4 62 2. Notification Protocol Contents............... ............... 5 63 2.1. Informative ............................................ 5 64 2.2. Subscription ........................................... 6 65 2.3. Extensibility .......................................... 6 66 2.4. Exception Handling ..................................... 6 67 2.5. Retrieval .............................................. 7 68 3. Notification Protocol Payload Semantics...... ............... 7 69 3.1. Attributes ............................................. 7 70 3.1.1. Mandatory Attributes .............................. 7 71 3.1.2. Additional Attributes ............................. 7 72 3.2. Events Order ........................................... 8 73 3.3. Internationalization ................................... 8 74 4. Operations .................................................. 8 75 4.1. Scalability ............................................ 8 76 4.2. Reliability ............................................ 8 77 4.3. Security ............................................... 9 78 4.3.1. Threats ........................................... 9 79 4.3.1.1. Denial of Service (DoS) ...................... 9 80 4.3.1.2. IP Spoofing ................................. 9 81 4.3.1.3. Network Snooping ............................. 9 82 4.3.1.4. Impersonation ................................ 9 83 4.3.2. Countermeasures ................................... 9 84 5. References .................................................. 10 85 6. Acknowledgements ............................................ 10 86 7. Authors' Addresses .......................................... 10 87 8. Change Log .................................................. 10 89 Decktor Expires January 2005 Page [2] 90 1. Introduction 92 1.1. Scope 94 The suite of Internet mail protocols (POP3, IMAP4) allows different 95 mail clients to access and manipulate electronic mail messages on 96 a messaging system. These protocols, however, do not provide off- 97 line methods by which an end user can be notified upon changes in 98 the mailbox status. Further, none of the mentioned protocols defines 99 a way to aggregate the status within the end user's various 100 mailboxes. 102 To provide an end user with the ability of unified Notification and 103 one centralized message-waiting indication (MWI), a Notification 104 service is required to aggregate the information of all the events 105 occurring on the end user's different messaging systems. 107 This memo suggests a set of requirements for the implementation of a 108 protocol in which a messaging system notifies a notification 109 service regarding events occurring in an end user's mailbox. 111 It is important to emphasize, that this protocol does not deal with 112 the communications between the notification service and the end user 113 devices (SMS, WAP Push, MWI, etc.). 115 For example, when an email message is deposited in an email server, 116 the email server sends a "new message" notification to the 117 notification service, which then notifies the end user by a Short 118 Text Message (SMS). 120 This process can be extended to include other mailbox events that are 121 important to the end user, such as "mailbox full" and "message 122 rejected" or any other mailbox status change. Each notification 123 should include additional information that is available to the end 124 user such as the mailbox status, message attributes, etc. 126 Decktor Expires January 2005 Page [3] 127 The following figure depicts the notification protocol scope: 129 +--------+ +--------+ 130 New | | | SMS | 131 Message | Email | \ |Gateway | 132 -------> |Server 1| \ _ | | 133 +--------+ \ /| +--------+ 134 ^ \ / 135 | \ / ^ 136 | \ / | +--------+ 137 +--------+ | _|+--------------+ / | | MWI | 138 Read | Voice | | | |/ | |Gateway | 139 Message | Mail |-------->| Notification |------->| | 140 -------> | Server | | ^ _ | Service |\ ^ | +--------+ 141 +--------+ | | /| +--------------- \ | | 142 | |/ \ \| | 143 | / ^ \ ^ \ | 144 |/| | \ | |\| 145 +--------+ / | | \ | | \ +--------+ 146 Mailbox | | /| | | \| | |\ | Wap | 147 Full | Email |/ | | | ^ \ | |_|| Push | 148 -------> |Server 2| | | | | |\| | |Gateway | 149 +--------+ | | | | | \ | +--------+ 150 | | | | | |\| 151 | | | | | | \ 152 | | | | | | |\ 153 | | | | | | |_|+--------+ 154 | | | | | | | | IM | 155 | | | | | | | |Gateway | 156 | | | | | | | | | 157 | | | | | | | +--------+ 158 | | | | | | | 159 Messaging OTHER 160 Notification PROTOCOLS 161 Protocol (not in this 162 document's scope) 164 1.2. Basic Operation 166 The messaging system notifies a notification service (which in turn 167 MAY notify an end user) about events that occurred in the end user's 168 mailbox. Each such notification, referring to a single mailbox event 169 is referred to as a notification request. 171 The notification request SHOULD contain data regarding the mailbox 172 event which has occurred. It's RECOMMENDED that the request would not 173 contain data regarding the end user notification destinations. This 174 would be left to the notification service's implementation. if such 175 data has been received the notification service MAY ignore it. 177 1.3. Terminology 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 180 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 181 "OPTIONAL" in this document are to be interpreted as described 182 in [KEYWORDS]. 184 Decktor Expires January 2005 Page [4] 185 This specification uses the following terms: 187 Message Waiting Indication (MWI) 188 A mechanism that indicates to the end user that a message is waiting 189 in a Messaging System. Examples for such action are: SMS message, 190 WAP push message, Instant messaging notification, telephony stutter 191 tone, etc. MWI states may be ON or OFF. 193 Notification Event 194 An event that may result in a notification to the end user or may 195 change the MWI state (ON or OFF). 197 Messaging System 198 A system that maintains a set of one or more mailboxes for end 199 user's messages, for example: email servers, voicemail systems, 200 etc. 202 Notification Service 203 A system, which aggregates all notification events from multiple 204 Messaging systems to multiple end user destinations. 206 Notification Protocol 207 A protocol that describes how to pass Notification Event 208 data from a Messaging System to a Notification 209 Service. 211 The Messaging System is referred to as the "Source" of the 212 notification and the Notification Service as the "Service". 213 In client/server terms, the Source is the client and the Service 214 is the server. 216 2. Notification Protocol Contents 218 2.1. Informative 220 The Notification Protocol MUST be informative enough to allow the 221 Notification Service to: 223 - Identify the end user whose inbox has generated the 224 notification. 225 - Identify the end user that should be informed about the 226 notification event (not necessarily the same as the previous 227 end user). 228 - Decide what kind of actions, the notification service 229 should perform, due to the notification request. 230 - Realize the messaging system's task which has caused the 231 notification event. The task may be related to one of the 232 following: 233 - New message Task 234 - New Message Deposit 235 - Mailbox Manipulation Task (e.g. Login, Logout, etc.) 236 -Login to mailbox 237 -Logout from mailbox 238 -Read message 239 -Delete Message 240 -Purge Message 241 - Management Task (e.g. Mailbox Full) 242 - Mailbox full 243 - Mailbox full cancellation 244 The task's types list, as defined above, SHOULD be extendable. 246 Decktor Expires January 2005 Page [5] 247 In addition, the Notification Protocol SHOULD be informative enough 248 to allow the Notification Service to: 250 - Provide a rich experience to the end user of the notification, 251 without the need to actually retrieve the message. This MAY 252 include mailbox status, message attributes, etc. 253 - Practice different MWI behaviors (e.g. turn MWI indication off 254 after all the messages in all the end user's mailboxes have 255 been read). 257 2.2. Subscription 259 It is RECOMMENDED that the notification protocol would not deal with 260 subscription. This SHOULD be defined in a complimentary protocol, or 261 left to implementers. 263 The rationale behind this relies a few matters: 264 1. There's no direct necessity of having subscription embedded in the 265 same protocol as notification. it's possible to have it in a complimentary 266 dedicated protocol. 267 2. This is also the current status of email messaging(no standard 268 subscription protocol). 270 2.3. Extensibility 272 It is assumed that the notification protocol describes the Mailbox 273 status. Therefore, its data schema MUST be extendable. 275 The notification protocol deals with messaging server-to-server 276 notification. However, in order to allow future extension both in 277 the event types and the initial payload, the protocol must adapt a 278 format that is extendable. For example, if a messaging system needs 279 to send a message�s attribute, which isn�t defined in the protocol�s 280 definition (x-header, for example), to the notification service, the 281 protocol MUST allow it. 283 2.4. Exception Handling 285 The notification protocol MUST provide a manner for the notification 286 service to notify the messaging system about the outcome of the 287 notification request (notification status message). The notification 288 service MUST notify the messaging system whenever a protocol 289 violation has occurred. If the request has failed, the data in this 290 notification MUST be coherent enough to allow the messaging system 291 to determine the cause of the failure. 293 The notification service MUST make a distinction between events in 294 which the content of the request has caused an error(request 295 errors), and cases in which a non-source-related reason has caused 296 the error. 298 The Messaging system SHOULD parse the notification status message to 299 decide its next actions (e.g. clear the message�s content, recompile 300 the message�s data, etc.). 302 Decktor Expires January 2005 Page [6] 303 2.5. Retrieval 305 The notification protocol SHOULD allow the source to send URL, as 306 defined in [RFC-URL], referring to the message which has caused the 307 event, to the notification service (and eventually, to the end 308 user). 310 3. Notification Protocol Payload Semantics 312 3.1. Attributes 314 The data items, which would be transferred using the notification 315 protocol, are referred to as attributes. The attributes set could 316 be divided into 2 subsets: mandatory attributes and optional 317 attributes. 319 The structure of these attribute sets MAY be complex. This means 320 that different types of notification requests MAY be composed from 321 different sets of attributes. 322 For example: it may be required in the event of a new message deposit 323 to send the message context [RFC-3458] value as well, and not send 324 this attribute in events which describe a mailbox full event. 325 Another example: it SHOULD be possible that when the protocol�s version 326 is x, there would be a specific set of attributes, and on version x+1 327 there would be a different set. 329 3.1.1. Mandatory Attributes 330 The absence of mandatory attributes is a protocol violation. An 331 example for such an attribute would be end Subscriber Identification 332 (only an example � this name is not committing). 334 In case of a protocol violation, the notification service MUST 335 notify the messaging system. 337 3.1.2. Additional Attributes 338 Additional attributes are not required, that is their absence does 339 not cause a protocol violation. It is RECOMMENDED that the 340 messaging system would send as many additional attributes as 341 possible to allow maximum accuracy in the notification process. 342 However, a notification service MUST be able to function without 343 any given additional field. 345 Decktor Expires January 2005 Page [7] 346 3.2. Events Order 347 It is assumed that the order of the mailbox events, which have 348 occurred in a given mailbox is important to the notification service. 349 Therefore, it is important that the notification service would have 350 the ability to realize the order of a given group of events. To do 351 so the notification protocol MUST supply manners for the messaging 352 service. 354 3.3. Internationalization 356 The protocol MUST allow the source to encode its data as unicode. 357 The protocol MUST allow the source to encode its data in any other 358 character set. 360 The protocol MUST supply a manner for specifying the character set 361 and/or the encoding of the notification data. 363 The protocol SHOULD specify a default character set to be used, 364 unless otherwise is specified. 366 4. Operations 368 4.1. Scalability 370 The notification protocol SHOULD cause the minimum possible 371 overhead and latency to the messaging system and Notification 372 services which are using it, so that the scale of the systems 373 which use the protocol are not a factor in its implementation. 374 To allow this, the notification protocol MUST assume that: 376 1. The number of subscribers handled within a single messaging 377 system is unlimited. 378 2. The number of subscribers handled within a single notification 379 service is unlimited. 380 3. A single messaging system may work with many notification 381 services. 382 4. A single notification service may work with many messaging 383 systems. 385 In addition to these issues, it is RECOMMENDED, that the 386 underlying transport level for the notification protocol would 387 support the usage of persistent connections. 389 4.2. Reliability 391 It is assumed that the data in a notification request is important, 392 and therefore a high level of reliability is needed. In order to 393 support this, the protocol MUST be implemented in such a manner 395 Decktor Expires January 2005 Page [8] 396 that would allow the source receive an acknowledge of the request's receipt. 397 This means that the messaging system is responsible for the 398 notification request until the notification service, has acknowledged 399 its receipt. 400 In addition, the protocol SHOULD provide means for the source to realize the 401 final status of the notification request(failed, succeeded, succeeded partialy etc...) 402 of the notification request. 404 4.3. Security 406 4.3.1. Threats 407 Certain threats may affect the participant in the notification event 408 (source, service, end user). The following threats are identified: 409 denial of service, IP spoofing, network snooping and impersonation 411 4.3.1.1. Denial of Service (DoS) 413 DoS attack might prevent an end user from receiving a notification 414 message by overloading the service. 416 4.3.1.2. IP Spoofing 418 Since the notification protocol�s payload MAY hold private end 419 user's data, message data and mailbox data, IP spoofing may cause an 420 attack on the end user's privacy. 422 4.3.1.3. Network Snooping 424 Packet sniffing on the notification protocol�s payload may impose a 425 threat on the end user's privacy. 427 4.3.1.4. Impersonation 429 A source impersonation might cause the service to send notification 430 messages on events that did not occur to the end user. 432 4.3.2. Countermeasures 433 The notification protocol MUST supply manners to eiliminate all the 434 threats specified in 2.10.1 (e.g. authentication, encryption). 436 Decktor Expires January 2005 Page [9] 437 5. References 439 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 440 Requirement Levels", BCP 14, RFC 2119, March 1997. 442 [RFC-URI] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform 443 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 444 1998. 446 [RFC-URL] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform 447 Resource Locator(URL)", RFC 1738, December 1994. 449 [RFC-IMAP4] Crispin, M., "Internet Message Access Protocol - Version 450 4rev1", RFC 3501, University of Washington, March 2003. 452 [RFC-3458] E. Burger, E. Candell, C. Eliot, G. Klyne, "Message 453 Context for Internet Mail", RFC 3458, January 2003. 455 6. Acknowledgements 457 The authors wish to acknowledge the following people who helped in 458 the development of this draft: Gal Shapira, Noam Shapira, Ari Erev, 459 Orly Rapaport and Ronit Iaroslavitz. 461 7. Authors' Addresses 463 Gev Decktor 464 Comverse Technology 465 29 Habarzel st. 466 Tel-Aviv 467 Israel 469 Phone: +972-3-7655174 470 Email: gev.decktor@comverse.com 472 8. Change Log 474 00 - Initial version, based on draft-decktor-s2s-notif-01.txt 476 Decktor Expires January 2005 Page [10]