idnits 2.17.1 draft-shapira-snap-05.txt: 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 is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 'SHOULD not' in this paragraph: The service SHOULD not send any informational status codes. The source MUST ignore all informational status codes sent by the service. == 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: Total-Email-Message = counter Total-New-Email-Message = counter Total-New-Urgent-Email-Message = counter Total-Message = counter Total-New-Message = counter Total-New-Urgent-Message = counter Other-Counter = "Total-" Message-Context | "Total-New-" Message-Context | "Total-New-Urgent-" Message-Context Note: Message-Context in Other-Counter - MUST not be one of the following: "voice-message", "fax-message" or "text-message" as they are predefined counters. -- 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 (November 2002) is 7823 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 47 -- Looks like a reference, but probably isn't: '2' on line 101 -- Looks like a reference, but probably isn't: '3' on line 156 -- Looks like a reference, but probably isn't: '4' on line 173 -- Looks like a reference, but probably isn't: '5' on line 225 -- Looks like a reference, but probably isn't: '6' on line 276 -- Looks like a reference, but probably isn't: '7' on line 328 -- Looks like a reference, but probably isn't: '8' on line 379 -- Looks like a reference, but probably isn't: '9' on line 429 -- Looks like a reference, but probably isn't: '10' on line 481 -- Looks like a reference, but probably isn't: '11' on line 534 -- Looks like a reference, but probably isn't: '12' on line 585 -- Looks like a reference, but probably isn't: '13' on line 639 -- Looks like a reference, but probably isn't: '14' on line 694 -- Looks like a reference, but probably isn't: '15' on line 743 -- Looks like a reference, but probably isn't: '16' on line 793 -- Looks like a reference, but probably isn't: '17' on line 844 -- Looks like a reference, but probably isn't: '18' on line 893 -- Looks like a reference, but probably isn't: '19' on line 947 -- Looks like a reference, but probably isn't: '20' on line 1000 -- Looks like a reference, but probably isn't: '21' on line 1051 -- Looks like a reference, but probably isn't: '22' on line 1098 -- Looks like a reference, but probably isn't: '23' on line 1149 -- Looks like a reference, but probably isn't: '24' on line 1186 -- Looks like a reference, but probably isn't: '25' on line 1234 -- Looks like a reference, but probably isn't: '26' on line 1287 -- Looks like a reference, but probably isn't: '27' on line 1338 -- Looks like a reference, but probably isn't: '28' on line 1387 -- Looks like a reference, but probably isn't: '29' on line 1436 -- Looks like a reference, but probably isn't: '30' on line 1454 == Unused Reference: 'RFC-MIME1' is defined on line 1317, but no explicit reference was found in the text == Unused Reference: 'RFC-2183' is defined on line 1334, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (ref. 'RFC-HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2234 (ref. 'RFC-ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2396 (ref. 'RFC-URI') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2184 (Obsoleted by RFC 2231) ** Obsolete normative reference: RFC 2060 (ref. 'RFC-IMAP4') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 1894 (ref. 'RFC-DSN') (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 2298 (ref. 'RFC-MDN') (Obsoleted by RFC 3798) Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 32 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Simple Notification and Alarm Protocol (SNAP) November 2002 3 Internet Draft Noam Shapira 4 Document: draft-shapira-snap-05 Eran Aloni 5 Category: Informational Comverse Technology 6 Expires: May 1, 2003 7 November, 3 2002 9 Simple Notification and Alarm Protocol (SNAP) 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or made obsolete by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This memo suggests a protocol for messaging notification in 35 which a messaging system (e.g. email server, voice mail system, 36 etc.) notifies a notification service, and through it the user, 37 that changes have occurred in a user's mailbox (new message 38 arrived, mailbox is full, etc.). The protocol aims to provide the 39 end-user with unified notification of events occurring on different 40 messaging systems. 42 A mailing list has been established to discuss this draft and 43 promote the issue of Notification to RFC. To subscribe, send 44 email with "subscribe snap" to majordomo@lists.neystadt.org 45 or using web at http://www.neystadt.org/cgi-bin/majordomo. 47 Shapira Informational - Expires May 2003 Page [1] 48 Simple Notification and Alarm Protocol (SNAP) November 2002 50 Table of Contents 52 1 Introduction ................................................ 5 53 1.1 Scope ................................................... 5 54 1.2 Terminology ............................................. 6 55 1.3 Notification Protocol High level requirements ........... 7 56 1.3.1 Informative ......................................... 7 57 1.3.2 Minimum latency ..................................... 7 58 1.3.3 Large Scale ......................................... 7 59 1.4 Organization of This Document ........................... 7 60 2 Basic Operation ............................................. 8 61 2.1 The Transport Layer...................................... 8 62 2.1.1 HTTP Compliance ..................................... 9 63 2.1.2 HTTP Method ......................................... 9 64 2.1.3 Request URI ......................................... 9 65 2.1.4 Request Payload ..................................... 9 66 2.1.5 Charset and Encoding ................................ 9 67 2.1.6 Response Payload .................................... 9 68 2.1.7 Persistent Connections .............................. 10 69 2.1.8 HTTP Port ........................................... 10 70 2.2 Request Flow ............................................ 10 71 2.2.1 Request Order ....................................... 10 72 2.2.2 Coherence ........................................... 10 73 2.2.3 Response ............................................ 10 74 2.2.4 Retries ............................................. 11 75 2.2.5 Pipelining .......................................... 11 76 3 Request ..................................................... 11 77 3.1 Protocol Header ......................................... 11 78 3.1.1 Notification-Protocol-Version (M) ................... 11 79 3.1.2 Application-Name (M) ................................ 11 80 3.1.3 Application-Version (M) ............................. 12 81 3.1.4 Server-Type (M) ..................................... 12 82 3.1.5 Request-Type (M) .................................... 12 83 3.1.6 Request-Time ........................................ 12 84 3.1.7 Request-Id .......................................... 12 85 3.2 Request Types ........................................... 12 86 3.2.1 New-Msg ............................................. 12 87 3.2.2 Read-Msg ............................................ 12 88 3.2.3 Delete-Msg .......................................... 13 89 3.2.4 Purge-Msg ........................................... 13 90 3.2.5 Reject-Msg .......................................... 13 91 3.2.6 Login ............................................... 13 92 3.2.7 Logout .............................................. 13 93 3.2.8 Update .............................................. 13 94 3.2.9 Mailbox-Full ........................................ 13 95 3.2.10 Account-Locked ..................................... 13 96 3.3 AccountLockGroup ........................................ 14 97 3.3.1 Account-Lock-Reason ................................. 14 98 3.4 MailboxGroup ............................................ 14 99 3.4.1 Email-Address (M) ................................... 14 101 Shapira Informational - Expires May 2003 Page [2] 102 Simple Notification and Alarm Protocol (SNAP) November 2002 104 3.4.2 Server-Name ......................................... 14 105 3.4.3 Mailbox-Name ........................................ 14 106 3.5 MessageGroup ............................................ 14 107 3.5.1 Message-Context (M) ................................. 14 108 3.5.2 Msg-Sensitivity ..................................... 14 109 3.5.3 Message-Id .......................................... 14 110 3.5.4 From ................................................ 15 111 3.5.5 To .................................................. 15 112 3.5.6 CC .................................................. 15 113 3.5.7 Subject ............................................. 15 114 3.5.8 Message-Send-Time ................................... 15 115 3.5.9 Message-Receive-Time ................................ 15 116 3.5.10 Message-Size ....................................... 15 117 3.5.11 Msg-Importance ..................................... 15 118 3.5.12 Body ............................................... 15 119 3.5.13 Delivery-Report-Msg ................................ 16 120 3.6 CountersGroup ........................................... 16 121 3.6.1 Total-Voice-Message ................................. 17 122 3.6.2 Total-New-Voice-Message ............................. 17 123 3.6.3 Total-New-Urgent-Voice-Message ...................... 17 124 3.6.4 Total-Fax-Message ................................... 17 125 3.6.5 Total-New-Fax-Message ............................... 17 126 3.6.6 Total-New-Urgent-Fax-Message ........................ 17 127 3.6.7 Total-Email-Message ................................. 17 128 3.6.8 Total-New-Email-Message ............................. 17 129 3.6.9 Total-New-Urgent-Email-Message ...................... 17 130 3.6.10 Total-Message ...................................... 17 131 3.6.11 Total-New-Message .................................. 17 132 3.6.12 Total-New-Urgent-Message ........................... 18 133 3.7 RejectGroup ............................................. 18 134 3.7.1 Reject-Reason ....................................... 18 135 3.8 MailboxCapacityGroup .................................... 18 136 3.8.1 Mailbox-Capacity .................................... 18 137 3.8.2 Mailbox-Capacity-Threshold .......................... 18 138 3.8.3 Mailbox-Full-Status ................................. 18 139 4 Response .................................................... 18 140 4.1 Status Codes ............................................ 19 141 4.1.1 Informational (1xx) Status Codes .................... 19 142 4.1.2 Successful (2xx) Status Codes .................... 19 143 4.1.3 Redirection (3xx) Status Codes .................... 19 144 4.1.4 Client Error (4xx) Status Codes .................... 19 145 4.1.5 Server Error (5xx) Status Codes .................... 19 146 4.1.6 "404 Not Found" ..................................... 20 147 4.2 Request-Id .............................................. 20 148 4.3 Description ............................................. 20 149 5 Protocol Syntax ............................................. 20 150 5.1 Basic Rules ............................................. 20 151 5.2 Request Syntax .......................................... 21 152 5.2.1 General Attribute Syntax............................. 21 153 5.2.2 Attribute Groups .................................... 21 154 5.2.3 Attributes .......................................... 23 156 Shapira Informational - Expires May 2003 Page [3] 157 Simple Notification and Alarm Protocol (SNAP) November 2002 159 5.3 Response Syntax ......................................... 24 160 5.4 Examples ................................................ 25 161 6 Security Considerations ..................................... 25 162 7 IANA Considerations ......................................... 26 163 8 References .................................................. 27 164 9 Acknowledgements ............................................ 28 165 10 Authors' Addresses ......................................... 28 167 A. Historical Overview of Notification Issue................... 29 168 B. List of changes from ..-01 version ......................... 29 169 C. List of changes from ..-02 version ......................... 29 170 D. List of changes from ..-03 version ......................... 30 171 E. List of changes from ..-04 version ......................... 30 173 Shapira Informational - Expires May 2003 Page [4] 174 Simple Notification and Alarm Protocol (SNAP) November 2002 176 1. Introduction 178 1.1 Scope 180 The suite of Internet mail protocols (POP3, IMAP4) allows different 181 mail clients to access and manipulate electronic mail messages on 182 a messaging system. These protocols do not provide off-line methods 183 by which a user can be notified upon changes in the mailbox 184 status. Further, none of the mentioned protocols define a way to 185 aggregate the status within the user's various mailboxes. 187 In order to provide a user with the ability of unified notification 188 and one centralized message-waiting indication (MWI), a notification 189 service is needed to aggregate the information of all the events 190 occurring on the user's different messaging systems. 192 This memo suggests a protocol in which a messaging system notifies 193 a notification service of events occurring in a user's mailbox. 194 For example, when a message is deposited (SMTP), the email server 195 sends a "new message" notification to the service, which may then 196 notify the user by sending him a Short Text Message (SMS). 198 The following figure depicts the SNAP scope: 200 +--------+ +--------+ 201 New | | | | 202 Message | Email | \ | SMS | 203 -------> |Server 1| \ _ | | 204 +--------+ \ /| +--------+ 205 ^ \ / 206 | \ / 207 | \ / 208 +--------+ | _|+--------------+ / +-----------+ 209 Read | Voice | | | |/ |Message | 210 Message | Mail |-------->| Notification |------->|Waiting | 211 -------> | Server | | ^ _ | Service |\ |Indication | 212 +--------+ | | /| +--------------- \ +-----------+ 213 | |/ \ 214 | / ^ \ 215 |/| | \ 216 +--------+ / | | \ +--------+ 217 Delete | | /| | | \ | | 218 Message | Email |/ | | | _|| WAP | 219 -------> |Server 2| | | | | Push | 220 +--------+ | | | +--------+ 221 | | | 222 | | | 223 SNAP 225 Shapira Informational - Expires May 2003 Page [5] 226 Simple Notification and Alarm Protocol (SNAP) November 2002 228 This can be extended to include other mailbox events that are of 229 importance to a user, such as "mailbox full" and "message rejected". 230 Each notification should include additional information that is 231 available to the user such as the number of messages in the mailbox, 232 mailbox quota, and MIME headers of incoming messages. 234 1.2 Terminology 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 237 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 238 "OPTIONAL" in this document are to be interpreted as described 239 in [KEYWORDS]. 241 This specification uses the following terms: 243 Message Waiting Indication (MWI) 244 A mechanism that indicates to the user that a message is waiting 245 in a mailbox. The MWI can be indicated by SMS icon, telephony 246 stutter tone, MWI lamp on the phone, etc. The MWI has two states: 247 ON or OFF. 249 Notification Event 250 An event that might cause a notification to the user or change 251 the MWI state (ON or OFF). 253 Messaging System 254 A system that maintains a set of one or more mailboxes for user's 255 messages, for example: Email servers, Voice-mail systems, etc. 256 The messaging system is the application that initiates the SNAP 257 session. 259 Notification Service 260 A system that is responsible for aggregating all Notification 261 Events from the different Messaging Systems, and sends them to 262 the user. The messaging system will use the SNAP to send 263 Notification Events to the Notification service. 265 Notification Protocol 266 A protocol that describes how to pass Notification Event 267 information from the Messaging System to the Notification 268 Service. This memo will propose the SNAP as a Notification 269 Protocol. 271 The Messaging System is referred to as the "Source" of the 272 notification and the Notification Service as the "Service". 273 In client/server terms, the Source is the client and the Service is 274 the server. 276 Shapira Informational - Expires May 2003 Page [6] 277 Simple Notification and Alarm Protocol (SNAP) November 2002 279 1.3 Notification Protocol High level requirements 281 This section will describe the major requirements from a Notification 282 Protocol and will serve as a basis for the design of the SNAP. 284 1.3.1 Informative 286 The Notification Protocol should be informative enough to allow the 287 Notification Service to: 289 - Identify the person that should be informed on the mailbox 290 status change. 291 - Decide if the Notification Event is interesting enough for the 292 user. This will enable the service provider and the end user 293 to personalize the notification behavior for each user. For 294 example, the user of the Notification Service can decide to be 295 notified only on receipt of a message from a specific person, 296 or with a specific subject. 297 - Practice different MWI behaviors (e.g. turn MWI indication off 298 after all the messages in all the user's mailboxes have been 299 read). 301 1.3.2 Minimum latency 303 The latency between the original time of the Notification Event and 304 the time the end user receives the notification depends on various 305 network elements taking part in the notification process. 307 The Notification Protocol should enable the Messaging System to 308 inform the Notification Service as soon as possible to help minimize 309 notification latency. 311 1.3.3 Scalability 313 The Notification Protocol should assume that it will be applied in 314 large scale systems including one or more messaging systems and a 315 notification service. 317 1.4 Organization of This Document 319 This document tries to separate it's three main issues: 321 - Protocol flow (covered in section 2) covers the underlying 322 transport protocol (HTTP) and the request flow. 323 - Protocol semantics covers the request payload (section 3) and the 324 response payload (section 4) semantics. 325 - Protocol syntax (covered in section 5) covers the payload, defined 326 in section 3 and 4, syntax. 328 Shapira Informational - Expires May 2003 Page [7] 329 Simple Notification and Alarm Protocol (SNAP) November 2002 331 2. Basic Operation 333 The Messaging System notifies a Notification Service of events 334 occurring (Notification Events) in a user's mailbox. 336 A Messaging System can be roughly broken down into the following 337 processes: 339 Message Deposit process- a message is deposited in a user's 340 mailbox. In this case, if the deposit is successful, the Messaging 341 System will send a "new message" request to the Notification 342 Service. The request will include partial MIME headers of the 343 incoming message. If the new message was rejected, the Messaging 344 System will send a "message reject" request. An example of a process 345 like this is the SMTP process in email servers. 347 Mailbox manipulation process - Handles user's interaction with 348 mailbox. The process sends requests when a user logs in, logs out, 349 reads a message, or deletes a message. These requests will help the 350 service to hold email counters and operate the Message Waiting 351 Indication (MWI) mechanism. For example user�s login can trigger 352 notification event that will eventually turn MWI off. An example of 353 a process like this is the IMAP4 process in email servers. 355 Management process - purges old messages, locks a mailbox if it has 356 exceeded its quota, etc. The management process sends 357 "purge message", "mailbox full", and "account locked" requests. 359 The above breakdown serves to illustrate the flow and is not part 360 of the suggested protocol. The syntax of each request is described 361 later in the memo. 363 The SNAP will use a request/response model protocol to transfer the 364 information between the Messaging System and the Notification 365 service. The Notification Service "listens" for notification 366 requests. When a request is accepted, it is processed and a response 367 is returned. 369 2.1 The Transport Layer 371 The suggested protocol uses HTTP as an underlying transport layer. 372 The messaging system sends a HTTP request with the POST method. The 373 notification service replies with a HTTP response. A great deal of 374 thought has been spent on choosing the correct underlying transport 375 protocol. HTTP has been chosen as it is widely deployed over the net 376 and provides the needs of the notification protocol - as described 377 in section 1.3 in this document. 379 Shapira Informational - Expires May 2003 Page [8] 380 Simple Notification and Alarm Protocol (SNAP) November 2002 382 2.1.1 HTTP Compliance 384 The source and the service MUST comply with HTTP 1.1 as described 385 in [RFC-HTTP]. 387 2.1.2 HTTP Method 389 The source MUST use the HTTP POST method in the request. 391 2.1.3 Request URI 393 The Uniform Resource Identifiers (URI) sent by the source to the 394 service MUST be agreed by the Messaging Server and the Notification 395 Service. The URI MUST comply with [RFC-URI]. 397 2.1.4 Request Payload 399 The source MUST pass the request payload in the HTTP body as 400 described in [RFC-HTTP]. The payload will be a set of MIME like 401 field-value pairs. 403 The source MUST use the HTTP Content-type value: text/SNAP in the 404 request. 406 The request payload will be described in section 3. Section 5 will 407 describe the payload syntax. 409 2.1.5 Charset and Encoding 411 The source MUST send a charset header if the protocol fields are not 412 in the ISO-8859-1 char set as described in [RFC-HTTP]. 414 The source MAY specify parameter values in character sets other than 415 US-ASCII as specified in [RFC-2184]. 417 2.1.6 Response Payload 419 The service MUST send a response using the HTTP response standard 420 error codes. The response payload MUST be passed by the HTTP body as 421 described in [RFC-HTTP]. 423 The service MUST use the HTTP Content-type value: text/SNAP in 424 response. 426 Section 4 describes the response payload. Section 5 describes the 427 response syntax. 429 Shapira Informational - Expires May 2003 Page [9] 430 Simple Notification and Alarm Protocol (SNAP) November 2002 432 2.1.7 Persistent Connections 434 The underlying transport may support sending multiple requests over 435 the same connection. 437 The Notification Service MUST support persistent connections and use 438 them upon source requests. 440 The motivation for this is that Notification Service is assumed to 441 be handling large amount of requests and this will significantly 442 optimize its operation. 444 2.1.8 HTTP Port 446 The Notification service MUST NOT use the standard HTTP port 447 [RFC-HTTP] for incoming SNAP request. The Notification Service 448 will use port number that will be provided by IANA for incoming 449 SNAP requests. 451 2.2 Request Flow 453 2.2.1 Request Order 455 The source SHOULD send the requests to the service in the same 456 order as the events that triggered them occurred. This will help to 457 keep a consistent behavior. For example: if there are two 458 notifications events, one indicating the user has one new message 459 and the second indicating there are two new messages, the user must 460 receive the first before the second. 462 This will be completed my a request time stamp that will help the 463 service maintain the consistent behavior. See Request-Time 464 attribute. 466 2.2.2 Coherence 468 The source MUST send a request only after the action has been 469 successfully completed. For example, "new message" notification MUST 470 be sent only after the message has been deposited in the user 471 mailbox. 473 2.2.3 Response 475 Upon receiving a request, the service MUST return a response 476 including a status code. 478 The source SHOULD parse the response to retrieve the error code and 479 determine success or failure of the request. 481 Shapira Informational - Expires May 2003 Page [10] 482 Simple Notification and Alarm Protocol (SNAP) November 2002 484 2.2.4 Retries 486 Upon receiving a response from the service indicating a failure, the 487 source SHOULD retry the request in case the service failure is 488 recoverable (i.e. temporary). If the source does not receive a response 489 from the service, it SHOULD retry as well. 491 Section 4 describes the different possible responses and gives 492 general guidelines regarding which responses should result in a 493 retry. 495 2.2.5 Pipelining 497 The source SHOULD pipeline requests according to [RFC-HTTP] part 498 8.1.2. If the source pipelines requests, the service SHOULD send 499 its responses in the same order in which they where received. 501 3. Request 503 Each Request includes a Header and a Body. Each of them consists of 504 pairs of fields and values. This section describes the semantics of 505 these attributes. Section 5 describes the attributes' syntax. 507 Each request MUST include a protocol header. One of the attributes 508 in the protocol header is the Request-Type. The Request-Type value 509 describes an event that triggered the request (for example 510 "NewMessage") and which additional attributes are included in the 511 request body. The additional attributes are grouped. The groups and 512 attributes in each group are listed in this section. 514 Mandatory attributes in each group are marked with (M). Mandatory 515 groups tied to a request type are also marked with (M). If a group 516 is mandatory for a request type , the mandatory attributes of the 517 group MUST appear in the request. 519 The source MUST send all mandatory attributes as described below: 521 3.1 Protocol Header 523 The header consists of the following attributes: 525 3.1.1 Notification-Protocol-Version (M) 527 The version of this protocol MUST be 1.0. 529 3.1.2 Application-Name (M) 531 The name of the source sending the request. This name identifies the 532 source and need not be unique. 534 Shapira Informational - Expires May 2003 Page [11] 535 Simple Notification and Alarm Protocol (SNAP) November 2002 537 3.1.3 Application-Version (M) 539 The version of the application sending the request. 541 3.1.4 Server-Type (M) 543 The type of server sending the request. Source MUST send either 544 "EMAIL" or "VOICE" in this field. In the future the protocol may be 545 extended to add other values. 547 3.1.5 Request-Type (M) 549 A string specifying the type of the request. Request types are 550 listed in section 3.2. 552 3.1.6 Request-Time 554 The time the request was sent by the source. Value MUST be in GMT. 556 3.1.7 Request-Id 558 A unique identifier used by the source of the request to identify 559 the request. This MAY be an incremental counter or a text value. 560 The source SHOULD set the Request-Id attribute if it is pipelining 561 in order to retry failed requests, since the order of responses is 562 not guaranteed. 564 The source is RECOMMENDED to set this attribute for debugging and 565 logging purposes. 567 3.2 Request Types 569 This section describes the trigger for sending each request type 570 and lists the groups of attributes that SHOULD appear in the 571 request. 573 3.2.1 New-Msg 575 Trigger: A new message has been deposited in the user's mailbox. 577 Groups: MailboxGroup(M) ,MessageGroup(M), CountersGroup. 579 3.2.2 Read-Msg 581 Trigger: User reads a message from his mailbox. 583 Groups: MailboxGroup(M) ,MessageGroup(M), CountersGroup. 585 Shapira Informational - Expires May 2003 Page [12] 586 Simple Notification and Alarm Protocol (SNAP) November 2002 588 3.2.3 Delete-Msg 590 Trigger: User deletes a message from mailbox. 592 Groups: MailboxGroup(M) ,MessageGroup(M), CountersGroup. 594 3.2.4 Purge-Msg 596 Trigger: Messaging System purges a message from mailbox. 598 Groups: MailboxGroup(M) ,MessageGroup(M), CountersGroup. 600 3.2.5 Reject-Msg 602 Trigger: Messaging System rejects a message destined to a user. 604 Groups: MailboxGroup(M) ,MessageGroup(M), RejectGroup, 605 CountersGroup. 607 3.2.6 Login 609 Trigger: User logs into mailbox. 611 Groups: MailboxGroup(M) , CountersGroup. 613 3.2.7 Logout 615 Trigger: User logs out of mailbox. 617 Groups: MailboxGroup(M) , CountersGroup. 619 3.2.8 Update 621 Trigger: An event has occurred in the mailbox but Messaging System 622 is unaware of the event type. 624 Groups: MailboxGroup(M) ,MessageGroup, CountersGroup. 626 3.2.9 Mailbox-Full 628 Trigger: The user mailbox has exceeded its threshold quota. 630 Groups: MailboxGroup(M) , CountersGroup, MailboxCapacityGroup. 632 3.2.10 Account-Locked 634 Trigger :The user mailbox has been locked for administrative 635 reasons. 637 Groups : MailboxGroup(M) , CountersGroup, AccountLockGroup. 639 Shapira Informational - Expires May 2003 Page [13] 640 Simple Notification and Alarm Protocol (SNAP) November 2002 642 3.3 AccountLockGroup 644 3.3.1 Account-Lock-Reason 646 A string containing a description of the lock reason. 648 3.4 MailboxGroup 650 3.4.1 Email-Address (M) 652 The fully qualified email address for the mailbox. 654 3.4.2 Server-Name 656 The name of the host the source is running on. 658 3.4.3 Mailbox-Name 660 The IMAP4 [RFC-IMAP4] mailbox (folder). This attribute will be used 661 when the message is not deposited to the Inbox folder, rather to a 662 different folder. If this attribute is missing from the SNAP 663 request - "INBOX" value will be assumed. 665 3.5 MessageGroup 667 3.5.1 Message-Context (M) 669 The message context is used by the service to enable the end user to 670 define different behaviors for different message types. 672 This attribute must comply with the Message-Context as defined 673 in [HINT]. 675 3.5.2 Msg-Sensitivity 677 The message content sensitivity as seen by the sender. 679 The legal values are Personal, private, company confidential as 680 defined in [HEADER]. The absence of this header field in the request 681 will indicate that the message is not sensitive. 683 3.5.3 Message-Id 685 Unique identifier that can be used by the Notification Service or 686 any other user agent (UA) to retrieve the message. The message id 687 should comply with [RFC-2822]. The Message-Id MUST persist across 688 sessions in the source, in order to allow the UA to retrieve the 689 message at any time. 691 In case where the source is an Email Server, the source SHOULD send 692 the IMAP4 UID [RFC-IMAP4]. 694 Shapira Informational - Expires May 2003 Page [14] 695 Simple Notification and Alarm Protocol (SNAP) November 2002 697 3.5.4 From 699 The message "From" header as in [RFC-2822]. 701 3.5.5 To 703 The message "To" header as in [RFC-2822]. 705 3.5.6 CC 707 The message "cc" header as in [RFC-2822]. 709 3.5.7 Subject 711 The message "Subject" header as in [RFC-2822]. 713 3.5.8 Message-Send-Time 715 The time the message has been sent as described in the message. 716 This MAY be the value of the Date header as defined in [RFC-2822]. 718 3.5.9 Message-Receive-Time 720 The time the message was received in the source expressed in GMT. 721 This MAY be the value of the IMAP4 Internal Date Message Attribute 722 as defined in [RFC-IMAP4] 724 3.5.10 Message-Size 726 A number that indicates the message size in bytes. If there are 727 attachments to the message, the size SHOULD include the size of 728 the attachments. 730 3.5.11 Msg-Importance 732 Importance of message as described in [HEADER] - Importance is 733 a user-presentation attributes intended to convey the senders 734 sense of importance of the message to the recipient. 736 Legal values are 'high', 'low' or 'normal'. 738 3.5.12 Body 740 The source SHOULD send the body of the MIME message in certain 741 requests as described later. When doing so, the following apply: 743 Shapira Informational - Expires May 2003 Page [15] 744 Simple Notification and Alarm Protocol (SNAP) November 2002 746 The source MUST copy the Content-Type header from the MIME message 747 to the request header. 749 The source MUST NOT send the body if the Content-Type is not "text". 750 All text subtypes are allowed. 752 The source MAY send only part of the body (for example the first 100 753 octets). 755 The source MUST add a Content-Length header to the request 756 specifying the size of the body. 758 3.5.13 Delivery-Report-Msg 760 If the message received is a DSN or a MDN, a string with value Yes. 761 See RFC [RFC-DSN] and [RFC-MDN] 763 3.6 CountersGroup 765 The counter group includes the count of messages in the user's 766 mailbox according to categories. The categories are type (as defined 767 in Message-Context), Freshness (New or not) and Urgency (Urgent or not). 769 A message is considered fresh if its unseen flag is true. It 770 is considered Urgent if the Msg-Importance attribute as described in 771 the MessageGroup is "high". Categorization to type is done with 772 accordance to the email Message-Context attribute as described in the 773 MessageGroup. 775 The value of each counter MUST be 0 or higher; or (-1) CAN be used 776 if value is unknown. 778 Following are a set of pre-defined counter types. The pre-defined 779 types are for Email, Voice and Fax messages. Each one is mapped 780 to a different Message-Context value: 781 - Email - "text-message" 782 - Voice - "voice-message" 783 - Fax - "fax-message" 785 Other counters (for other types of Message-Context) may be added as 786 following: 787 - Total-X 788 - Total-New-X 789 - Total-New-Urgent-X 791 Where X is a known Message-context as defined later in this document. 793 Shapira Informational - Expires May 2003 Page [16] 794 Simple Notification and Alarm Protocol (SNAP) November 2002 796 3.6.1 Total-Voice-Message 798 Total number of voice messages in mailbox. 800 3.6.2 Total-New-Voice-Message 802 Number of new voice messages in mailbox. This includes messages 803 that are new and urgent. 805 3.6.3 Total-New-Urgent-Voice-Message 807 Number of new urgent voice messages in mailbox. 809 3.6.4 Total-Fax-Message 811 Total number of fax messages in mailbox. 813 3.6.5 Total-New-Fax-Message 815 Number of new fax messages in mailbox. This includes messages that 816 are new and urgent. 818 3.6.6 Total-New-Urgent-Fax-Message 820 Number of new urgent fax messages in mailbox. 822 3.6.7 Total-Email-Message 824 Total number of email messages in mailbox. 826 3.6.8 Total-New-Email-Message 828 Number of new email messages in mailbox. This includes messages that 829 are new and urgent. 831 3.6.9 Total-New-Urgent-Email-Message 833 Number of new urgent email messages in mailbox. 835 3.6.10 Total-Message 837 Total number of messages in mailbox. 839 3.6.11 Total-New-Message 841 Number of all new messages in mailbox. This includes messages that 842 are new and urgent. 844 Shapira Informational - Expires May 2003 Page [17] 845 Simple Notification and Alarm Protocol (SNAP) November 2002 847 3.6.12 Total-New-Urgent-Message 849 Number of all new urgent messages in mailbox. 851 3.7 RejectGroup 853 3.7.1 Reject-Reason 855 A string containing a description of the reject reason. 857 3.8 MailboxCapacityGroup 859 3.8.1 Mailbox-Capacity 861 Actual usage percentage of user's mailbox. 863 3.8.2 Mailbox-Capacity-Threshold 865 Usage percentage threshold of user's mailbox. 867 If Mailbox-Capacity > Mailbox-Capacity-Threshold --> Mailbox is 868 full. This is also the default if one (or both) of these attributes 869 are not part of the request. 871 If Mailbox-Capacity <= Mailbox-Capacity-Threshold --> Mailbox was 872 full, but it is not full any more (capacity is now below 873 threshold) 875 3.8.3 Mailbox-Full-Status 877 The mailbox full status attribute SHOULD be used to describe the 878 implications of the fact that the mailbox is full, e.g. "Message 879 retrieval disabled" or "No more messages can be stored in the 880 mailbox". 882 4. Response 884 The service MUST send a response for each request. The response MUST 885 include a standard status code [RFC-HTTP]. 887 The service MAY use proprietary status codes, as long as they 888 comply with the standard classification of status codes according 889 to their numbering convention. 891 The syntax of the response in ABNF is listed in section 5. 893 Shapira Informational - Expires May 2003 Page [18] 894 Simple Notification and Alarm Protocol (SNAP) November 2002 896 4.1 Status Codes 898 4.1.1 Informational (1xx) Status Codes 900 The service SHOULD not send any informational status codes. 901 The source MUST ignore all informational status codes sent by the 902 service. 904 4.1.2 Successful (2xx) Status Codes 906 The service SHOULD return "200 Ok" status code if request succeeded. 908 The service MAY return additional success (2xx) codes. 910 After receiving a successful status code, the source MUST NOT 911 perform retries. 913 4.1.3 Redirection (3xx) Status Codes 915 4.1.3.1 "301 Moved Permanently" 917 Upon receiving this status code, the source MUST resend the 918 notification request to the new URI specified in the location 919 field of the response. 921 When sending other requests after receiving this response, the 922 source SHOULD use the new URL that is part of the URI returned in 923 the "location" field. 925 4.1.3.2 "307 Temporary Redirect" 927 Upon receiving this status code, the source MUST resend the request 928 to the new URI specified in the location field of the response. The 929 source MUST NOT change its behavior when sending future requests. 931 4.1.4 Client Error (4xx) Status Codes 933 The service MUST send a client error status code when it finds out 934 that the request format or content are illegal. 936 The service SHOULD use the "400 Bad Request" status code, but MAY 937 also use other (including proprietary) client error status codes. 939 The source MUST NOT perform retries upon receiving one of these 940 status codes as a reply. 942 4.1.5 Server Error (5xx) Status Codes 944 The service MUST return a server error status code when it fails 945 to process the request due to some internal error. 947 Shapira Informational - Expires May 2003 Page [19] 948 Simple Notification and Alarm Protocol (SNAP) November 2002 950 The service SHOULD use the "500 Internal Server Error" status 951 code, but MAY also use other (including proprietary) server error 952 status codes. 954 Upon receiving any server error status code, the source SHOULD 955 perform retries. 957 4.1.6 "404 Not Found" 959 The service MUST NOT return a "404 Not Found" status code. The HTTP 960 server will return this status code when it cannot find the service. 962 The source MUST treat this error as if it were a Server error 963 par 4.1.5 above). 965 4.2 Request-Id 967 The service MUST send the Request-Id if available as part 968 of the original request. 970 4.3 Description 972 The response MAY include additional text description. 974 5. Protocol Syntax 976 Section 2 describes the interaction with the underlying transport 977 protocol. Section 3 described the semantics of each attribute in the 978 header and the body of the request. Section 4 described the 979 semantics of each attribute in the response. This section will 980 describe the syntax of the request and the response. 982 The section uses the [RFC-ABNF] syntax. 984 5.1 Basic Rules 986 The following rules are defined in [RFC-HTTP] 987 OCTET = 988 CHAR = 989 UPALPHA = 990 LOALPHA = 991 ALPHA = UPALPHA | LOALPHA 992 DIGIT = 993 CTL = 995 CR = 996 LF = 997 SP = 998 HT = 1000 Shapira Informational - Expires May 2003 Page [20] 1001 Simple Notification and Alarm Protocol (SNAP) November 2002 1003 <"> = 1004 token = 1* 1005 phrase = * 1007 SNAP is a case insensitive in all attributes and values - unless 1008 specified otherwise. 1010 5.2 Request Syntax 1012 The SNAP request from a source to a service is composed of a header 1013 and a body. 1015 SNAP-Request = ProtocolHeader ProtocolBody 1017 A protocol body is composed of a set of one or more Attribute groups 1018 as defined in section 3. 1020 ProtocolBody = 1*AttributeGroup 1022 5.2.1 General Attribute Syntax 1024 Header and body attributes are lines composed in the same manner as 1025 in [RFC-2822]: 1027 :CRLF 1029 Attribute-value can be in different charset and encoding as 1030 described in sub-section 2.1.2. 1032 5.2.2 Attribute Groups 1034 ProtocolHeader = 1035 Notification-Protocol-Version 1036 Application-Name 1037 Application-Version 1038 Server-Type 1039 Request-Type 1040 [Request-Time] 1041 [Request-Id] 1043 AttributeGroup = 1044 MailboxGroup | 1045 MessageGroup | 1046 CountersGroup | 1047 RejectGroup | 1048 MailboxCapacityGroup | 1049 AccountLockGroup 1051 Shapira Informational - Expires May 2003 Page [21] 1052 Simple Notification and Alarm Protocol (SNAP) November 2002 1054 MessageGroup = 1055 Message-Context 1056 [From] 1057 [To] 1058 [CC] 1059 [Subject] 1060 [Message-Send-Time] 1061 [Message-Receive-Time] 1062 [Message-Size] 1063 [Body] 1064 [Msg-Importance] 1065 [Msg-Sensitivity] 1066 [Message-Id] 1067 [Delivery-Report-Msg] 1069 MailboxGroup = 1070 Email-Address 1071 [Server-Name] 1072 [Mailbox-Name] 1074 CountersGroup = 1075 [Total-Voice-Message] 1076 [Total-New-Voice-Message] 1077 [Total-New-Urgent-Voice-Message] 1078 [Total-Fax-Message] 1079 [Total-New-Fax-Message] 1080 [Total-New-Urgent-Fax-Message] 1081 [Total-Email-Message] 1082 [Total-New-Email-Message] 1083 [Total-New-Urgent-Email-Message] 1084 [Total-Message] 1085 [Total-New-Message] 1086 [Total-New-Urgent-Message] 1087 [Other-Counter] 1089 RejectGroup = [Reject-Reason] 1091 MailboxCapacityGroup = 1092 [Mailbox-Capacity] 1093 [Mailbox-Capacity-Threshold] 1094 [Mailbox-Full-Status] 1096 AccountLockGroup = [Account-Lock-Reason] 1098 Shapira Informational - Expires May 2003 Page [22] 1099 Simple Notification and Alarm Protocol (SNAP) November 2002 1101 5.2.3 Attributes 1103 Following is the list of attributes and their valid values. The list 1104 is constructed from: 1106 = ";" 1108 Notification-Protocol-Version = 1*DIGIT "."1*DIGIT 1109 Application-Name = token 1110 Application-Version = token 1111 Server-Type = "EMAIL"|"VOICE" 1112 Request-Type = "New-Msg" | "Read-Msg" | "Delete-Msg" | 1113 "Purge-Msg" | "Reject-Msg" | "login" | 1114 "logout" | "update" | "Mailbox-Full" | 1115 "Account-Locked" 1116 mailbox = As defined in "Address Specification" in [RFC-2822] 1117 Email-Address = mailbox 1118 From = mailbox 1119 To = mailbox 1120 CC = mailbox 1122 SubscribrerId = token 1123 Server-Name = token 1124 Mailbox-Name = token 1125 Message-Context = as defined in [HINT]. 1127 Subject = token ;as described by [RFC-2822] 1129 date-time = As defined in "Date and Time Specification" [RFC-2822] 1130 Request-Time = datetime 1131 Message-Send-Time = datetime 1132 Message-Receive-Time = datetime 1133 Message-Size = *DIGITS 1134 Body = Token 1135 Msg-Importance = "high" | "normal" |"low" ; see [HEADER] 1136 Msg-Sensitivity = "Personal" | "Private" | 1137 "Company-Confidential" ; see [HEADER] 1138 Message-Id = token 1139 Delivery-Report-Msg = "Yes"|"No" 1141 counter = "-1" | *DIGIT 1142 Total-Voice-Message = counter 1143 Total-New-Voice-Message = counter 1144 Total-New-Urgent-Voice-Message = counter 1145 Total-Fax-Message = counter 1146 Total-New-Fax-Message = counter 1147 Total-New-Urgent-Fax-Message = counter 1149 Shapira Informational - Expires May 2003 Page [23] 1150 Simple Notification and Alarm Protocol (SNAP) November 2002 1152 Total-Email-Message = counter 1153 Total-New-Email-Message = counter 1154 Total-New-Urgent-Email-Message = counter 1155 Total-Message = counter 1156 Total-New-Message = counter 1157 Total-New-Urgent-Message = counter 1158 Other-Counter = "Total-" Message-Context | 1159 "Total-New-" Message-Context | 1160 "Total-New-Urgent-" Message-Context 1161 Note: Message-Context in Other-Counter - MUST not be one of the 1162 following: "voice-message", "fax-message" or "text-message" as they 1163 are predefined counters. 1165 percentage = ("0".."100") 1166 Mailbox-Capacity = percentage 1167 Mailbox-Capacity-Threshold = percentage 1169 Reject-Reason = phrase 1170 Mailbox-Full-Status = phrase 1171 Account-Lock-Reason = phrase 1173 5.3 Response Syntax 1175 Response = 1Status-Line *1Request-Id-Line *1Description-Line 1176 Status-Line = 1177 Protocol-Version SP Status-Code SP Reason-Phrase CRLF 1178 Protocol-Version = "Protocol Name" "/" 1*DIGIT "." 1*DIGIT 1179 Status-Code = "1" 2*DIGIT | "2" 2*DIGIT |"3" 2*DIGIT 1180 |"4" 2*DIGIT |"5" 2*DIGIT 1181 Reason-Phrase = * 1182 Request-Id = * 1183 Request-Id-Line = "REQUEST-ID:" *WS 1*request-id *WS CRLF 1184 Description-Line = "Description:" *WS * 1186 Shapira Informational - Expires May 2003 Page [24] 1187 Simple Notification and Alarm Protocol (SNAP) November 2002 1189 5.4 Examples: 1191 Request example: 1193 POST /Notification-Service/notif.cgi HTTP/1.1 ;The URI 1194 Content-Type: text/SNAP; ;From HTTP 1195 charset="utf-8" ;From HTTP 1196 Content-Length: nnnn ;From HTTP 1198 Notification-Protocol-Version:1.1 1199 Application-Name:Applic 1200 Application-Version:1.0 1201 Server-Type:Email 1202 Request-Type:New-Msg 1203 Request-Time:15Feb2000%2012:02:00%20+0000 1204 Request-Id:9941401AA 1205 Message-Context:text-message ;Indicate email 1206 Message-Id:9999 1207 Email-Address:joe@email.com 1208 Server-Name:ES1 1209 Total-Email-Message:20 1210 Total-New-Email-Message:20 1211 Message-Send-Time:15Feb2000%2012:02:00%20+0000 1212 Message-Receive-Time:15Feb2000%2012:02:00%20+0000 1213 Message-Size:20000 1214 Msg-Importance:high 1215 From:Budd@email.com 1216 To:joe@email.com 1217 Subject:Hello%20Joe 1219 Response example (1): 1220 HTTP/1.1 200 OK 1221 Request-Id: 9941401AA 1222 Description: Request%20processed%20successfully 1224 6. Security Considerations 1226 The SNAP describes a server-to-server protocol (Messaging Server 1227 and a Notification Server). The protocol defines the means by 1228 which the Notification Service will receive the event information 1229 and trigger a notification message / action to the user. Following 1230 is a set of threats implementers MUST take in consideration when 1231 defining the integration between the Messaging Server and the 1232 Notification Service: 1234 Shapira Informational - Expires May 2003 Page [25] 1235 Simple Notification and Alarm Protocol (SNAP) November 2002 1237 6.1 Denial of Service (DoS) 1239 SNAP defines the way by which a Messaging System passes the 1240 information to the Notification Service. DoS attack, might 1241 prevent a user from receiving a notification message by overloading 1242 the notification server. The possible countermeasures include: 1243 validating the notification request before processing it, limiting 1244 the number of notification requests from a single store, etc. 1246 6.2 IP Spoofing 1248 As SNAP's payload holds private user's data, message data and 1249 mailbox data, IP spoofing may cause an attack on the user's 1250 privacy. 1252 6.3 Impersonation 1254 A Messaging System impersonation might cause the Notification 1255 Service to send notification messages on events that did not occur. 1257 6.4 Network Snooping 1259 Packet sniffing on the SNAP payload may impose a threat on the 1260 user's privacy. The SNAP's payload SHOULD be secured in order to 1261 prevent network snooping. 1263 7. IANA Considerations 1265 This specification calls for the registration of the new MIME 1266 content-type text/SNAP. 1268 The registration template: 1270 To: ietf-types@iana.org 1271 Subject: Registration of MIME media type text/SNAP 1273 MIME media type name: text 1275 MIME subtype name: SNAP 1277 Required parameters: See section 3 defined mandatory parameters 1279 Optional parameters: See section 3 defined non-mandatory parameters 1281 Encoding considerations: None 1283 Security considerations: None 1285 Interoperability considerations: None 1287 Shapira Informational - Expires May 2003 Page [26] 1288 Simple Notification and Alarm Protocol (SNAP) November 2002 1290 Published specification: This draft 1292 Applications which use this media type: 1293 Messaging System and Notification Services as defined in 1294 this draft. 1296 Additional information: 1297 Magic number(s): None 1298 File extension(s): None 1299 Macintosh File Type Code(s): None 1301 Person & email address to contact for further information: 1303 Noam Shapira: noam.shapira@comverse.com 1305 Intended usage: 1306 Common 1308 Author/Change controller: 1310 noam.shapira@comverse.com 1312 8. References 1314 [RFC-HTTP] Fielding, et al, "Hypertext Transfer Protocol HTTP/1.1", 1315 RFC 2616, June 1999 1317 [RFC-MIME1] Freed, N., and Borenstein, N., "Multipurpose Internet 1318 Mail Extensions (MIME) Part One: Format of Internet Message 1319 Bodies", RFC 2045, November 1996. 1321 [RFC-2822] P. Resnick, "Internet Message Format", RFC 2822, April 1322 2001 1324 [RFC-ABNF] Crocker, D., Editor, and Overell, P., "Augmented BNF for 1325 Syntax Specifications: ABNF", RFC 2234, November 1997. 1327 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1328 Requirement Levels", BCP 14, RFC 2119, March 1997. 1330 [RFC-URI] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform 1331 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1332 1998. 1334 [RFC-2183] Troost, R., Dorner, S., and Moore, K., "Communicating 1335 Presentation Information in Internet Messages: The 1336 Content-Disposition Header Field", RFC 2183,August 1997. 1338 Shapira Informational - Expires May 2003 Page [27] 1339 Simple Notification and Alarm Protocol (SNAP) November 2002 1341 [RFC-2184] Freed, N., and Moore, K., "MIME Parameter Value and 1342 Encoded Word Extensions: Character Sets, Languages, and 1343 Continuations", RFC 2184, August 1997. 1345 [RFC-IMAP4] Crispin, M., "Internet Message Access Protocol - Version 1346 4rev1", RFC 2060, University of Washington, December 1996. 1348 [HINT] E. Burger, E. Candell, C. Eliot, G. Klyne, "Message Context 1349 for Internet Mail", draft - draft-ietf-vpim-hint-08.txt 1351 [HEADER] Jacob Palme, "Common Internet Message Header Fields", 1352 draft-palme-mailext-headers-08.txt 1354 [RFC-DSN] K. Moore, G. Vaudreuil, "An Extensible Message Format for 1355 Delivery Status Notifications", RFC 1894, January 1996 1357 [RFC-MDN] R. Fajman, "An Extensible Message Format for Message 1358 Disposition Notifications", RFC 2298, March 1998 1360 9. Acknowledgements 1362 The authors wish to acknowledge the following people who helped in 1363 the development of this draft: The participants in SNAP mailing list 1364 who contributed to SNAP formation, the VPIM working group for both 1365 hosting a discussion on SNAP and providing very important insights. 1366 In particular Greg Vaudreuil from Lucent Technologies, who 1367 contributed some very useful advice and Glenn Parsons, VPIM WG Chair 1368 who facilitated and contributed to this activity. 1370 The authors also wish to acknowledge the following colleagues 1371 from Comverse Technology for advising and reviewing the draft: 1372 Erez Reinshmidt, Ari Erev, John Neystadt, Olga Elin, Arie Levy, 1373 Asaf Barak, Eli Jacobi, Dmitry Rubinstein and Gev Decktor. 1375 10. Authors' Addresses 1377 Noam Shapira 1378 Comverse Technology 1379 29 Habarzel st. 1380 Tel-Aviv 1381 Israel 1383 Phone: +972-3-7663605 1384 Fax: +972-3-6454866 1385 EMail: noam.shapira@comverse.com 1387 Shapira Informational - Expires May 2003 Page [28] 1388 Simple Notification and Alarm Protocol (SNAP) November 2002 1390 Appendix A. Historical Overview of Notification Issue. 1392 During previous years and even now there were a number of proposals 1393 in IETF regarding Notification. 1395 It is possible to retrieve the documentation information from the 1396 following documents: 1398 draft-roach-sip-subscribe-notify 1399 draft-ietf-sip-events 1400 draft-martin-sieve-notify 1401 draft-mahy-sip-message-waiting 1402 draft-khare-notification (ISENS at 1998) 1403 draft-nerenberg-sin-framework 1404 draft-nerenberg-sin-imap 1406 All these documents were considered in the drafting of this proposal. 1408 Appendix B. List of changes from ..-01 version 1410 Following are the changes: 1412 - Added Notification Protocol High level requirements. 1413 - Better define the SNAP scope and the document structure. 1414 - Bind the SNAP with HTTP. 1415 - Chosen a new format for the SNAP - 2822 like. 1416 - Added Security and IANA considerations. 1417 - Extended the terminology section 1418 - Make sure that time attributes are compatible to [RFC-2822]. 1419 - Changed MessageType to Message-Context - compatible to [HINT]. 1420 - Changed MsgPriority to Msg-Importance 1422 Appendix C. List of changes from ..-02 version 1424 Following are the changes: 1426 - In 2.2.4 Added retry as a result of no response. 1427 - Counters: Better define the categorizing and add the ability 1428 to add new counters. 1429 - Added that SNAP is case insensitive. 1430 - Added dash to names (e.g. RequestType to Request-Type). 1431 - Removed GMT requirement from Message-Send-Time 1432 - Removed MIXER reference and changed to 1433 draft-palme-mailext-headers-06.txt. 1434 - In 2.2.1 Request Order: Changed from MUST to SHOULD. 1436 Shapira Informational - Expires May 2003 Page [29] 1437 Simple Notification and Alarm Protocol (SNAP) November 2002 1439 Appendix D. List of changes from ..-03 version 1441 - Removed Attachment-Names and nAttachments attributes 1442 - Added that the Notification Service will receive SNAP in a 1443 pre-defined port (2.1.8). 1444 - Added Total-Message, Total-New-Message and 1445 Total-New-Urgent-Message (3.6.10-12). 1446 - Added Mailbox-Name (3.4.3) in MailboxGroup. 1448 Appendix D. List of changes from ..-03 version 1450 - Fixed response syntax. 1451 - Fixed response example 1452 - Updated references to internet drafts. 1454 Shapira Informational - Expires May 2003 Page [30]