idnits 2.17.1 draft-ietf-sipping-mwi-00.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 13 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 (May 2002) is 8017 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 661 == Unused Reference: '7' is defined on line 828, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 831, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 835, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-sip-callerprefs-05 ** Obsolete normative reference: RFC 2234 (ref. '5') (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2421 (ref. '7') (Obsoleted by RFC 3801) -- Obsolete informational reference (is this intentional?): RFC 2822 (ref. '9') (Obsoleted by RFC 5322) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING WG R. Mahy 3 Internet-Draft Cisco Systems, Inc. 4 Expires: October 30, 2002 May 2002 6 A Message Summary and Message Waiting Indication Event Package for 7 the Session Initiation Protocol (SIP) 8 draft-ietf-sipping-mwi-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 30, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 39 This draft proposes a SIP event package to carry message waiting 40 status and message summaries from a messaging system to an interested 41 User Agent. 43 Table of Contents 45 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Background and Appropriateness . . . . . . . . . . . . . . . 3 47 3. Event Package Formal Definition . . . . . . . . . . . . . . 4 48 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . . 4 49 3.2 Event Package Parameters . . . . . . . . . . . . . . . . . . 4 50 3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . . 4 51 3.4 Subscription Duration . . . . . . . . . . . . . . . . . . . 4 52 3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.6 Subscriber generation of SUBSCRIBE requests . . . . . . . . 5 54 3.7 Notifier processing of SUBSCRIBE requests . . . . . . . . . 6 55 3.8 Notifier generation of NOTIFY requests . . . . . . . . . . . 6 56 3.9 Subscriber processing of NOTIFY requests . . . . . . . . . . 7 57 3.10 Handling of Forked Requests . . . . . . . . . . . . . . . . 7 58 3.11 Rate of notifications . . . . . . . . . . . . . . . . . . . 7 59 3.12 State Agents . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3.13 Behavior of a Proxy Server . . . . . . . . . . . . . . . . . 8 61 4. Examples of Usage . . . . . . . . . . . . . . . . . . . . . 8 62 4.1 Example Message Flow . . . . . . . . . . . . . . . . . . . . 8 63 4.2 Example Usage with Caller Preferences . . . . . . . . . . . 13 64 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 14 65 5.1 New event-package definition . . . . . . . . . . . . . . . . 14 66 5.2 Body Format Syntax . . . . . . . . . . . . . . . . . . . . . 14 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 68 6.1 SIP Event Package Registration for message-summary . . . . . 15 69 6.2 MIME Registration for application/simple-message-summary . . 16 70 7. Security Considerations . . . . . . . . . . . . . . . . . . 16 71 8. Revision history . . . . . . . . . . . . . . . . . . . . . . 16 72 8.1 Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 17 73 8.2 Changes from draft-mahy-sipping-mwi-00 . . . . . . . . . . . 17 74 8.3 Changes from draft-mahy-sip-mwi-01 . . . . . . . . . . . . . 17 75 8.4 Changes from draft-mahy-sip-mwi-00 . . . . . . . . . . . . . 18 76 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18 78 Normative References . . . . . . . . . . . . . . . . . . . . 19 79 Informational References . . . . . . . . . . . . . . . . . . 19 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 81 Full Copyright Statement . . . . . . . . . . . . . . . . . . 20 83 1. Conventions 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC-2119 [3]. 89 2. Background and Appropriateness 91 Messaging Waiting Indication is a common feature of telephone 92 networks. It typically involves playing a special dial tone (called 93 message-waiting dial tone), lighting a light or indicator on the 94 phone, or both. Message-waiting dial tone is similar but distinct 95 from stutter dial tone. Both are defined in GR-506 [10]. 97 The methods in the SIP [1] base specification were only designed to 98 solve the problem of session initiation for multimedia sessions, and 99 rendezvous. Since Message Waiting Indication is really status 100 information orthogonal to a session, it was not clear how an IP 101 telephone acting as a SIP User Agent would implement comparable 102 functionality. Members of the telephony community viewed this as a 103 shortcoming of SIP. 105 Users want the useful parts of the functionality they had using 106 traditional analog and PBX telephones. It is also desirable to 107 provide comparable functionality in a flexible way that allows for 108 more customization and new features. 110 SIP Specific Event Notification SIP Events [2] is an appropriate 111 mechanism to use in this environment, as it preserves the user 112 mobility and rendezvous features which SIP provides. 114 Using SIP-Specific Event Notification, A Subscriber User Agent 115 (typically an IP phone or SIP software User Agent) subscribes to the 116 status of their messages. A SIP User Agent acting on behalf of the 117 user's messaging system then notifies the Subscriber whenever the 118 account's messages have changed. The Notifier sends this message 119 summary information in the body of the NOTIFY, encoded in a new MIME 120 type defined later in this draft. A User Agent can also explicitly 121 fetch the current status. 123 A SIP User Agent MAY subscribe to multiple accounts (distinguished by 124 the Request URI). Multiple SIP User Agents MAY subscribe to the same 125 account. 127 Before any subscriptions or notifications are sent, each interested 128 User Agent must be made aware of its messaging server(s). This MAY 129 be manually configured on interested User Agents, manually configured 130 on an appropriate SIP Proxy, or dynamically discovered using caller 131 preferences [4]. (For more information on usage with caller 132 preferences, see Section 4.2) 134 3. Event Package Formal Definition 136 3.1 Event Package Name 138 This document defines a SIP Event Package as defined in SIP Events 139 [2]. The event-package token name for this package is: 141 "message-summary" 143 3.2 Event Package Parameters 145 This package does not define any event package parameters. 147 3.3 SUBSCRIBE Bodies 149 This package does not define any SUBSCRIBE bodies. 151 3.4 Subscription Duration 153 Subscriptions to this event package MAY range from minutes to weeks. 154 Subscriptions in hours or days are more typical and are RECOMMENDED. 156 3.5 NOTIFY Bodies 158 A simple text-based format is proposed to prevent an undue burden on 159 low-end user agents, for example, inexpensive IP phones with no 160 display. Although this format is text-based, it is intended for 161 machine consumption only. 163 A future extension MAY define other NOTIFY bodies. If no "Accept" 164 header is present in the SUBSCRIBE, the body type defined in this 165 document MUST be assumed. 167 The format specified in this proposal attempts to separate orthogonal 168 attributes of messages as much as possible. Messages are separated 169 by media type (audio, text, image, and video); by message status (new 170 and old); and by urgent and non-urgent type. 172 The text format begins with a simple status line, and optionally a 173 summary line per media type. Valid media types are Voicemail 174 (audio), Email (text), Fax (image), and Video (video). For each 175 media type the total number of new and old messages is reported in 176 the new and old fields. 178 In some cases, detailed message summaries are not available. The 179 status line allows messaging systems or messaging gateways to provide 180 the traditional boolean message waiting notification. 182 Messages-Waiting: yes 184 In the example that follows, more functionality is available to the 185 User Agent. There are one new and three old voice messages. 187 Voicemail: 1/3 189 After the summary, the format can optionally list a summary count of 190 urgent messages. Of the one new and three old voice messages, none 191 of the new messages are urgent, but one of the old messages is. All 192 counters have a maximum value of 4,294,967,295 ((2^32) - 1). 193 Notifiers MUST NOT generate a request with a larger value. 194 Subscribers MUST ignore a larger value. 196 Voicemail: 1/3 (0/1) 198 Optionally, after the summary counts, the messaging systems MAY 199 append RFC 2822 [9]-style message headers, which further describe 200 newly added messages. A messaging system which includes message 201 headers in a NOTIFY, MUST provide an administrator configurable 202 mechanism for selecting which headers are sent. Likely headers for 203 inclusion include To, From, Date, Subject, Message-ID, and Priority. 204 Note that the syntax for these headers is more restrictive than for 205 RFC 2822 and SIP. For example, line folding is prohibited. 207 Implementations which generate large notifications are reminded to 208 follow the message size restrictions for unreliable transports 209 articulated in Section 18.1.1 of SIP. 211 Mapping local message state to new/old message status and urgency is 212 an implementation issue of the messaging server. 214 Messaging systems MAY use any algorithm for determining the 215 approporiate media type for a message. Such algorithms are out of 216 scope of this document. Systems which use Internet Mail SHOULD use 217 the Message-Context header [6] if present as a hint to make a media 218 type determination. 220 3.6 Subscriber generation of SUBSCRIBE requests 222 Subscriber User Agents will typically SUBSCRIBE to message summary 223 information for a period of hours or days, and automatically attempt 224 to re-SUBSCRIBE well before the subscription is completely expired. 225 If re-subscription fails, the Subscriber SHOULD periodically retry 226 again until a subscription is successful, taking care to backoff to 227 avoid network congestion. If a subscription has expired, new re- 228 subscriptions MUST use a new Call-ID. 230 The Subscriber SHOULD SUBSCRIBE to that user's message summaries 231 whenever a new user becomes associated with the device (a new login). 232 The Subscriber MAY also explicitly fetch the current status at any 233 time. The subscriber SHOULD renew its subscription immediately after 234 a reboot, or when the subscriber's network connectivity has just been 235 re-established. 237 The Subscriber MUST be prepared to receive and process a NOTIFY with 238 new state immediately after sending a new SUBSCRIBE, a SUBSCRIBE, 239 renewal, an unSUBSCRIBE or a fetch; or at any time during the 240 subscription. 242 When a user de-registers from a device (logoff, power down of a 243 mobile device, etc.), subscribers SHOULD unsubscribe by sending a 244 SUBSCRIBE message with an Expires header of zero. 246 3.7 Notifier processing of SUBSCRIBE requests 248 When a SIP Messaging System receives SUBSCRIBE messages with the 249 message-summary event-type, it SHOULD authenticate the subscription 250 request. If authentication is successful, the Notifier MAY limit the 251 duration of the subscription to an administrator defined amount of 252 time as described in SIP Events. 254 3.8 Notifier generation of NOTIFY requests 256 Immediately after a subscription is accepted, the Notifier MUST send 257 a NOTIFY with the current message summary information. This allows 258 the Subscriber to resynchronize its state. This initial 259 synchronization NOTIFY MUST NOT include the optional message headers. 261 When the status of the messages changes sufficiently for a messaging 262 account to change the number of new or old messages, the Notifier 263 SHOULD send a NOTIFY message to all active subscribers to that 264 account. NOTIFY messages sent to subscribers of a group or alias, 265 MUST place the account name in the user part of the Contact header 266 URL. 268 A Messaging System MAY send a NOTIFY with an "Expires" header of "0" 269 and a "Subscription-State" header of "terminated" before a graceful 270 shutdown. 272 3.9 Subscriber processing of NOTIFY requests 274 Upon receipt of a valid NOTIFY request, the subscriber SHOULD 275 immediately render the message status and summary information to the 276 end user in an implementation specific way. 278 The Subscriber MUST be prepared to receive NOTIFYs from different 279 Contacts corresponding to the same SUBSCRIBE. (the SUBSCRIBE may 280 have been forked). 282 3.10 Handling of Forked Requests 284 Forked requests are allowed for this event type and may install 285 multiple subscriptions. The Subscriber MAY render multiple summaries 286 to the user, or MAY merge them as described below. 288 If any of the "Messages-Waiting" status lines report "yes", then the 289 merged state is "yes"; otherwise the merged state is "no". 291 status-line = "Messages-Waiting: " status CRLF 292 status = "yes" / "no" 294 The Subscriber MAY merge summary lines in an implementation-specific 295 way if all notifications contain at least one summary line. 297 summary-line = media-type ":" SP new "/" old [ SP urgent ] CRLF 298 urgent = "(" new-urgent "/" old-urgent ")" 300 A Subscriber MAY use an "alias" or "group" in the To header and/or 301 Request-URI if that name is significant to the messaging system. 303 3.11 Rate of notifications 305 A Notifier MAY choose to buffer NOTIFY responses for a short 306 administrator-defined period (seconds or minutes) when the message 307 status is changing rapidly. This buffering behavior is RECOMMENDED. 308 Note that timely notification of a newly added message is probably 309 more significant to the end user than notifications of newly deleted 310 messages which do not affect the overall message waiting state. 312 Notifiers SHOULD NOT generate NOTIFY requests more frequently than 313 once per second. 315 3.12 State Agents 317 Implementers MAY create a service which consolidates and summarizes 318 NOTIFYs from many Contacts. This document does not preclude 319 implementations from building state agents which support this event 320 package. 322 3.13 Behavior of a Proxy Server 324 There are no additional requirements on a SIP Proxy, other than to 325 transparently forward the SUBSCRIBE and NOTIFY methods as required in 326 SIP. However, Proxies SHOULD allow non-SIP URLs. Proxies and 327 Redirect servers SHOULD be able to direct the SUBSCRIBE request to an 328 appropriate messaging server User Agent. Proxies are encouraged to 329 support routing to Contacts based on the existence of 330 methods="SUBSCRIBE" and feature="voice-mail" parameters in an Accept- 331 Contact header (as specified in the caller preferences 332 specification). 334 4. Examples of Usage 336 4.1 Example Message Flow 338 The examples shown below are for informational purposes only. For a 339 normative description of the event package, please see sections 4 and 340 6 of this document. 342 In the example call flow below, Rohan's IP phone subscribes to the 343 status of Rohan's messages. Via headers are omitted for clarity. 345 Subscriber Notifier 346 | | 347 | A1: SUBSCRIBE (new) | 348 |---------------------->| 349 | A2: 200 OK | 350 |<----------------------| 351 | | 352 | A3: NOTIFY (sync) | 353 |<----------------------| 354 | A4: 200 OK | 355 |---------------------->| 356 | | 357 | | 358 | A5: NOTIFY (change) | 359 |<----------------------| 360 | A6: 200 OK | 361 |---------------------->| 362 | | 363 | | 364 | A7: (re)SUBSCRIBE | 365 |---------------------->| 366 | A8: 200 OK | 367 |<----------------------| 368 | | 369 | A9: NOTIFY (sync) | 370 |<----------------------| 371 | A10: 200 OK | 372 |---------------------->| 373 | | 374 | | 375 | A11: (un)SUBSCRIBE | 376 |---------------------->| 377 | A12: 200 OK | 378 |<----------------------| 379 | | 380 | A13: NOTIFY (sync) | 381 |<----------------------| 382 | A14: 200 OK | 383 |---------------------->| 385 A1: Subscriber (Rohan's phone) -> 386 Notifier (Rohan's voicemail gateway) 387 Subscribe to Rohan's message summary status for 1 day. 389 SUBSCRIBE sip:rohan@vmail.cisco.com SIP/2.0 390 To: 391 From: ;tag=78923 392 Date: Mon, 10 Jul 2000 03:55:06 GMT 393 Call-Id: 1349882@rmahy-phone.cisco.com 394 CSeq: 4 SUBSCRIBE 395 Contact: 396 Event: message-summary 397 Expires: 86400 398 Accept: application/simple-message-summary 399 Content-Length: 0 401 A2: Notifier -> Subscriber 403 SIP/2.0 200 OK 404 To: ;tag=4442 405 From: ;tag=78923 406 Date: Mon, 10 Jul 2000 03:55:07 GMT 407 Call-Id: 1349882@rmahy-phone.cisco.com 408 CSeq: 4 SUBSCRIBE 409 Expires: 86400 410 Content-Length: 0 412 A3: Notifier -> Subscriber 413 (immediate synchronization of current state: 414 2 new and 8 old [2 urgent] messages) 416 NOTIFY sip:rohan@rmahy-phone.cisco.com SIP/2.0 417 To: ;tag=78923 418 From: ;tag=4442 419 Date: Mon, 10 Jul 2000 03:55:07 GMT 420 Call-Id: 1349882@rmahy-phone.cisco.com 421 CSeq: 20 NOTIFY 422 Contact: 423 Event: message-summary 424 Subscription-State: active 425 Content-Type: application/simple-message-summary 426 Content-Length: 45 428 Messages-Waiting: yes 429 Voicemail: 2/8 (0/2) 431 A4: Subscriber -> Notifier 433 SIP/2.0 200 OK 434 To: ;tag=78923 435 From: ;tag=4442 436 Date: Mon, 10 Jul 2000 03:55:08 GMT 437 Call-Id: 1349882@rmahy-phone.cisco.com 438 CSeq: 20 NOTIFY 439 Content-Length: 0 441 A5: Notifier -> Subscriber 442 This is a notification of new messages. 443 Some headers from the new messages are appended. 445 NOTIFY sip:rohan@rmahy-phone.cisco.com SIP/2.0 446 To: ;tag=78923 447 From: ;tag=4442 448 Date: Mon, 10 Jul 2000 04:28:53 GMT 449 Contact: 450 Call-ID: 1349882@rmahy-phone.cisco.com 451 CSeq: 31 NOTIFY 452 Event: message-summary 453 Subscription-State: active 454 Content-Type: application/simple-message-summary 455 Content-Length: 420 457 Messages-Waiting: yes 458 Voicemail: 4/8 (1/2) 460 To: 461 From: 462 Subject: carpool tomorrow? 463 Date: Sun, 09 Jul 2000 21:23:01 -0700 464 Priority: normal 465 Message-ID: 13784434989@vmail.cisco.com 467 To: 468 From: 469 Subject: HELP! at home ill, present for me please 470 Date: Sun, 09 Jul 2000 21:25:12 -0700 471 Priority: urgent 472 Message-ID: 13684434990@vmail.cisco.com 474 A6: Subscriber -> Notifier 476 SIP/2.0 200 OK 477 To: ;tag=78923 478 From: ;tag=4442 479 Date: Mon, 10 Jul 2000 04:28:53 GMT 480 Call-ID: 1349882@rmahy-phone.cisco.com 481 CSeq: 31 NOTIFY 482 Content-Length: 0 484 A7: Subscriber -> Notifier 485 Refresh subscription. 487 SUBSCRIBE sip:rohan@vmail.cisco.com SIP/2.0 488 To: ;tag=4442 489 From: ;tag=78923 490 Date: Mon, 10 Jul 2000 15:55:06 GMT 491 Call-Id: 1349882@rmahy-phone.cisco.com 492 CSeq: 8 SUBSCRIBE 493 Contact: 494 Event: message-summary 495 Expires: 86400 496 Accept: application/simple-message-summary 497 Content-Length: 0 499 A8: Notifier -> Subscriber 501 SIP/2.0 200 OK 502 To: ;tag=4442 503 From: ;tag=78923 504 Date: Mon, 10 Jul 2000 15:55:07 GMT 505 Call-Id: 1349882@rmahy-phone.cisco.com 506 CSeq: 8 SUBSCRIBE 507 Contact: 508 Expires: 86400 509 Content-Length: 0 511 A9: Notifier -> Subscriber 512 (immediate synchronization of current state) 514 NOTIFY sip:rohan@rmahy-phone.cisco.com SIP/2.0 515 To: ;tag=78923 516 From: ;tag=4442 517 Date: Mon, 10 Jul 2000 15:55:07 GMT 518 Call-Id: 1349882@rmahy-phone.cisco.com 519 CSeq: 47 NOTIFY 520 Contact: 521 Event: message-summary 522 Subscription-State: active 523 Content-Type: application/simple-message-summary 524 Content-Length: 45 526 Messages-Waiting: yes 527 Voicemail: 4/8 (1/2) 529 A10: Subscriber -> Notifier 531 SIP/2.0 200 OK 532 To: ;tag=78923 533 From: ;tag=4442 534 Date: Mon, 10 Jul 2000 15:55:08 GMT 535 Call-Id: 1349882@rmahy-phone.cisco.com 536 CSeq: 47 NOTIFY 537 Contact: 539 A11: Subscriber -> Notifier 540 Un-subscribe after "rohan" logs out. 542 SUBSCRIBE sip:rohan@vmail.cisco.com SIP/2.0 543 To: ;tag=4442 544 From: ;tag=78923 545 Date: Mon, 10 Jul 2000 19:35:06 GMT 546 Call-Id: 1349882@rmahy-phone.cisco.com 547 CSeq: 17 SUBSCRIBE 548 Contact: 549 Event: message-summary 550 Expires: 0 551 Accept: application/simple-message-summary 552 Content-Length: 0 554 A12: Notifier -> Subscriber 556 SIP/2.0 200 OK 557 To: ;tag=4442 558 From: ;tag=78923 559 Date: Mon, 10 Jul 2000 19:35:07 GMT 560 Call-Id: 1349882@rmahy-phone.cisco.com 561 CSeq: 17 SUBSCRIBE 562 Contact: 563 Expires: 0 564 Content-Length: 0 566 A13: Notifier -> Subscriber 567 (immediate synchronization of current state, 568 which the subscriber can now ignore) 570 NOTIFY sip:rohan@rmahy-phone.cisco.com SIP/2.0 571 To: ;tag=78923 572 From: ;tag=4442 573 Date: Mon, 10 Jul 2000 19:35:07 GMT 574 Call-Id: 1349882@rmahy-phone.cisco.com 575 CSeq: 56 NOTIFY 576 Contact: 577 Event: message-summary 578 Subscription-State: active 579 Content-Type: application/simple-message-summary 580 Content-Length: 45 582 Messages-Waiting: yes 583 Voicemail: 4/8 (1/2) 585 A10: Subscriber -> Notifier 587 SIP/2.0 200 OK 588 To: ;tag=78923 589 From: ;tag=4442 590 Date: Mon, 10 Jul 2000 19:35:08 GMT 591 Call-Id: 1349882@rmahy-phone.cisco.com 592 CSeq: 56 NOTIFY 593 Event: message-summary 594 Content-Length: 0 596 4.2 Example Usage with Caller Preferences 598 The use of caller preferences is optional but encouraged. If caller 599 preferences is used, a messaging server MAY REGISTER a Contact with a 600 "SUBSCRIBE" methods tag. If SUBSCRIBE is used by other services, the 601 messaging server MAY also REGISTER as a Contact with the 602 feature="voice-mail" tag. An example of this kind of registration 603 follows below. 605 REGISTER sip:sip3-sj.cisco.com SIP/2.0 606 To: 607 From: ;tag=4442 608 ... 609 Contact: 610 ;feature="voice-mail";methods="SUBSCRIBE" 612 The following SUBSCRIBE message would find the Contact which 613 registered in the example above. 615 SUSBCRIBE sip:rohan@cisco.com SIP/2.0 616 ... 617 Accept: application/simple-message-summary 618 Accept-Contact: *;feature="voice-mail";methods="SUBSCRIBE" 620 5. Formal Syntax 622 The following syntax specification uses the augmented Backus-Naur 623 Form (BNF) as described in RFC-2234 [5]. 625 5.1 New event-package definition 627 This document defines a new event-package with the package name: 629 message-summary 631 5.2 Body Format Syntax 633 The formal syntax for application/simple-message-summary is below: 635 messsage-summary = status-line [*(summary-line)] [ *msg ] 636 status-line = "Messages-Waiting:" SP status CRLF 637 status = "yes" / "no" 639 summary-line = media-type ":" SP new "/" old [ SP urgent ] CRLF 640 urgent = "(" new-urgent "/" old-urgent ")" 641 media-type = "Voicemail" / "Email" / "Fax" / "Video" 643 msg = CRLF 1*(mheader) 644 mheader = mhname ":" SP mhvalue CRLF 645 mhname = alphanum 1*( alphanum / "-" / "_" ) 646 mhvalue = *( HTAB / %x20-7E / UTF8-NONASCII ) 648 new = 1*DIGIT 649 old = 1*DIGIT 650 new-urgent = 1*DIGIT 651 old-urgent = 1*DIGIT 653 6. IANA Considerations 655 6.1 SIP Event Package Registration for message-summary 657 Package name: message-summary 659 Type: package 661 Contact: [Mahy] 663 Published Specification: This document. 665 6.2 MIME Registration for application/simple-message-summary 667 MIME media type name: application 669 MIME subtype name: simple-message-summary 671 Required parameters: none. 673 Optional parameters: none. 675 Encoding considerations: This type is only defined for transfer 676 via SIP [1]. 678 Security considerations: See the "Security Considerations" 679 section in this document. 681 Interoperability considerations: none 683 Published specification: This document. 685 Applications which use this media: The simple-message-summary 686 application subtype supports the exchange of message waiting and 687 message summary information in SIP networks. 689 Additional information: 691 1. Magic number(s): N/A 693 2. File extension(s): N/A 695 3. Macintosh file type code: N/A 697 7. Security Considerations 699 Message Summaries and optional message bodies contain information 700 which is typically very privacy sensitive. At minimum, subscriptions 701 to this event package SHOULD be authenticated; and notifications 702 SHOULD be encrypted and integrity protected using either end-to-end 703 mechanisms, or the hop-by-hop protection afforded messages sent to 704 SIPS URIs. 706 Additional security considerations are covered in SIP [1] and SIP 707 Events [2]. 709 8. Revision history 710 8.1 Open Issues 712 1. Should the "media types" concept be replaced entirely with 713 message contexts? This would be a non-backwards compatible 714 change, but appears to be a better semantic match than what is in 715 the draft now. This would also add extensibility and change 716 control in a single document. The list of valid message-context- 717 classes are voice-message, fax-message, pager-message, 718 multimedia-message, text-message, and none. 720 2. Should the syntax follow that of SIP instead of the restrictive 721 syntax now in place? A SIP syntax would add line folding, for 722 example. The optional message-headers would borrow the 723 "extension-header" syntax from SIP and the per-media (or per- 724 message-context) summary lines would use the explicit whitespace 725 separators defined in SIP (ex: HCOLON, SLASH). 727 3. If forking or state agents are supported, and the subscriber 728 subscribes to a group alias, how is the specific messaging 729 account specified in the corresponding notifies. 731 8.2 Changes from draft-mahy-sipping-mwi-00 733 1. Updated references and split into normative and informational 735 2. Removed normative behavior now specified in Events 737 3. Updated to address the event package sections now specified in 738 Events. 740 4. Added the Subscription-State header field to the examples and 741 removed the Event header field from responses. 743 5. Removed redundant BNF 745 6. Simplified text on how to choose the media type. For Internet 746 Mail, this now references the Message-Context header. 748 8.3 Changes from draft-mahy-sip-mwi-01 750 1. This document is now formatted as a SIP Event Package as defined 751 in Section 4 of SIP Events [2]. 753 2. The event-package name is now "message-summary", to allow for 754 other bodies to extend the package. 756 3. The "urgent" token was missing from the BNF. 758 8.4 Changes from draft-mahy-sip-mwi-00 760 This draft greatly simplifies and shortens the -00 version. 762 1. The generic behavior of SUBSCRIBE/NOTIFY is now greatly clarified 763 in SIP Events [2] and made consistent with PINT and SIP for 764 presence. This message waiting draft is now consistent with SIP 765 Events [2]. 767 2. The XML format has been removed due to lack of immediate 768 interest. At a future date, similar functionality may be added 769 as another body definition with an appropriate MIME type. 771 3. An IANA Considerations section was added to register the new 772 "application/simple-message-summary" MIME type and the "simple- 773 message-summary" SIP event package. 775 4. The "flag-list" was removed due to lack of interest and to 776 encourage simplicity. 778 5. Due to synchronization issues, and the recommendation of the VPIM 779 Working Group, support for message count "deltas" was removed. 781 6. The Messages-Waiting line in the body is now mandatory. 783 7. This version of the draft clarifies the role of caller 784 preferences as optional but encouraged. 786 8. A set of SMTP-like headers from the triggering messages may now 787 optionally follow the message summaries, provided that the 788 resulting NOTIFY on UDP fits in a single datagram. 790 9. Contributors 792 Ilya Slain came up with the initial format of the text body contained 793 in this document. He was previously listed as a co-author, however, 794 he is no longer reachable. 796 10. Acknowledgments 798 Thanks to Dave Oran, Bill Foster, Steve Levy, Denise Caballero- 799 McCann, Jeff Michel, Priti Patil, Satyender Khatter, Bich Nguyen, 800 Manoj Bhatia, David Williams, and Bryan Byerly of Cisco; and Jonathan 801 Rosenberg and Adam Roach of Dynamicsoft. 803 Normative References 805 [1] Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation 806 Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress), 807 February 2002. 809 [2] Roach, A., "SIP-Specific Event Notification", draft-ietf-sip- 810 events-05 (work in progress), March 2002. 812 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 813 Levels", BCP 14, RFC 2119, March 1997. 815 [4] Rosenberg, J. and H. Schulzrinne, "SIP Caller Preferences and 816 Callee Capabilities", draft-ietf-sip-callerprefs-05 (work in 817 progress), November 2001. 819 [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax 820 Specifications: ABNF", RFC 2234, November 1997. 822 [6] Klyne, G., Burger, E., Candell, E. and C. Eliot, "Message 823 Context for Internet Mail", draft-ietf-vpim-hint-08 (work in 824 progress), June 2002. 826 Informational References 828 [7] Parsons, G. and G. Vaudreuil, "Voice Profile for Internet Mail 829 - version 2", RFC 2421, September 1998. 831 [8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 832 Extensions (MIME) Part Two: Media Types", RFC 2046, November 833 1996. 835 [9] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 837 [10] Telcordia, "GR-506: Signaling for Analog Interfaces, Issue 1, 838 Revision 1", Nov 1996. 840 Author's Address 842 Rohan Mahy 843 Cisco Systems, Inc. 844 170 West Tasman Drive 845 San Jose, CA 95134 846 USA 848 EMail: rohan@cisco.com 850 Full Copyright Statement 852 Copyright (C) The Internet Society (2002). All Rights Reserved. 854 This document and translations of it may be copied and furnished to 855 others, and derivative works that comment on or otherwise explain it 856 or assist in its implementation may be prepared, copied, published 857 and distributed, in whole or in part, without restriction of any 858 kind, provided that the above copyright notice and this paragraph are 859 included on all such copies and derivative works. However, this 860 document itself may not be modified in any way, such as by removing 861 the copyright notice or references to the Internet Society or other 862 Internet organizations, except as needed for the purpose of 863 developing Internet standards in which case the procedures for 864 copyrights defined in the Internet Standards process must be 865 followed, or as required to translate it into languages other than 866 English. 868 The limited permissions granted above are perpetual and will not be 869 revoked by the Internet Society or its successors or assigns. 871 This document and the information contained herein is provided on an 872 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 873 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 874 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 875 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 876 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 878 Acknowledgement 880 Funding for the RFC Editor function is currently provided by the 881 Internet Society.