Contact: <sip:alice@alice-phone.example.com>
Expires: 86400
Content-Length: 0
A9: Notifier -> Subscriber
(immediate synchronization of current state)
NOTIFY sip:alice@alice-phone.example.com SIP/2.0
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 15:55:07 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 47 NOTIFY
Contact: <sip:alice@vmail.example.com>
Event: message-summary
Subscription-State: active
Content-Type: application/simple-message-summary
Content-Length: 99
Messages-Waiting: yes
Message-Account: sip:alice@vmail.example.com
Voice-Message: 4/8 (1/2)
A10: Subscriber -> Notifier
SIP/2.0 200 OK
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 15:55:08 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 47 NOTIFY
Contact: <sip:alice@vmail.example.com>
A11: Subscriber -> Notifier
Un-subscribe after "alice" logs out.
SUBSCRIBE sip:alice@vmail.example.com SIP/2.0
To: <sip:alice@example.com>;tag=4442
From: <sip:alice@example.com>;tag=78923
Date: Mon, 10 Jul 2000 19:35:06 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 17 SUBSCRIBE
Contact: <sip:alice@alice-phone.example.com>
Event: message-summary
Expires: 0
Accept: application/simple-message-summary
Content-Length: 0
A12: Notifier -> Subscriber
SIP/2.0 200 OK
To: <sip:alice@example.com>;tag=4442
From: <sip:alice@example.com>;tag=78923
Date: Mon, 10 Jul 2000 19:35:07 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 17 SUBSCRIBE
Contact: <sip:alice@alice-phone.example.com>
Expires: 0
Content-Length: 0
A13: Notifier -> Subscriber
(immediate synchronization of current state,
which the subscriber can now ignore)
NOTIFY sip:alice@alice-phone.example.com SIP/2.0
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 19:35:07 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 56 NOTIFY
Contact: <sip:alice@vmail.example.com>
Event: message-summary
Subscription-State: terminated;reason=timeout
Content-Type: application/simple-message-summary
Content-Length: 99
Messages-Waiting: yes
Message-Account: sip:alice@vmail.example.com
Voice-Message: 4/8 (1/2)
A14: Subscriber -> Notifier
SIP/2.0 200 OK
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 19:35:08 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 56 NOTIFY
Event: message-summary
Content-Length: 0
4.2. Example Usage with Callee Capabilities and Caller Preferences
The use of callee capabilities is optional but encouraged. If callee
capabilities are used, a messaging notifier MAY REGISTER a Contact
with an appropriate methods and events tag as shown in the example
below. To further distinguish itself, the messaging notifier MAY
also REGISTER as a Contact with the actor="msg-taker" tag. An
example of this kind of registration follows below.
REGISTER sip:sip3-sj.example.com SIP/2.0
To: <sip:alice@example.com>
From: <sip:alice@example.com>;tag=4442
...
Contact: <sip:alice@vm13-sj.example.com>
;actor="msg-taker";methods="SUBSCRIBE"
;automata;events="message-summary"
The following SUBSCRIBE message would find the Contact which
registered in the example above.
SUBSCRIBE sip:alice@example.com SIP/2.0
...
Accept: application/simple-message-summary
Event: message-summary
Accept-Contact: *;automata;actor="msg-taker"
5. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC 2234 [6].
5.1. New Event-Package Definition
This document defines a new event-package with the package name:
message-summary
5.2. Body Format Syntax
The formal syntax for the application/simple-message-summary MIME
type is described below. The message-context-class production is
defined in Section 6.2 of RFC 3458 [7]. Note that all productions
described here are case insensitive.
message-summary = msg-status-line CRLF
[msg-account CRLF]
[*(msg-summary-line CRLF)]
[ *opt-msg-headers ]
msg-status-line = "Messages-Waiting" HCOLON msg-status
msg-status = "yes" / "no"
msg-account = "Message-Account" HCOLON Account-URI
Account-URI = SIP-URI / SIPS-URI / absoluteURI
msg-summary-line = message-context-class HCOLON newmsgs SLASH oldmsgs
[ LPAREN new-urgentmsgs SLASH old-urgentmsgs RPAREN ]
opt-msg-headers = CRLF 1*(extension-header CRLF)
newmsgs = msgcount
oldmsgs = msgcount
new-urgentmsgs = msgcount
old-urgentmsgs = msgcount
msgcount = 1*DIGIT ; MUST NOT exceed 2^32-1
6. Security Considerations
Message summaries and optional message bodies contain information
which is typically very privacy sensitive. At a minimum,
subscriptions to this event package SHOULD be authenticated and
properly authorized. Furthermore, notifications SHOULD be encrypted
and integrity protected using either end-to-end mechanisms, or the
hop-by-hop protection afforded messages sent to SIPS URIs.
Additional and privacy security considerations are discussed in
detail in SIP [1] and SIP Events [2].
7. IANA Considerations
7.1. SIP Event Package Registration for message-summary
Package name: message-summary
Type: package
Contact: [Mahy]
Published Specification: This document.
7.2. MIME Registration for application/simple-message-summary
MIME media type name: application
MIME subtype name: simple-message-summary
Required parameters: none.
Optional parameters: none.
Encoding considerations: This MIME type was designed for
use with protocols which can carry binary-encoded data.
Although the format of this MIME type is similar to RFC 2822,
it is not identical. (Specifically, line folding rules are
SIP-specific and included URIs can contain non-ASCII
characters.) Protocols which do not carry binary data
(which have line length or character-set restrictions
for example) MUST use a reversible transfer encoding
(such as base64) to carry this MIME type.
Security considerations: See the "Security Considerations"
section in this document.
Interoperability considerations: none
Published specification: This document.
Applications which use this media: The simple-message-summary
application subtype supports the exchange of message waiting and
message summary information in SIP networks.
Additional information:
1. Magic number(s): N/A
2. File extension(s): N/A
3. Macintosh file type code: N/A
8. Contributors
Ilya Slain came up with the initial format of the text body contained
in this document. He was previously listed as a co-author, however,
he is no longer reachable.
9. Acknowledgments
Thanks to Dan Wing, Dave Oran, Bill Foster, Steve Levy, Denise
Caballero-McCann, Jeff Michel, Priti Patil, Satyender Khatter, Bich
Nguyen, Manoj Bhatia, David Williams, and Bryan Byerly of Cisco,
Jonathan Rosenberg and Adam Roach of Dynamicsoft, Eric Burger of
Snowshore, Nir Chen of Comverse, and Eric Tremblay of Mediatrix.
10. References
10.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", RFC
3841, August 2004.
[5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User
Agent Capabilities in the Session Initiation Protocol (SIP)",
RFC 3840, August 2004.
[6] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[7] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
Context for Internet Mail", RFC 3458, January 2003.
10.2. Informational References
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[9] Resnick, P., Ed., "Internet Message Format", RFC 2822, April
2001.
[10] Rosenberg, J., Roach, A.B., and B. Campbell, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", Work in Progress, June 2003.
[11] Telcordia, "GR-506: Signaling for Analog Interfaces, Issue 1,
Revision 1", Nov 1996.
11. Author’s Address
Rohan Mahy
Cisco Systems, Inc.
5617 Scotts Valley Drive, Suite 200
Scotts Valley, CA 95066
USA
EMail: rohan@cisco.com
12. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.