Internet Engineering Task Force Rohan Mahy Internet Draft Ilya Slain Document: draft-mahy-sip-message-waiting-00.txt Cisco Systems Expires: January, 2001 July 2000 SIP Extensions for Message Waiting Indication Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is an individual submission to the IETF. Comments should be directed to the authors. 1. Abstract SIP [2] is very useful as a protocol for finding users and for rendezvous with those users. It is also very good at getting status and presence information which corresponds to those users (see the work of the PINT WG [3], and recent SIP-based proposals for Instant Messaging (IM) [4], and Presence [5]). This draft proposes using SIP with the SUBSCRIBE/NOTIFY methods [6] to carry message waiting status and message summaries from a messaging system to an interested User Agent. This proposal contains two message body definitions. The first is a simple text representation suitable for giving the status of a single folder. The second uses XML [7]; it can carry status for multiple message folders within an account, it is compatible with XSL [8] style sheets, and it can be extended later without breaking backwards compatibility. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [9]. Mahy, Slain [Page 1] Internet Draft SIP Message Waiting July 2000 3. Background and Overview Messaging Waiting Indication is a common feature of telephone networks. It typically involves playing a special dial tone (called message-waiting dial tone), lighting a light or indicator on the phone, or both. Message-waiting dial tone is similar but distinct from stutter dial tone. Both are defined in GR506 [10]. The methods in SIP 2.0, as defined in RFC2543, were only designed to solve the problem of session initiation for multimedia sessions, and rendezvous. Since Message Waiting Indication is really status information orthogonal to a session, it was not clear how an IP telephone acting as a SIP User Agent would implement comparable functionality. Members of the telephony community viewed this as a shortcoming of SIP. Users want the useful parts of the functionality they had using traditional analog and PBX telephones. It is also desirable to provide comparable functionality in a flexible way that allows for more customization and new features. Using the SUBSCRIBE and NOTIFY methods, A Subscriber User Agent (typically an IP phone or SIP soft-phone) subscribes to the status of their messages. A SIP User Agent acting on behalf of the user's messaging system then notifies the Subscriber whenever the account's messages have changed. A User Agent can also explicitly fetch the current status which is returned in a 200 OK. A fetch does not require a subscription. A SIP User Agent MAY subscribe to multiple accounts (distinguished by the URL in the To header), each with their own separate subscriptions and notifications. Multiple SIP User Agents MAY subscribe to the same account. The formats specified in this proposal attempt to separate orthogonal attributes of messages as much as possible. Messages are separated by media type (audio, text, image, and video); by message status (untouched, read, skipped, answered, etc.); by urgent and non-urgent type; and in the XML format, by mail folder. 4. Overview of Operation Before any subscriptions are sent, a messaging server MAY REGISTER a Contact with a "SUBSCRIBE" methods tag (specified in the caller preferences specification [11]), or the administrator MAY manually configure the proxy or User Agents to forward SUBSCRIBE requests appropriately. If SUBSCRIBE is used by other services, the User Agent or Proxy need a way to determine the relevant Contact. The feature="voicemail" tag is one of many appropriate mechanisms. An example of this kind of registration follows below. REGISTER sip:sip3-sj.cisco.com SIP/2.0 To: Mahy, Slain [Page 2] Internet Draft SIP Message Waiting July 2000 From: ... Contact: A SUBSCRIBE message with the Request-Contact header would find the Contact requested above. In the example call flow below, Rohan's IP phone subscribes to the status of Rohan's messages. The Subscriber uses the Accept header to inform the Notifier that it can use the XML format for message summaries. Via headers are omitted for clarity. Subscriber Notifier | | | | | A1: SUBSCRIBE | | (w/immediate status) | |---------------------->| | | | A2: 200 OK | |<----------------------| | | | | | | | A3: SUBSCRIBE | | (refresh timer) | |---------------------->| | | | A4: 200 OK | |<----------------------| | | | | | | | A5 & A6: NOTIFY | |<----------------------| | | | A7: 200 OK | |---------------------->| | | | | | A8: SUBSCRIBE | | (unsubscribe) | |---------------------->| | | | A9: 200 OK | |<----------------------| | | Call Flow for example A: Mahy, Slain [Page 3] Internet Draft SIP Message Waiting July 2000 A1: Subscriber (Rohan's phone) -> Notifier (Rohan's voicemail gateway) Subscribe to Rohan's message summary status for 1 day. And reply immediately. SUBSCRIBE sip:rohan@cisco.com SIP/2.0 To: From: Date: Mon, 10 Jul 2000 03:55:06 -0700 Call-Id: 1349882@dhcp78-193.cisco.com CSeq: 4 SUBSCRIBE Request-Contact: *;feature="voicemail" Event: message-summary;immediate Expires: 86400 Accept: text/xml Content-Length: 0 A2: Notifier -> Subscriber Notifier sends a 200 OK with the current status below. In this example, the Notifier only supported simple text. SIP/2.0 200 OK To: From: Date: Mon, 10 Jul 2000 03:55:07 -0700 Call-Id: 1349882@dhcp78-193.cisco.com CSeq: 4 SUBSCRIBE Expires: 86400 Event: message-summary;immediate Content-Type: text/plain Content-Length: 44 Voicemail: 1/3; u:1/0; r:2/0; a:1/1; d:2/0 A3: Subscriber (Rohan's phone) -> Notifier (Rohan's voicemail gateway) Re-subscribe after half the subscription is over. SUBSCRIBE sip:rohan@cisco.com SIP/2.0 To: From: Date: Mon, 10 Jul 2000 15:55:14 -0700 Contact: Call-Id: 1349882@dhcp78-193.cisco.com CSeq: 5 SUBSCRIBE Request-Contact: *;feature="voicemail" Event: message-summary Expires: 86400 Accept: text/xml Content-Length: 0 A4: Notifier -> Subscriber Mahy, Slain [Page 4] Internet Draft SIP Message Waiting July 2000 SIP/2.0 200 OK To: From: Date: Mon, 10 Jul 2000 15:55:14 -0700 Call-Id: 1349882@dhcp78-193.cisco.com CSeq: 5 SUBSCRIBE Expires: 86400 Event: message-summary Content-Length: 0 A5: Notifier -> Subscriber This is a notification using message summary deltas. Deltas are supported with both plain text and XML formats. NOTIFY sip:rohan@dhcp78-193.cisco.com SIP/2.0 To: From: Date: Mon, 10 Jul 2000 16:28:53 -0700 Contact: Call-ID: 1349882@dhcp78-193.cisco.com CSeq: 8938 NOTIFY Event: message-summary Content-Type: text/plain Content-Length: 49 Voicemail: +4/-1; u:+3/+1; d:+1/0 Email: +1/0 A6: Notifier -> Subscriber This is a notification using "classic", boolean message waiting. NOTIFY sip:rohan@dhcp78-193.cisco.com SIP/2.0 To: From: Date: Mon, 10 Jul 2000 16:28:53 -0700 Contact: Call-ID: 1349882@dhcp78-193.cisco.com CSeq: 8938 NOTIFY Event: message-summary Content-Type: text/plain Content-Length: 22 Message-Waiting: yes A7: Subscriber -> Notifier SIP/2.0 200 OK To: From: Date: Mon, 10 Jul 2000 16:28:54 -0700 Call-ID: 1349882@dhcp78-193.cisco.com CSeq: 8938 NOTIFY Mahy, Slain [Page 5] Internet Draft SIP Message Waiting July 2000 Event: message-summary Content-Length: 0 A8: Subscriber -> Notifier Un-subscribe after "rohan" logs out. SUBSCRIBE sip:rohan@cisco.com SIP/2.0 To: From: Date: Mon, 10 Jul 2000 19:02:19 -0700 Contact: Call-Id: 1349882@dhcp78-193.cisco.com CSeq: 8 SUBSCRIBE Request-Contact: *;feature="voicemail" Event: message-summary Expires: 0 Content-Length: 0 A9: Notifier -> Subscriber SIP/2.0 200 OK To: From: Date: Mon, 10 Jul 2000 19:02:19 -0700 Call-Id: 1349882@dhcp78-193.cisco.com CSeq: 8 SUBSCRIBE Event: message-summary Expires: 0 Content-Length: 0 Subscriber Notifier | | | | | B1: SUBSCRIBE | | (fetch) | |---------------------->| | | | B2: 401 Unauthorized | |<----------------------| | | | | | | | B3: SUBSCRIBE | | (fetch w/ auth) | |---------------------->| | | | B4: 200 OK | |<----------------------| | | Call flow for example B: Mahy, Slain [Page 6] Internet Draft SIP Message Waiting July 2000 B1: Subscriber -> Notifier This is an explicit fetch request. SUBSCRIBE sip:rohan@cisco.com SIP/2.0 To: From: Date: Mon, 10 Jul 2000 17:09:35 -0700 Call-Id: 1349883@dhcp78-193.cisco.com CSeq: 6 SUBSCRIBE Request-Contact: *;feature="voicemail" Event: message-summary Expires: 0 Accept: text/xml Content-Length: 0 B2: Notifier -> Subscriber The Notfier requires authentication. SIP/2.0 401 Unauthorized To: From: Date: Mon, 10 Jul 2000 17:09:35 -0700 Call-Id: 1349883@dhcp78-193.cisco.com CSeq: 6 SUBSCRIBE Expires: 0 Event: message-summary WWW-Authenticate: Digest realm="Cisco", domain="cisco.com", nonce="hjhadf13hjlhad98qilllljqnjl", opaque="", stale="FALSE", algorithm="MD5" Content-Length: 0 B3: Subscriber -> Notifier Here is the same explicit fetch with authorization. SUBSCRIBE sip:rohan@cisco.com SIP/2.0 To: From: Date: Mon, 10 Jul 2000 17:09:35 -0700 Call-Id: 1349883@dhcp78-193.cisco.com CSeq: 7 SUBSCRIBE Request-Contact: *;feature="voicemail" Event: message-summary Expires: 0 Accept: text/xml Authorization: Digest username="rohan", realm="Cisco", nonce="hjhadf13hjlhad98qilllljqnjl", opaque="", uri="sip:rohan@cisco.com", response="jkg924jhjsdffhjlhsjl92u9pwvisdhwh" Content-Length: 0 B4: Notifier (supports XML format) -> Subscriber Mahy, Slain [Page 7] Internet Draft SIP Message Waiting July 2000 The Notfier supported the XML format; the fetch reply looks like this. SIP/2.0 200 OK To: From: Date: Mon, 10 Jul 2000 17:09:36 -0700 Call-Id: 1349883@dhcp78-193.cisco.com CSeq: 7 SUBSCRIBE Expires: 0 Event: message-summary Content-Type: text/xml Content-Length: 231 Inbox 1 2 1 2 User Agents that implement this proposal MUST support the simple text encoding, and SHOULD support the XML version if they have a large display, or native voice processing support (text-to-speech and/or speech recognition). Messaging server User Agents MUST support the simple text encoding, and SHOULD also support the XML format. User Agents and Proxies SHOULD tolerate non-SIP URI schemes in the To and From fields. 5. Use of SUBSCRIBE and NOTIFY 5.1 Backward compatibility A Requires header is not needed for the SUBSCRIBE and NOTIFY methods, because new methods are ignored or proxied transparently. A Requires header is not needed for the message-summary event-type, because User Agents which do not understand the event-type in the Event header will ignore the event-type. 5.2 Behavior of Subscriber (Ordinary User Agent) Subscriber User Agents will typically SUBSCRIBE to message summary information for a period of hours or days, and automatically attempt to re-SUBSCRIBE when the subscription is half-expired. If re- Mahy, Slain [Page 8] Internet Draft SIP Message Waiting July 2000 subscription fails, the Subscriber SHOULD retry again after the subscription is 66%, 75%, 80%, 85%, 90%, 95%, and 99% expired or until a subscription is successful. This retry sequence is similar to that used by DHCP [12] Clients trying to renew a lease. Re- subscriptions should reuse the same Call-Id, and increment the CSeq as appropriate. These SUBSCRIBE requests MUST have a valid Contact header. If a subscription has expired, the Subscriber MAY attempt to renew the expired subscription in intervals of about 10% of the expires period of the original or requested subscription. These new subscriptions MUST use a new Call-ID. The Subscriber SHOULD send a SUBSCRIBE and use the immediate option to get current state whenever a new user becomes associated with the device (a new login). The Subscriber MAY also explicitly fetch the current status at any time. The subscriber SHOULD fetch the current status after a reboot, or when the subscriber's network connectivity is just re-established. To generate an explicit fetch, generate a SUBSCRIBE with a new Call-Id, no Contact, and an Expires equal to zero. Although redundant, an ";immediate" tag is permitted in the Event header of a fetch. When a user deregisters from a device (logoff, power down of a mobile device, etc.), subscribers SHOULD unsubscribe by sending a SUBSCRIBE message with the To, From, Call-Id, and Contact used in the original subscription, but with an Expires header of zero. A Subscriber MAY use an "alias" or "group" in the To header and/or Request-URI if that name is significant to the messaging system. However, alias or group names MAY NOT appear in a fetch or a SUBSCRIBE request which includes the ";immediate" option. 5.3 Behavior of the Notifier (Messaging System) When a SIP Messaging System receives SUBSCRIBE messages with the message-summary event-type, it obeys the following rules. If the Contact field is absent, and the Expires header is zero, this is a fetch, a request for one time status. Include the text or XML content in the 200 OK reply. The Notifier MUST NOT create or modify subscriptions due to a fetch. The ";immediate" option is not required for an explicit fetch. A reply to a fetch MAY NOT contain relative (+/-) notation in message counts; it MUST contain only absolute message counts and/or boolean state. If the Contact field is absent and the Expires header is not zero, return a 400 (Bad Request) error. If the Contact field is present and the Expires header is zero, this is an request to unsubscribe. If the To, From, and Call-ID headers match an existing subscription, then the Notifier MUST remove the subscription state and send a 200 OK. The Notifier MUST NOT send the Mahy, Slain [Page 9] Internet Draft SIP Message Waiting July 2000 current state with the reply. If To, From, and Call-ID do not match, send a 481 (Call Leg/Transaction Does Not Exist) error. If the Contact field is present and the Expires header is non-zero, this is either a new subscription, or a re-subscription. If the To, From, and Call-ID match an existing subscription, then update the new expires time, otherwise create a new subscription. In either case, if the ";immediate" option follows the message-summary event- type, the 200 OK reply MUST contain the current status. If the ";immediate" option is not present, the Notifier SHOULD NOT include the message summary in the reply. If an immediate reply is returned, it MUST contain only absolute message counts and/or boolean state; it MAY NOT contain relative message counts. When the status of the messages changes for a messaging account, the Notifier SHOULD send a NOTIFY message to all subscribers to that account. The Call-ID, To, and From headers in the NOTIFY message MUST match the Call-ID, From, and To headers (respectively) used in the original SUBSCRIBE message. If there are any active group or alias subscriptions, NOTIFY messages sent to each subscriber of the group, if the status of any of the member accounts has changed. If there are changes in multiple accounts, separate NOTIFY messages are sent for each changed account. For group subscriptions, the Notifier MUST place the group name in the From field, and the user name associated with the changed account in the user part of the Contact header URL. Messages are ALWAYS counted individually within each account. A Notifier MAY choose to buffer NOTIFY responses for a short administrator-defined period (seconds or minutes) when the message status is changing rapidly. 5.4 Behavior of a Proxy Server There are no additional requirements on the Proxy, other than to transparently forward the SUBSCRIBE and NOTIFY methods. However, Proxies SHOULD allow non-SIP URLs. Proxies and Redirect servers SHOULD be able to direct the SUBSCRIBE request to an appropriate messaging server User Agent. Proxies SHOULD support routing to Contacts with the methods="SUBSCRIBE" extension, as specified in the caller preferences specification. 6. Text Format in Detail A simple text format is proposed to prevent an undue burden on low- end user agents, for example, inexpensive IP phones with no display. User Agents with a large usable display or other sophisticated features SHOULD also implement the XML format. 6.1 Semantics of the text format Mahy, Slain [Page 10] Internet Draft SIP Message Waiting July 2000 The text format contains message information about the default or "Inbox" folder only (multiple formats are allowed in the XML format only). The text format consists of at least one line. It may begin with a simple status line which is optional unless it is the only line. It has one summary line per media type of interest. If the the status line is absent, there must be at least one summary line. Valid media types are Voicemail (audio), Email (text), Fax (image), and Video (video). For each media type the total number of new and old messages is reported in the new and old fields. NEW messages are either UNTOUCHED or SKIPPED. OLD messages are either FLAGGED, READ, or ANSWERED. text-messsage-summary = [status-line] *(summary-line) status-line = "Messages-Waiting: " status CRLF summary-line = media-type ": " new "/" old [flag-list] CRLF status = "yes" | "no" In some cases, detailed message summaries are not available. The status line allows messaging systems or messaging gateways to provide the traditional boolean message waiting notification. Messages-Waiting: yes In the example that follows, more functionality is available to User Agent. There are one new and three old voice messages. Voicemail: 1/3 After the summary, the format can optionally list a summary count of messages by message status. These status "flags" correspond roughly to the status flags in IMAP4 [13]. The status flag names are in lowercase and correspond to the first letter of the status names listed below. They are defined below. flag-list = *("; " flag ":" message-num ["/" urgent-num]) flag = untouched | skipped | flagged | read | answered | deleted untouched = "u" skipped = "s" flagged = "f" read = "r" answered = "a" deleted = "d" UNTOUCHED The message has never been processed SKIPPED The user began "reading" the message, but didnÆt finish, reply, flag, delete, etc. FLAGGED The user marked the message for special processing READ The user read the complete message but did not flag, answer, or delete it Mahy, Slain [Page 11] Internet Draft SIP Message Waiting July 2000 ANSWERED The user answered the message (reply, forward, etc.) DELETED The user deleted the message In the following example, the following messages are represented in the Voicemail box: 1 untouched message, 2 read messages, 1 urgent answered message, and 2 deleted messages. The urgent answered message is counted in the total number of answered messages (1/1). Voicemail: 1/3; u:1/0; r:2; a:1/1; d:2/0 Some messaging systems only provide information about some kinds of message changes, and may natively provide message deltas (2 new messages arrived, 3 messages were marked as read, 1 was deleted). Therefore, for bodies in NOTIFY messages only (not acceptible in a 200 OK reply) the messaging systems MAY instead send message summaries of the number of additional or fewer messages preceded by a "+" or "-" respectively. The example below shows 4 unread messages have arrived (1 urgent), and one (old) message was deleted. The notation "+0" conveys that a number has not changed from its original value. An unsigned zero is ALWAYS an absolute measure, and always means that there are exactly zero messages. Note however that absolute and delta notation MAY NOT be mixed. Voicemail: +4/-1; u:+3/+1; d:+1/+0 If flags are used, there should be no counting overlap among the flag types (each message MUST be counted in EXACTLY one of these categories). Any of these categories can have an "urgent" attribute with the number of urgent messages of that type. If the "urgent" attribute is not supplied, it is assumed to be zero or unchanged for absolute and relative sumarries, respectively. In IMAP4, for example, the corresponding flags can overlap (a message can be \Seen, \Answered, \Deleted, and \Flagged for example). In this type of mapping, it is necessary to use a precedence of flags. Deleted messages are always categorized as Deleted, then Flagged, then Answered, then Read, and so forth. If mapping media types from VPIM [14], multipart/Voice-Message corresponds to voice, multipart/Fax-Message to fax, multipart/Video- Message to video, and everything else to email. The same flag MUST NOT appear more than once per media type. The flags SHOULD be presented in the order listed, but MAY be in any order. 6.2 Alternate placement for text format This proposal places the text format in a NOTIFY body or in the body of a SUBSCRIBE reply. However the contents of the body could be placed in the main part of NOTIFY message and treated as headers. Mahy, Slain [Page 12] Internet Draft SIP Message Waiting July 2000 For example, the body could also reside inside a LPIDF [15] message body. 7. XML Format in Detail 7.1 Example of message summary data in XML Following is an example of the proposed XML message summary format. Inbox 2 1 3 2 1 Inbox.Priority 77 4 3 2 7.2 Semantics of Elements A given user may have access to multiple mail accounts (an assistant may handle accounts for himself, his supervisor, and a general delivery account), and multiple users may be associated with the same user agent (as in a lab environment). Therefore a User Agent SHOULD be able to subscribe to multiple messaging accounts. Each account MUST contain summaries from at least one incoming folder. Mahy, Slain [Page 13] Internet Draft SIP Message Waiting July 2000 Users of IMAP4 or proprietary mail systems such as Microsoft Outlook or Lotus Notes, may have multiple mail folders on the same server for the same account. Each "interesting" folder SHOULD be included, but the messaging server MAY choose to send information only about the primary Inbox. The primary Inbox MUST always be the first folder listed and SHOULD have the name "Inbox" if no other name is required. Folder names are case insensitive. If multiple folders are present, they SHOULD be listed from the root as shown in the example below. Inbox Inbox Priority Inbox.Priority Spam Inbox.Spam Personal Inbox.Personal Financial Inbox.Personal.Financial Humor Inbox.Personal.Humor ProjectX ProjectX Archive1999 Archive1999 Incoming folders list a message summary count per media type. Valid Media types are: VOICEMAIL EMAIL FAX VIDEO Within each media type, the document lists a summary count of messages by message status. These status "flags" correspond roughly to the status flags in IMAP4. The status flags are listed below. UNTOUCHED The message has never been processed SKIPPED The user began "reading" the message, but didnÆt finish, reply, flag, delete, etc. FLAGGED The user marked the message for special processing READ The user read the complete message but did not flag, answer, or delete it ANSWERED The user answered the message (reply, forward, etc.) DELETED The user deleted the message There should be no counting overlap (each message MUST be counted in EXACTLY one of these categories). Any of these categories can have an "urgent" attribute with the number of urgent messages of that type. If the "urgent" attribute is not supplied, it is assumed to be 0. The number of additional or fewer messages may be used, signified by the +/- notation. For more detailed semantics, see the text format semantics section. NEW messages are UNTOUCHED + SKIPPED OLD messages are FLAGGED + READ + ANSWERED 7.3 Interpretation and Display of the XML document Mahy, Slain [Page 14] Internet Draft SIP Message Waiting July 2000 The User Agent could use an XSL or other style sheet to interpret the message summary in a way that is informative to that user. Style sheets would be fairly static. An administrator or a specific user may customize their style sheet, but would have a typical lifetime of months rather than minutes. In this example, the user doesn't care how many new email messages exist, unless they are urgent. An example style sheet might render the XML document above, and display the following information on my display, or play this information using TTS (Text-To-Speech), or with pre-recorded prompts. You have: 3 new (1 Urgent) and 3 old Voice messages You have: 1 new urgent Email message This same style sheet could also light the message waiting light, or play message-waiting dial tone. 7.4 Enclosure in other XML documents This XML document type could be enclosed inside a set of higher level tags in another XML document, for example inside an XML PIDF document [16]. 8. Formal Syntax 8.1 New event-type definition The syntax of the Event header is defined in SUBSCRIBE/NOTIFY as shown below. Event = "Event" ":" SP 1#event-type event-type = token This document amends that definition as shown below. event-type = message-event | token message-event = "message-summary" [";" "immediate"] 8.2 Text Format Syntax The following syntax specification for the text format uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [17]. Consistent with SIP (which this draft extends), mutiple choices are separated by a pipe character ("|") instead of the slash ("/") specified in RFC-2234. text-messsage-summary = [status-line] *(summary-line) status-line = "Messages-Waiting: " status CRLF summary-line = media-type ":" SP new "/" old [flag-list] CRLF status = "yes" | "no" Mahy, Slain [Page 15] Internet Draft SIP Message Waiting July 2000 flag-list = *(";" SP flag ":" message-num ["/" urgent-num]) media-type = "Voicemail" | "Email" | "Fax" | "Video" flag = untouched | skipped | flagged | read | answered | deleted untouched = "u" skipped = "s" flagged = "f" read = "r" answered = "a" deleted = "d" new = ["+" | "-"] WHOLENUMBER old = ["+" | "-"] WHOLENUMBER message-num = ["+" | "-"] WHOLENUMBER urgent-num = ["+" | "-"] WHOLENUMBER WHOLENUMBER = 1*DIGIT DIGIT = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" CRLF = %d13 %d10 SP = %d32 8.3 DTD for XML Format The following syntax specification for the XML format uses the Document Type Definition (DTD) as defined in SGML [18]. Elements marked with a "+" appear one or more times. Elements marked with a "?" appear zero or one times. All of the listed attributes are optional. If the "urgent" attribute is omitted, it is assumed to be zero. All elements are specified as CDATA (character data), but the implementation SHOULD verify that all fields except "name" are valid integers. Mahy, Slain [Page 16] Internet Draft SIP Message Waiting July 2000 9. Security Considerations At a minimum, SUBSCRIPTION requests for message waiting, and message waiting NOTIFY messages SHOULD be authenticated. Because of the potential privacy implications, encrypting NOTIFY messages is RECOMMENDED to keep potentially sensitive information private. Additionally, SUBSCRIPTION requests MAY be encrypted. Hop-by-hop encryption could discourage unauthorized disclosure of the address or location of the user's account. 10. Open Issues To do: - Write an XSL example. - Write more prose in the security section. - Harmonize terminology with draft-rosenberg-impp-presence-00.txt Questions: - Is the CDATA type in XML adequate for describing whole numbers? - Should the "media types" be audio, text, image, and video instead? - What error message does a UA give if it didn't understand the SUBSCRIBE event-type? - Is the proposed usage of SUBSCRIBE acceptable to the SIP WG? Mahy, Slain [Page 17] Internet Draft SIP Message Waiting July 2000 11. References [1] S Bradner, "The Internet Standards Process -- Revision 3", RFC2026 (BCP), IETF, October 1996. [2] M. Handley, E. Schooler, and H. Schulzrinne, "SIP: Session Initiation Protocol", RFC2543, Internet Engineering Task Force, Nov 1998. [3] L. Conroy, S. Petrack "The PINT Profile of SIP and SDP; A Protocol for IP Access to Telephone Call Services", Internet Engineering Task Force, March 1999. Work in progress. [4] J Rosenberg, et al., "SIP Extensions for Instant Messaging", Internet Draft , IETF; June 2000. Work in progress. [5] J Rosenberg, et al., "SIP Extensions for Presence", Internet Draft , IETF, June 2000. Work in progress. [6] Adam Roach, "Event Notification in SIP", Internet Draft , IETF; March 2000. Work in progress. [7] T. Bray, J. Paoli, and C. M. Sperberg-McQueen, "Extensible markup language (XML) 1.0," W3C Recommendation REC-xml-19980210, World Wide Web Consortium (W3C), Feb. 1998. Available at http://www.w3.org/TR/REC-xml. [8] "Extensible Stylesheet Language (XSL) Version 1.0", W3C Working Draft, W3C, March 2000. Work in progress. Available at: http://www.w3.org/TR/2000/WD-xsl-20000327/ [9] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, Mar. 1997. [10] "GR-506: Signaling for Analog Interfaces, Issue 1, Revision 1", Telecordia, November 1996. [11] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and callee capabilities," Internet Draft , Internet Engineering Task Force, Mar. 2000. Work in progress. [12] R Droms, "Dynamic Host Configuration Protocol", RFC2131, IETF, March 1997. [13] M Crispin, "Internet Message Access Protocol - Version 4rev1", RFC2060, IETF, December 1996. Mahy, Slain [Page 18] Internet Draft SIP Message Waiting July 2000 [14] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet Mail - version 2", RFC 2421, September 1998. [15] J Rosenberg, et al., "A Lightweight Presence Information Format", Internet Draft , IETF, June 2000. Work in progress. [16] J Rosenberg, et al., "A Data Format for Presence Using XML", Internet Draft , IETF, June 2000. Work in progress. [17] D Crocker, P Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC2234, IETF, Nov 1997. [18] ISO (International Organization for Standardization), "Information processing -- text and office systems -- standard generalized markup language (SGML)," ISO Standard ISO 8879:1986(E), International Organization for Standardization, Geneva, Switzerland, Oct. 1986. 12. Acknowledgments Thanks to 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; and Jonathan Rosenberg of Dynamicsoft. 11. Author's Addresses Rohan Mahy Cisco Systems 170 W Tasman Dr, MS: SJC-I/2/3 San Jose, CA 95134 USA Phone: +1 408 526 4000 Email: rohan@cisco.com Ilya Slain Cisco Systems 170 W Tasman Dr, MS: SJC09/2/2 San Jose, CA 95134 USA Phone: +1 408 527 9446 Email: islain@cisco.com Mahy, Slain [Page 19] Internet Draft SIP Message Waiting July 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into. Mahy, Slain [Page 20]