idnits 2.17.1 draft-ietf-sipping-mwi-04.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (Dec 2003) is 7430 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: 'Mahy' on line 705 == Unused Reference: '8' is defined on line 899, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 902, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 906, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (ref. '2') (Obsoleted by RFC 6665) == Outdated reference: A later version (-10) exists of draft-ietf-sip-callerprefs-08 == Outdated reference: A later version (-03) exists of draft-ietf-sip-callee-caps-00 ** Obsolete normative reference: RFC 2234 (ref. '6') (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2421 (ref. '8') (Obsoleted by RFC 3801) -- Obsolete informational reference (is this intentional?): RFC 2822 (ref. '10') (Obsoleted by RFC 5322) == Outdated reference: A later version (-07) exists of draft-ietf-simple-event-list-04 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING WG R. Mahy 2 Internet-Draft Cisco Systems, Inc. 3 Expires: May 31, 2004 Dec 2003 5 A Message Summary and Message Waiting Indication Event Package for 6 the Session Initiation Protocol (SIP) 7 draft-ietf-sipping-mwi-04.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on May 31, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document describes a SIP event package to carry message waiting 38 status and message summaries from a messaging system to an interested 39 User Agent. 41 Table of Contents 43 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. Background and Appropriateness . . . . . . . . . . . . . . . 3 45 3. Event Package Formal Definition . . . . . . . . . . . . . . 4 46 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . . 4 47 3.2 Event Package Parameters . . . . . . . . . . . . . . . . . . 4 48 3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . 4 49 3.4 Subscription Duration . . . . . . . . . . . . . . . . . . . 4 50 3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 4 51 3.6 Subscriber generation of SUBSCRIBE requests . . . . . . . . 6 52 3.7 Notifier processing of SUBSCRIBE requests . . . . . . . . . 6 53 3.8 Notifier generation of NOTIFY requests . . . . . . . . . . . 7 54 3.9 Subscriber processing of NOTIFY requests . . . . . . . . . . 7 55 3.10 Handling of Forked Requests . . . . . . . . . . . . . . . . 7 56 3.11 Rate of notifications . . . . . . . . . . . . . . . . . . . 7 57 3.12 State Agents and Lists . . . . . . . . . . . . . . . . . . . 8 58 3.13 Behavior of a Proxy Server . . . . . . . . . . . . . . . . . 8 59 4. Examples of Usage . . . . . . . . . . . . . . . . . . . . . 8 60 4.1 Example Message Flow . . . . . . . . . . . . . . . . . . . . 8 61 4.2 Example Usage with Callee Capabilities and Caller 62 Preferences . . . . . . . . . . . . . . . . . . . . . . . . 14 63 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 14 64 5.1 New event-package definition . . . . . . . . . . . . . . . . 14 65 5.2 Body Format Syntax . . . . . . . . . . . . . . . . . . . . . 15 66 6. Security Considerations . . . . . . . . . . . . . . . . . . 15 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 68 7.1 SIP Event Package Registration for message-summary . . . . . 16 69 7.2 MIME Registration for application/simple-message-summary . . 16 70 8. Revision history . . . . . . . . . . . . . . . . . . . . . . 17 71 8.1 Changes from draft-ietf-sipping-mwi-03 . . . . . . . . . . . 17 72 8.2 Changes from draft-ietf-sipping-mwi-01 and -02 . . . . . . . 17 73 8.3 Changes from draft-ietf-sipping-mwi-00 . . . . . . . . . . . 17 74 8.4 Changes from draft-mahy-sipping-mwi-00 . . . . . . . . . . . 18 75 8.5 Changes from draft-mahy-sip-mwi-01 . . . . . . . . . . . . . 18 76 8.6 Changes from draft-mahy-sip-mwi-00 . . . . . . . . . . . . . 18 77 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 78 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 19 79 Normative References . . . . . . . . . . . . . . . . . . . . 19 80 Informational References . . . . . . . . . . . . . . . . . . 20 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . 20 82 Intellectual Property and Copyright Statements . . . . . . . 21 84 1. Conventions 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC-2119 [3]. 90 2. Background and Appropriateness 92 Messaging Waiting Indication is a common feature of telephone 93 networks. It typically involves an audible or visible indication 94 that messages are waiting, such as playing a special dial tone (which 95 in telephone networks is called message-waiting dial tone), lighting 96 a light or indicator on the phone, displaying icons or text, or some 97 combination. 99 Message-waiting dial tone is similar to but distinct from stutter 100 dial tone. Both are defined in GR-506 [12]. 102 The methods in the SIP [1] base specification were only designed to 103 solve the problem of session initiation for multimedia sessions, and 104 rendezvous. Since Message Waiting Indication is really status 105 information orthogonal to a session, it was not clear how an IP 106 telephone acting as a SIP User Agent would implement comparable 107 functionality. Members of the telephony community viewed this as a 108 shortcoming of SIP. 110 Users want the useful parts of the functionality they have using 111 traditional analog, mobile, and PBX telephones. It is also desirable 112 to provide comparable functionality in a flexible way that allows for 113 more customization and new features. SIP Specific Event Notification 114 (RFC 3265 -- SIP Events) [2] is an appropriate mechanism to use in 115 this environment, as it preserves the user mobility and rendezvous 116 features which SIP provides. 118 Using SIP-Specific Event Notification, A Subscriber User Agent 119 (typically an IP phone or SIP software User Agent) subscribes to the 120 status of their messages. A SIP User Agent acting on behalf of the 121 user's messaging system then notifies the Subscriber whenever the 122 messaging account's messages have changed. (This Notifier could be 123 composed with a User Agent that provides a real-time media interface 124 to send or receive messages, or it could be a standalone entitiy.) 125 The Notifier sends a message summary in the body of a NOTIFY, encoded 126 in a new MIME type defined later in this document. A User Agent can 127 also explicitly fetch the current status. 129 A SIP User Agent MAY subscribe to multiple accounts (distinguished by 130 the Request URI). Multiple SIP User Agents MAY subscribe to the same 131 account. 133 Before any subscriptions or notifications are sent, each interested 134 User Agent must be made aware of its messaging notifier(s). This MAY 135 be manually configured on interested User Agents, manually configured 136 on an appropriate SIP Proxy, or dynamically discovered based on 137 requested caller preferences [4] and registered callee capabilities 138 [5]. (For more information on usage with callee capabilities, see 139 Section 4.2) 141 3. Event Package Formal Definition 143 3.1 Event Package Name 145 This document defines a SIP Event Package as defined in RFC 3265 [2]. 146 The event-package token name for this package is: 148 "message-summary" 150 3.2 Event Package Parameters 152 This package does not define any event package parameters. 154 3.3 SUBSCRIBE Bodies 156 This package does not define any SUBSCRIBE bodies. 158 3.4 Subscription Duration 160 Subscriptions to this event package MAY range from minutes to weeks. 161 Subscriptions in hours or days are more typical and are RECOMMENDED. 162 The default subscription duration for this event package is one hour. 164 3.5 NOTIFY Bodies 166 A simple text-based format is proposed to prevent an undue burden on 167 low-end user agents, for example, inexpensive IP phones with no 168 display. Although this format is text-based, it is intended for 169 machine consumption only. 171 A future extension MAY define other NOTIFY bodies. If no "Accept" 172 header is present in the SUBSCRIBE, the body type defined in this 173 document MUST be assumed. 175 The format specified in this proposal attempts to separate orthogonal 176 attributes of messages as much as possible. Messages are separated 177 by message-context-class (for example: voice-message, fax-message, 178 pager-message, multimedia-message, text-message, and none); by 179 message status (new and old); and by urgent and non-urgent type. 181 The text format begins with a simple status line, and optionally a 182 summary line per message-context-class. Message-context-classes are 183 defined in [7]. For each message-context-class, the total number of 184 new and old messages is reported in the new and old fields. 186 In some cases, detailed message summaries are not available. The 187 status line allows messaging systems or messaging gateways to provide 188 the traditional boolean message waiting notification. 190 Messages-Waiting: yes 192 If the Request-URI or To header in a message-summary subscription 193 corresponds to a group or collection of individual messaging 194 accounts, the notifier MUST specify to which account the 195 message-summary body corresponds. Note that the account URI MUST NOT 196 be delimited with angle brackets ("<" and ">"). 198 Message-Account: sip:alice@example.com 200 In the example that follows, more than boolean message summary 201 information is available to the User Agent. There are two new and 202 four old fax messages. 204 Fax-Message: 2/4 206 After the summary, the format can optionally list a summary count of 207 urgent messages. In the next example there are one new and three old 208 voice messages, none of the new messages are urgent, but one of the 209 old messages is. All counters have a maximum value of 4,294,967,295 210 ((2^32) - 1). Notifiers MUST NOT generate a request with a larger 211 value. Subscribers MUST treat a larger value as 2^32-1. 213 Voice-Message: 1/3 (0/1) 215 Optionally, after the summary counts, the messaging systems MAY 216 append RFC 2822 [10]-style message headers, which further describe 217 newly added messages. Message headers MUST NOT be included in an 218 initial NOTIFY, as new messages could be essentially unbounded in 219 size. Message headers included in subsequent notifications MUST only 220 correspond to messages added since the previous notification for that 221 subscription. A messaging system which includes message headers in a 222 NOTIFY, MUST provide an administrator configurable mechanism for 223 selecting which headers are sent. Likely headers for inclusion 224 include To, From, Date, Subject, and Message-ID. Note that the 225 formatting of these headers in this body is identical to that of SIP 226 extension-headers, not the (similar) format defined in RFC 2822. 228 Implementations which generate large notifications are reminded to 229 follow the message size restrictions for unreliable transports 230 articulated in Section 18.1.1 of SIP. 232 Mapping local message state to new/old message status and urgency is 233 an implementation issue of the messaging system. However, the 234 messaging notifier MUST NOT consider a message "old" merely because 235 it generated a notification, as this could prevent another 236 subscription from accurately receiving message-summary notifications. 237 Likewise, the messaging system MAY use any suitable algorithm to 238 determine that a message is "urgent". 240 Messaging systems MAY use any algorithm for determining the 241 approporiate message-context-class for a specific message. Systems 242 which use Internet Mail SHOULD use the contents of the 243 Message-Context header [7] (defined in RFC 3458) if present as a hint 244 to make a context determination. Note that a composed messaging 245 system does not need to support a given context in order to generate 246 notifications identified with that context. 248 3.6 Subscriber generation of SUBSCRIBE requests 250 Subscriber User Agents will typically SUBSCRIBE to message summary 251 information for a period of hours or days, and automatically attempt 252 to re-SUBSCRIBE well before the subscription is completely expired. 253 If re-subscription fails, the Subscriber SHOULD periodically retry 254 again until a subscription is successful, taking care to backoff to 255 avoid network congestion. If a subscription has expired, new 256 re-subscriptions MUST use a new Call-ID. 258 The Subscriber SHOULD SUBSCRIBE to that user's message summaries 259 whenever a new user becomes associated with the device (a new login). 260 The Subscriber MAY also explicitly fetch the current status at any 261 time. The subscriber SHOULD renew its subscription immediately after 262 a reboot, or when the subscriber's network connectivity has just been 263 re-established. 265 The Subscriber MUST be prepared to receive and process a NOTIFY with 266 new state immediately after sending a new SUBSCRIBE, a SUBSCRIBE 267 renewal, an unsubscribe, or a fetch; or at any time during the 268 subscription. 270 When a user de-registers from a device (logoff, power down of a 271 mobile device, etc.), subscribers SHOULD unsubscribe by sending a 272 SUBSCRIBE message with an Expires header of zero. 274 3.7 Notifier processing of SUBSCRIBE requests 276 When a SIP Messaging System receives SUBSCRIBE messages with the 277 message-summary event-type, it SHOULD authenticate the subscription 278 request. If authentication is successful, the Notifier MAY limit the 279 duration of the subscription to an administrator defined amount of 280 time as described in SIP Events. 282 3.8 Notifier generation of NOTIFY requests 284 Immediately after a subscription is accepted, the Notifier MUST send 285 a NOTIFY with the current message summary information. This allows 286 the Subscriber to resynchronize its state. This initial 287 synchronization NOTIFY MUST NOT include the optional RFC 2822 288 [9]-style message headers. 290 When the status of the messages changes sufficiently for a messaging 291 account to change the number of new or old messages, the Notifier 292 SHOULD send a NOTIFY message to all active subscribers to that 293 account. NOTIFY messages sent to subscribers of a group or alias, 294 MUST contain the message account name in the notification body. 296 A Messaging System MAY send a NOTIFY with an "Expires" header of "0" 297 and a "Subscription-State" header of "terminated" before a graceful 298 shutdown. 300 3.9 Subscriber processing of NOTIFY requests 302 Upon receipt of a valid NOTIFY request, the subscriber SHOULD 303 immediately render the message status and summary information to the 304 end user in an implementation specific way. 306 The Subscriber MUST be prepared to receive NOTIFYs from different 307 Contacts corresponding to the same SUBSCRIBE. (the SUBSCRIBE may 308 have been forked). 310 3.10 Handling of Forked Requests 312 Forked requests are allowed for this event type and may install 313 multiple subscriptions. The Subscriber MAY render multiple summaries 314 which correspond to the same account directly to the user, or MAY 315 merge them as described below. 317 If any of the "Messages-Waiting" status lines report "yes", then the 318 merged state is "yes"; otherwise the merged state is "no". 320 The Subscriber MAY merge summary lines in an implementation-specific 321 way if all notifications contain at least one msg-summary line. 323 3.11 Rate of notifications 324 A Notifier MAY choose to hold NOTIFY requests in "quarantine" for a 325 short administrator-defined period (seconds or minutes) when the 326 message status is changing rapidly. Requests in the quarantine which 327 become invalid are replaced by newer notifications, thus reducing the 328 total volume of notifications. This behavior is encouraged for 329 implementations with heavy interactive use. Note that timely 330 notification which results in a change of overall state (messages 331 waiting or not), and notification of newly added messages is probably 332 more significant to the end user than a notification of newly deleted 333 messages which do not affect the overall message waiting state (e.g. 334 there are still new messages). 336 Notifiers SHOULD NOT generate NOTIFY requests more frequently than 337 once per second. 339 3.12 State Agents and Lists 341 A Subscriber MAY use an "alias" or "group" in the Request-URI of a 342 subscription if that name is significant to the messaging system. 343 Implementers MAY create a service which consolidates and summarizes 344 NOTIFYs from many Contacts. This document does not preclude 345 implementations from building state agents which support this event 346 package. One way to implement such a service is with the event list 347 extension [11]. 349 3.13 Behavior of a Proxy Server 351 There are no additional requirements on a SIP Proxy, other than to 352 transparently forward the SUBSCRIBE and NOTIFY methods as required in 353 SIP. However, Proxies SHOULD allow non-SIP URLs. Proxies and 354 Redirect servers SHOULD be able to direct the SUBSCRIBE request to an 355 appropriate messaging notifier User Agent. 357 4. Examples of Usage 359 4.1 Example Message Flow 361 The examples shown below are for informational purposes only. For a 362 normative description of the event package, please see sections 3 and 363 5 of this document. 365 In the example call flow below, Alice's IP phone subscribes to the 366 status of Alice's messages. Via headers are omitted for clarity. 368 Subscriber Notifier 369 | | 370 | A1: SUBSCRIBE (new) | 371 |---------------------->| 372 | A2: 200 OK | 373 |<----------------------| 374 | | 375 | A3: NOTIFY (sync) | 376 |<----------------------| 377 | A4: 200 OK | 378 |---------------------->| 379 | | 380 | | 381 | A5: NOTIFY (change) | 382 |<----------------------| 383 | A6: 200 OK | 384 |---------------------->| 385 | | 386 | | 387 | A7: (re)SUBSCRIBE | 388 |---------------------->| 389 | A8: 200 OK | 390 |<----------------------| 391 | | 392 | A9: NOTIFY (sync) | 393 |<----------------------| 394 | A10: 200 OK | 395 |---------------------->| 396 | | 397 | | 398 | A11: (un)SUBSCRIBE | 399 |---------------------->| 400 | A12: 200 OK | 401 |<----------------------| 402 | | 403 | A13: NOTIFY (sync) | 404 |<----------------------| 405 | A14: 200 OK | 406 |---------------------->| 408 A1: Subscriber (Alice's phone) -> 409 Notifier (Alice's voicemail gateway) 410 Subscribe to Alice's message summary status for 1 day. 412 SUBSCRIBE sip:alice@vmail.example.com SIP/2.0 413 To: 414 From: ;tag=78923 415 Date: Mon, 10 Jul 2000 03:55:06 GMT 416 Call-Id: 1349882@alice-phone.example.com 417 CSeq: 4 SUBSCRIBE 418 Contact: 419 Event: message-summary 420 Expires: 86400 421 Accept: application/simple-message-summary 422 Content-Length: 0 424 A2: Notifier -> Subscriber 426 SIP/2.0 200 OK 427 To: ;tag=4442 428 From: ;tag=78923 429 Date: Mon, 10 Jul 2000 03:55:07 GMT 430 Call-Id: 1349882@alice-phone.example.com 431 CSeq: 4 SUBSCRIBE 432 Expires: 86400 433 Content-Length: 0 435 A3: Notifier -> Subscriber 436 (immediate synchronization of current state: 437 2 new and 8 old [2 urgent] messages) 439 NOTIFY sip:alice@alice-phone.example.com SIP/2.0 440 To: ;tag=78923 441 From: ;tag=4442 442 Date: Mon, 10 Jul 2000 03:55:07 GMT 443 Call-Id: 1349882@alice-phone.example.com 444 CSeq: 20 NOTIFY 445 Contact: 446 Event: message-summary 447 Subscription-State: active 448 Content-Type: application/simple-message-summary 449 Content-Length: 99 451 Messages-Waiting: yes 452 Message-Account: sip:alice@vmail.example.com 453 Voice-Message: 2/8 (0/2) 455 A4: Subscriber -> Notifier 457 SIP/2.0 200 OK 458 To: ;tag=78923 459 From: ;tag=4442 460 Date: Mon, 10 Jul 2000 03:55:08 GMT 461 Call-Id: 1349882@alice-phone.example.com 462 CSeq: 20 NOTIFY 463 Content-Length: 0 465 A5: Notifier -> Subscriber 466 This is a notification of new messages. 468 Some headers from each of the new messages are appended. 470 NOTIFY sip:alice@alice-phone.example.com SIP/2.0 471 To: ;tag=78923 472 From: ;tag=4442 473 Date: Mon, 10 Jul 2000 04:28:53 GMT 474 Contact: 475 Call-ID: 1349882@alice-phone.example.com 476 CSeq: 31 NOTIFY 477 Event: message-summary 478 Subscription-State: active 479 Content-Type: application/simple-message-summary 480 Content-Length: 503 482 Messages-Waiting: yes 483 Message-Account: sip:alice@vmail.example.com 484 Voice-Message: 4/8 (1/2) 486 To: 487 From: 488 Subject: carpool tomorrow? 489 Date: Sun, 09 Jul 2000 21:23:01 -0700 490 Priority: normal 491 Message-ID: 13784434989@vmail.example.com 493 To: 494 From: 495 Subject: HELP! at home ill, present for me please 496 Date: Sun, 09 Jul 2000 21:25:12 -0700 497 Priority: urgent 498 Message-ID: 13684434990@vmail.example.com 500 A6: Subscriber -> Notifier 502 SIP/2.0 200 OK 503 To: ;tag=78923 504 From: ;tag=4442 505 Date: Mon, 10 Jul 2000 04:28:53 GMT 506 Call-ID: 1349882@alice-phone.example.com 507 CSeq: 31 NOTIFY 508 Content-Length: 0 510 A7: Subscriber -> Notifier 511 Refresh subscription. 513 SUBSCRIBE sip:alice@vmail.example.com SIP/2.0 514 To: ;tag=4442 515 From: ;tag=78923 516 Date: Mon, 10 Jul 2000 15:55:06 GMT 517 Call-Id: 1349882@alice-phone.example.com 518 CSeq: 8 SUBSCRIBE 519 Contact: 520 Event: message-summary 521 Expires: 86400 522 Accept: application/simple-message-summary 523 Content-Length: 0 525 A8: Notifier -> Subscriber 527 SIP/2.0 200 OK 528 To: ;tag=4442 529 From: ;tag=78923 530 Date: Mon, 10 Jul 2000 15:55:07 GMT 531 Call-Id: 1349882@alice-phone.example.com 532 CSeq: 8 SUBSCRIBE 533 Contact: 534 Expires: 86400 535 Content-Length: 0 537 A9: Notifier -> Subscriber 538 (immediate synchronization of current state) 540 NOTIFY sip:alice@alice-phone.example.com SIP/2.0 541 To: ;tag=78923 542 From: ;tag=4442 543 Date: Mon, 10 Jul 2000 15:55:07 GMT 544 Call-Id: 1349882@alice-phone.example.com 545 CSeq: 47 NOTIFY 546 Contact: 547 Event: message-summary 548 Subscription-State: active 549 Content-Type: application/simple-message-summary 550 Content-Length: 99 552 Messages-Waiting: yes 553 Message-Account: sip:alice@vmail.example.com 554 Voice-Message: 4/8 (1/2) 556 A10: Subscriber -> Notifier 558 SIP/2.0 200 OK 559 To: ;tag=78923 560 From: ;tag=4442 561 Date: Mon, 10 Jul 2000 15:55:08 GMT 562 Call-Id: 1349882@alice-phone.example.com 563 CSeq: 47 NOTIFY 564 Contact: 566 A11: Subscriber -> Notifier 567 Un-subscribe after "alice" logs out. 569 SUBSCRIBE sip:alice@vmail.example.com SIP/2.0 570 To: ;tag=4442 571 From: ;tag=78923 572 Date: Mon, 10 Jul 2000 19:35:06 GMT 573 Call-Id: 1349882@alice-phone.example.com 574 CSeq: 17 SUBSCRIBE 575 Contact: 576 Event: message-summary 577 Expires: 0 578 Accept: application/simple-message-summary 579 Content-Length: 0 581 A12: Notifier -> Subscriber 583 SIP/2.0 200 OK 584 To: ;tag=4442 585 From: ;tag=78923 586 Date: Mon, 10 Jul 2000 19:35:07 GMT 587 Call-Id: 1349882@alice-phone.example.com 588 CSeq: 17 SUBSCRIBE 589 Contact: 590 Expires: 0 591 Content-Length: 0 593 A13: Notifier -> Subscriber 594 (immediate synchronization of current state, 595 which the subscriber can now ignore) 597 NOTIFY sip:alice@alice-phone.example.com SIP/2.0 598 To: ;tag=78923 599 From: ;tag=4442 600 Date: Mon, 10 Jul 2000 19:35:07 GMT 601 Call-Id: 1349882@alice-phone.example.com 602 CSeq: 56 NOTIFY 603 Contact: 604 Event: message-summary 605 Subscription-State: terminated;reason=timeout 606 Content-Type: application/simple-message-summary 607 Content-Length: 99 609 Messages-Waiting: yes 610 Message-Account: sip:alice@vmail.example.com 611 Voice-Message: 4/8 (1/2) 613 A14: Subscriber -> Notifier 615 SIP/2.0 200 OK 616 To: ;tag=78923 617 From: ;tag=4442 618 Date: Mon, 10 Jul 2000 19:35:08 GMT 619 Call-Id: 1349882@alice-phone.example.com 620 CSeq: 56 NOTIFY 621 Event: message-summary 622 Content-Length: 0 624 4.2 Example Usage with Callee Capabilities and Caller Preferences 626 The use of callee capabilities is optional but encouraged. If callee 627 capabilities is used, a messaging notifier MAY REGISTER a Contact 628 with an appropriate methods and events tag as shown in the example 629 below. To further distinguish itself, the messaging notifier MAY 630 also REGISTER as a Contact with the actor="msg-taker" tag. An 631 example of this kind of registration follows below. 633 REGISTER sip:sip3-sj.example.com SIP/2.0 634 To: 635 From: ;tag=4442 636 ... 637 Contact: 638 ;actor="msg-taker";methods="SUBSCRIBE" 639 ;automata;events="message-summary" 641 The following SUBSCRIBE message would find the Contact which 642 registered in the example above. 644 SUSBCRIBE sip:alice@example.com SIP/2.0 645 ... 646 Accept: application/simple-message-summary 647 Event: message-summary 648 Accept-Contact: *;automata;actor="msg-taker" 650 5. Formal Syntax 652 The following syntax specification uses the augmented Backus-Naur 653 Form (BNF) as described in RFC-2234 [6]. 655 5.1 New event-package definition 656 This document defines a new event-package with the package name: 658 message-summary 660 5.2 Body Format Syntax 662 The formal syntax for the application/simple-message-summary MIME 663 type is described below: 665 messsage-summary = msg-status-line CRLF 666 [msg-account CRLF] 667 [*(msg-summary-line CRLF)] 668 [ *opt-msg-headers ] 670 msg-status-line = "Messages-Waiting" HCOLON msg-status 671 msg-status = "yes" / "no" 672 msg-account = "Message-Account" HCOLON Account-URI 673 Account-URI = SIP-URI / SIPS-URI / absoluteURI 675 msg-summary-line = message-context-class HCOLON newmsgs SLASH oldmsgs 676 [ LPAREN new-urgentmsgs SLASH old-urgentmsgs RPAREN ] 678 opt-msg-headers = CRLF 1*(extension-header CRLF) 680 newmsgs = msgcount 681 oldmsgs = msgcount 682 new-urgentmsgs = msgcount 683 old-urgentmsgs = msgcount 684 msgcount = 1*DIGIT ; MUST NOT exceed 2^32-1 686 6. Security Considerations 688 Message summaries and optional message bodies contain information 689 which is typically very privacy sensitive. At minimum, subscriptions 690 to this event package SHOULD be authenticated and properly 691 authorized. Furthermore, notifications SHOULD be encrypted and 692 integrity protected using either end-to-end mechanisms, or the 693 hop-by-hop protection afforded messages sent to SIPS URIs. 695 Additional and privacy security considerations are discussed in 696 detail in SIP [1] and SIP Events [2]. 698 7. IANA Considerations 699 7.1 SIP Event Package Registration for message-summary 701 Package name: message-summary 703 Type: package 705 Contact: [Mahy] 707 Published Specification: This document. 709 7.2 MIME Registration for application/simple-message-summary 711 MIME media type name: application 713 MIME subtype name: simple-message-summary 715 Required parameters: none. 717 Optional parameters: none. 719 Encoding considerations: This MIME type was designed for 720 use with protocols which can carry binary-encoded data. 721 Although the format of this MIME type is similar to RFC2822, 722 it is not identical. (Specifically, line folding rules are 723 SIP-specific and included URIs can contain non-ASCII 724 characters.) Protocols which do not carry binary data 725 (which have line length or character-set restrictions 726 for example) MUST use a reversible transfer encoding 727 (such as base64) to carry this MIME type. 729 Security considerations: See the "Security Considerations" 730 section in this document. 732 Interoperability considerations: none 734 Published specification: This document. 736 Applications which use this media: The simple-message-summary 737 application subtype supports the exchange of message waiting and 738 message summary information in SIP networks. 740 Additional information: 742 1. Magic number(s): N/A 744 2. File extension(s): N/A 745 3. Macintosh file type code: N/A 747 8. Revision history 749 ** Note to the RFC editor: please remove this entire section upon 750 publication. ** 752 8.1 Changes from draft-ietf-sipping-mwi-03 754 1. Updated MIME type registration to permit transfer encoding using 755 any binary-clean encoding. 757 2. Changed caller preferences and callee capabilities usage to be 758 consistent with change from msg-server="true" to 759 actor="msg-taker". 761 8.2 Changes from draft-ietf-sipping-mwi-01 and -02 763 1. Updated the caller-preference section (now the callee 764 capabilities section) to reflect the split of these drafts and 765 the new tag ;msgserver="true". 767 2. Added some text in the overview to further clarify how message 768 notifiers can be composed/decomposed with media processing. 770 3. Add a pointer to the event-list extension. 772 8.3 Changes from draft-ietf-sipping-mwi-00 774 1. Replaced the "media types" concept with message contexts. This is 775 a better semantic match than what was in the draft before, and 776 also controls extensibility and change control in a single 777 document. The list of valid message-context-classes are 778 voice-message, fax-message, pager-message, multimedia-message, 779 text-message, and none. 781 2. Completely updated the syntax to follow that of SIP instead of 782 the previously more restrictive (and somewhat arbitrary) syntax. 783 The SIP syntax adds line folding, for example. The optional 784 message-headers borrow the "extension-header" syntax and explicit 785 whitespace separators defined in SIP (ex: HCOLON, SLASH). 787 3. Added a Message-Account field in the body format to provide the 788 specific account name which corresponds to the notification when 789 forking or state agents are used with group aliases (or 790 collections). 792 4. Changed caller preferences example to exclude methods="SUBSCRIBE" 793 in the SUBSCRIBE request (removed redundant information). 795 5. Changed examples to be consistent with IESG recommendations 797 8.4 Changes from draft-mahy-sipping-mwi-00 799 1. Updated references and split into normative and informational 801 2. Removed normative behavior now specified in Events 803 3. Updated to address the event package sections now specified in 804 Events. 806 4. Added the Subscription-State header field to the examples and 807 removed the Event header field from responses. 809 5. Removed redundant BNF 811 6. Simplified text on how to choose the media type. For Internet 812 Mail, this now references the Message-Context header. 814 8.5 Changes from draft-mahy-sip-mwi-01 816 1. This document is now formatted as a SIP Event Package as defined 817 in Section 4 of RFC 3265 (SIP Events) [2]. 819 2. The event-package name is now "message-summary", to allow for 820 other bodies to extend the package. 822 3. The "urgent" token was missing from the BNF. 824 8.6 Changes from draft-mahy-sip-mwi-00 826 This draft greatly simplifies and shortens the -00 version. 828 1. The generic behavior of SUBSCRIBE/NOTIFY is now greatly clarified 829 in SIP Events [2] and made consistent with PINT and SIP for 830 presence. This message waiting draft is now consistent with SIP 831 Events. 833 2. The XML format has been removed due to lack of immediate 834 interest. At a future date, similar functionality may be added 835 as another body definition with an appropriate MIME type. 837 3. An IANA Considerations section was added to register the new 838 "application/simple-message-summary" MIME type and the 839 "simple-message-summary" SIP event package. 841 4. The "flag-list" was removed due to lack of interest and to 842 encourage simplicity. 844 5. Due to synchronization issues, and the recommendation of the VPIM 845 Working Group, support for message count "deltas" was removed. 847 6. The Messages-Waiting line in the body is now mandatory. 849 7. This version of the draft clarifies the role of caller 850 preferences as optional but encouraged. 852 8. A set of SMTP-like headers from the triggering messages may now 853 optionally follow the message summaries, provided that the 854 resulting NOTIFY on UDP fits in a single datagram. 856 9. Contributors 858 Ilya Slain came up with the initial format of the text body contained 859 in this document. He was previously listed as a co-author, however, 860 he is no longer reachable. 862 10. Acknowledgments 864 Thanks to Dan Wing, Dave Oran, Bill Foster, Steve Levy, Denise 865 Caballero-McCann, Jeff Michel, Priti Patil, Satyender Khatter, Bich 866 Nguyen, Manoj Bhatia, David Williams, and Bryan Byerly of Cisco; 867 Jonathan Rosenberg and Adam Roach of Dynamicsoft; Eric Burger of 868 Snowshore; Nir Chen of iComverse, and Eric Tremblay of Mediatrix. 870 Normative References 872 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 873 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 874 Session Initiation Protocol", RFC 3261, June 2002. 876 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 877 Notification", RFC 3265, June 2002. 879 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 880 Levels", BCP 14, RFC 2119, March 1997. 882 [4] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller 883 Preferences and Callee Capabilities for the Session Initiation 884 Protocol (SIP)", draft-ietf-sip-callerprefs-08 (work in 885 progress), March 2003. 887 [5] Rosenberg, J., "Indicating User Agent Capabilities in the 888 Session Initiation Protocol (SIP)", 889 draft-ietf-sip-callee-caps-00 (work in progress), June 2003. 891 [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax 892 Specifications: ABNF", RFC 2234, November 1997. 894 [7] Burger, E., Candell, E., Eliot, C. and G. Klyne, "Message 895 Context for Internet Mail", RFC 3458, January 2003. 897 Informational References 899 [8] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail 900 - version 2", RFC 2421, September 1998. 902 [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 903 Extensions (MIME) Part Two: Media Types", RFC 2046, November 904 1996. 906 [10] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 908 [11] Rosenberg, J., Roach, A. and B. Campbell, "A Session Initiation 909 Protocol (SIP) Event Notification Extension for Resource 910 Lists", draft-ietf-simple-event-list-04 (work in progress), 911 June 2003. 913 [12] Telcordia, "GR-506: Signaling for Analog Interfaces, Issue 1, 914 Revision 1", Nov 1996. 916 Author's Address 918 Rohan Mahy 919 Cisco Systems, Inc. 920 101 Cooper Street 921 Santa Cruz, CA 95060 922 USA 924 EMail: rohan@cisco.com 926 Intellectual Property Statement 928 The IETF takes no position regarding the validity or scope of any 929 intellectual property or other rights that might be claimed to 930 pertain to the implementation or use of the technology described in 931 this document or the extent to which any license under such rights 932 might or might not be available; neither does it represent that it 933 has made any effort to identify any such rights. Information on the 934 IETF's procedures with respect to rights in standards-track and 935 standards-related documentation can be found in BCP-11. Copies of 936 claims of rights made available for publication and any assurances of 937 licenses to be made available, or the result of an attempt made to 938 obtain a general license or permission for the use of such 939 proprietary rights by implementors or users of this specification can 940 be obtained from the IETF Secretariat. 942 The IETF invites any interested party to bring to its attention any 943 copyrights, patents or patent applications, or other proprietary 944 rights which may cover technology that may be required to practice 945 this standard. Please address the information to the IETF Executive 946 Director. 948 Full Copyright Statement 950 Copyright (C) The Internet Society (2003). All Rights Reserved. 952 This document and translations of it may be copied and furnished to 953 others, and derivative works that comment on or otherwise explain it 954 or assist in its implementation may be prepared, copied, published 955 and distributed, in whole or in part, without restriction of any 956 kind, provided that the above copyright notice and this paragraph are 957 included on all such copies and derivative works. However, this 958 document itself may not be modified in any way, such as by removing 959 the copyright notice or references to the Internet Society or other 960 Internet organizations, except as needed for the purpose of 961 developing Internet standards in which case the procedures for 962 copyrights defined in the Internet Standards process must be 963 followed, or as required to translate it into languages other than 964 English. 966 The limited permissions granted above are perpetual and will not be 967 revoked by the Internet Society or its successors or assignees. 969 This document and the information contained herein is provided on an 970 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 971 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 972 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 973 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 974 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 976 Acknowledgement 978 Funding for the RFC Editor function is currently provided by the 979 Internet Society.