INTERNET-DRAFT M. Kocheisen draft-kocheisen-alert-format-00.txt J. Cloutier F. McNeil P. Rioux J. Tessier AT&T Labs Expires six months after: 19 October 1999 Alert and Notification Format Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Please send comments to the authors at . Abstract The Alert Format defines the MIME type message/alert. It describes how alerts and notifications are formatted in order that they can be sent and received by alert transport agents and alert receivers. The alert format is transport independent. However, in most parts it simply extends RFC 822 [RFC822] and uses RFC 2045 [MIME1], such that any RFC 822 or RFC 2045 message represents a simple and valid alert. Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 1] draft-kocheisen-alert-format-00.txt 19 October 1999 Table of Contents 1 Introduction.................................................3 1.1 Design Goal................................................3 1.2 Infrastructure.............................................3 1.3 Alert Addressing...........................................4 1.4 Terminology................................................4 2 Definition of an Alert.......................................4 2.1 General....................................................4 2.1 Direct Alert and Reference Alert...........................5 3 Alert Header Fields..........................................5 3.1 Reused RFC 822 Fields......................................6 3.1.1 FROM ....................................................6 3.1.2 TO, CC, and BCC..........................................6 3.1.3 SUBJECT..................................................6 3.1.4 DATE.....................................................6 3.1.5 MESSAGE-ID...............................................6 3.1.5 REFERENCES...............................................6 3.2 Reused RFC 2045 Fields.....................................6 3.2.1 CONTENT-TYPE.............................................6 3.2.2 MIME-VERSION.............................................6 3.3 New Alert Fields...........................................7 3.3.1 ALERT-DELIVERY-DATE......................................7 3.3.2 ALERT-EXPIRATION.........................................7 3.3.3 ALERT-PRIORITY...........................................8 3.3.4 ALERT-SENDER-URL.........................................8 3.3.5 ALERT-TYPE...............................................9 4 Types of Alerts..............................................9 4.1 Direct Alert..............................................10 4.2 Reference Alert...........................................10 5 Threads of Alerts...........................................11 6. Phone Number Representation.................................13 7. Implementation..............................................13 7.1 Minimal ATA Implementation Requirement....................13 7.2 HTTP Implementation.......................................14 8 Representation of Alert Types...............................14 8.1 Email Event...............................................14 8.1.1 Partial or Entire Email.................................15 8.1.2 External Email..........................................16 8.1.3 Example of a Partial Email..............................17 8.2 Fax Event.................................................18 8.3 NEWS Event................................................18 8.4 MIME Event................................................19 8.5 Phone Call Event..........................................20 8.6 Voice Mail Event..........................................21 9 Examples of an Advanced Alert...............................22 10 Security Considerations.....................................24 11 Syntax......................................................25 Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 2] draft-kocheisen-alert-format-00.txt 19 October 1999 12 References..................................................26 13 Contact Address.............................................27 1. Introduction This memo defines a format for the exchange of alerts and notifications. The alert format is protocol independent. However, in order to leverage existing SMTP infrastructure it extends the Internet text message standard RFC 822 by defining alert specific header fields and reusing some RFC 2045 header fields [MIME1]. 1.1 Design Goal It is a goal of this memo to describe a format which allows human beings as well as automated services to send/receive alerts in a simple but efficient way. The format was designed to be independent of a transport protocol (e.g. SMTP, HTTP, etc.) but it is intended for use on a TCP/IP network. However, to leverage today's email infrastructure an email sent by a regular email client should represent a legal alert. A tracking mechanism (alert thread) was defined in order to allow alert services or alert receivers to keep track of alerts that are related to each other. 1.2 Infrastructure The definition of the alerting format assumes the following generic infrastructure setting: Alert ------------------> Sender ----> ATA ----> ... ----> ATA ----> Receiver The Sender is an individual or a service who generates an alert. E.g., this can be an email client which sends a message to an alert service (by definition an RFC 822 or RFC 2045 message is a legal alert), or it could be an alert service which generates alerts about Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 3] draft-kocheisen-alert-format-00.txt 19 October 1999 events in the network (e.g. "you have new email"). The ATA (Alert Transport Agent) is any kind of server/service that receives and forwards alerts. The alert can be transported using arbitrary transport protocols (SMTP, HTTP, etc.). Any standard SMTP MTA (Message Transport Agent) can be seen as a simple ATA, however, MTAs were not designed for real-time delivery and therefore might not be efficient ATAs. Beside simply forwarding alerts, an ATA can also provide more advanced features like protocol conversion or alert filtering. The Receiver is a device or a client application which receives the alert and presents it to the recipient. A Receiver might also be a gateway which converts an alert into a different format (e.g. into a text message which doesn't follow the alert format). 1.3 Alert Addressing The addressing schema for an alert follows the common email addressing schema of @. (e.g. pierre@alerting.att.net). No assumptions about the receiver are made. The receiver can represent a user (michael@alerting.att.net) as well as a device (55511112222@pager.att.net). 1.4 Terminology The keywords "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 [KEYWORDS]. 2 Definition of an Alert 2.1 General Alerts or notifications are timely messages. They should be delivered in real-time (or near real-time) to the recipient. Because of their timeliness, a push model is appropriate. Because of the real-time aspect there is no explicit requirement to store an alert in case it could not be delivered (e.g. alert delivered by placing a phone call and nobody answers the phone), though, an alert service might choose to implement this option (i.e. guaranteed delivery). This has to be seen in contrast to email which uses a store-and- forward mechanism with guaranteed delivery, even when a message Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 4] draft-kocheisen-alert-format-00.txt 19 October 1999 transport agent (MTA) is unavailable to accept new email for a certain period. Also, for email, the last part of the delivery usually involves a pull mechanism (POP3, IMAP4, etc.). 2.1 Direct Alert and Reference Alert The alert format defines two different types of alerts, direct alerts and reference alerts. A direct alert is a simple alert sent to a receiver with an optional message in the alert body. The alert format was designed such that any RFC 822 or RFC 2045 message [RFC822, MIME1] is a valid direct alert. This enables any email client to send a direct alert to any ATA which supports the SMTP protocol for receiving alerts. A reference alert is defined as an alert which references some other event in the network. Reference alerts are often generated by services. Examples of reference alerts are notification about new email, incoming phone calls, traffic alerts, etc. The alert header of a reference alert contains a field which labels it as a reference alert. The alert body contains all the information about the referenced event. The distinction between direct alerts and reference alerts is necessary for ATAs and receivers to filter alerts correctly. In case of a direct alert a filter might be applied to the alert header. In case of a reference alert the filter would be applied to the body. In this case the body carries the information about the network event, whereas the alert header contains information about the alert generating service. See also section "4 Types of Alerts" below. 3 Alert Header Fields The alert format extends RFC 822 message format [RFC822] by adding some alert specific header fields. Moreover, it uses header fields and message structures defined in RFC 2045 [MIME1] to attach specific semantics to some alerts. Syntax and semantics of reused fields as well as the overall message structure and specification strictly follow the RFC 822 an RFC 2045 specification. Any email client can generate at least a simple Direct alert. Notification services can generate sophisticated alerts using the alert format defined in this document. The semantics of the reused Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 5] draft-kocheisen-alert-format-00.txt 19 October 1999 RFC 822 and RFC 2045 fields and the new alert specific fields are explained in the following sections. 3.1 Reused RFC 822 Fields All fields in this section follow the syntax specified in RFC 822 [RFC822]. 3.1.1 FROM The FROM field specifies the sender of the alert. The syntax is specified in RFC 822 [RFC822]. 3.1.2 TO, CC, and BCC The TO, CC and BCC field specify the recipient(s) of the alert. The syntax is specified in RFC 822 [RFC822]. 3.1.3 SUBJECT The SUBJECT field specifies the subject of an alert. The syntax is specified in RFC 822 [RFC822]. 3.1.4 DATE The DATE field specifies the time when the alert was generated. The syntax is specified in RFC 822 [RFC822]. 3.1.5 MESSAGE-ID The MESSAGE-ID field identifies the alert. The syntax is specified in RFC 822 [RFC822]. 3.1.5 REFERENCES The REFERENCES field identifies other alerts which this alert references. The syntax is specified in RFC 822 [RFC822] (See also "5 Threads of Alerts"). 3.2 Reused RFC 2045 Fields All fields in this section follow the syntax specified in RFC 2045 [MIME1]. 3.2.1 CONTENT-TYPE Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 6] draft-kocheisen-alert-format-00.txt 19 October 1999 The CONTENT-TYPE specifies the content type of the alert body. The syntax is specified in RFC 2045 [MIME1]. 3.2.2 MIME-VERSION The MIME-VERSION declares the version of the MIME standard used. The syntax is specified in RFC 2045 [MIME1]. 3.3 New Alert Fields 3.3.1 ALERT-DELIVERY-DATE The ALERT-DELIVERY-DATE field specifies the time at which the alert should be delivered. The receiver MAY override it. If the receiver is a device or client application, it can decide to present the alert immediately. If the receiver is a gateway the alert can be forwarded immediately. Any ATA MAY implement a queue for delayed delivery of alerts. Alerts MUST only be stored in that queue if the ALERT-DELIVERY-DATE is set in the future. Moreover, they MUST be processed by the ATA not later then the ALERT-DELIVERY-DATE indicates. When the ALERT-DELIVERY-DATE is set in the past or when it is missing, the alert must be processed immediately. Syntax: alert-deliver-date = date-time This field is optional and defaults semantically to now. It follows the date specification defined in RFC 822 [RFC822] (as extended by RFC 1123 [REQUIREMENTS] to permit 4 digits in the year field). 3.3.2 ALERT-EXPIRATION The ALERT-EXPIRATION field defines the date and time when an alert may automatically be deleted from a persistent storage or client display on the receiver. When an alert is in transit from the sender to the receiver, the ALERT-EXPIRATION field MUST NOT be used for not delivering an alert (except when the ALERT-DELIVERY-DATE is set in the future). Only the receiver may decide to delete an alert based on the ALERT-EXPIRATION date. The user or the receiver might override this field. If the ALERT-DELIVERY-DATE is set in the future and the ATA implements a delivery queue, the ATA can replace a previous alert with a new alert of the same thread (See "5 Threads of Alerts"). Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 7] draft-kocheisen-alert-format-00.txt 19 October 1999 Syntax: alert-expiration = date-time This field is optional and the receiver MAY override it. By default, an alert does not expire. The field follows the date specification defined in RFC 822 [RFC822] (as extended by RFC 1123 [REQUIREMENTS] to permit 4 digits in the year field). 3.3.3 ALERT-PRIORITY The priority field MAY be set/updated by the sender, any ATA, or by the receiver. Syntax: alert-priority = "LOWEST" / "LOW" / "NORMAL" / "HIGH" / "HIGHEST" This field is optional and defaults to "NORMAL". 3.3.4 ALERT-SENDER-URL The ALERT-SENDER-URL specifies a URL that MAY be accessed by the receiver. This allows the receiver to contact the sender upon receiving an alert in order to fetch additional information or pass control to the sender for interaction with the recipient. This mechanism is a very powerful tool with which to build integrated applications. E.g., when receiving an alert about an incoming phone call, an alert client, running on a computer, could connect to the ALERT-SENDER-URL (displayed in a browser), which then could provide the capability to transfer/forward the call to another phone number. Syntax: alert-sender-url = url ; defined in RFC 1738 [URL] [ 1*SPACE *1( ";" *SPACE "content-type=" content-type ) *1( ";" *SPACE "window-name=" word ) *1( ";" *SPACE "window-width=" window-size ) *1( ";" *SPACE "window-height=" window-size ) *1( ";" *SPACE x-other "=" word ) ] Beside the actual URL the ALERT-SENDER-URL MAY contain additional information about the content-type of the URL and preferred display settings. Display settings (window name and window size) are optional and may be overridden by the receiver. The window size is in pixel or, if followed by a "%", in percent of the display area. Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 8] draft-kocheisen-alert-format-00.txt 19 October 1999 The ALERT-SENDER-URL is optional. An alert header MAY contain multiple ALERT-SENDER-URL fields. The receiving client may decide to display/play the referred content depending on its capability or depending on user preferences. Example: ALERT-SENDER-URL: http://some.domain.name?par=a ; content-type=text/html; window-name="Hello"; window-width=200 The use of the ALERT-SENDER-URL has certain security risks for the recipient. Automatic access of a URL can reveal information considered to be private by the recipient (e.g. the fact that the recipient received the alert, or when he/she reads it). Moreover, a URL can potentially lead to remote execution of active content on the receiver. Therefore the ALERT-SENDER-URL MUST NOT be accessed without prior authorization by the recipient. 3.3.5 ALERT-TYPE The ALERT-TYPE field specifies the type of alert. This field allows alert servers and receivers to determine the nature of the alert and to process the alert accordingly. The ALERT-TYPE field is especially important with MIME parts of content type message/rfc822 because this type can represent many different types of alerts (i.e. email, voice mail, phone call, etc.). Syntax: alert-type = "DIRECT" / "EMAIL" / "FAX" / "NEWS" / "MIME" /"PHONECALL" / "VOICEMAIL" / x-other The alert type "MIME" tells an ATA or receiver to take the CONTENT- TYPE field of the alert header to decide what the nature of the alert is. This mechanism enables notification services to send alerts about events that have no predefined representation in the alert-type but conform to an acknowledged standard, e.g. calendar or to-do list alerts. The ALERT-TYPE is mandatory for reference alerts and optional for direct alerts. If the ALERT-TYPE is missing it defaults to "DIRECT". (See also "8 Representation of Alert Types" below) 4 Types of Alerts Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 9] draft-kocheisen-alert-format-00.txt 19 October 1999 The alerting format defines two different types of alerts, Direct Alerts and Reference Alerts. 4.1 Direct Alert A direct alert is a simple alert sent to an ATA or receiver. The alert header doesn't contain the ALERT-TYPE field, or the ALERT-TYPE field is set to "DIRECT". The content of the alert body can be plain text or any other MIME type. Example: Message-Id: <12345@surfcity.att.net> From: michael@att.net To: jocelyn@alerting.att.net Date: Thu, 26 Aug 1999 16:00:05 -0700 Subject: Urgent Please call me. 4.2 Reference Alert A reference alert is defined as an alert which references some other event in the network. A reference alert MUST contain the ALERT-TYPE field in the alert header and the field MUST NOT be set to "DIRECT". The alert header contains only information about the alert itself (when the alert was generated, by whom, etc.) but no information about the network event (except for the ALERT-TYPE). All information about the referenced network event is in the alert body. No assumptions about the content type of the body are made. However, some implementation guidelines on how to reference certain network events are given in section "Representation of Alert Types" below. The ALERT-TYPE field provides a hint about if and how the ATA or receiver should interpret the content of the alert body. In some cases the content type of the body (specified by the CONTENT-TYPE field in the alert header) might be enough information to determine the nature of the alert (e.g. text/calendar). However, different kinds of alerts can be represented by using the same content type (i.e. "message/rfc822"). In this case the content of the alert body provides no clue about the nature of the alert. In order to provide this information, the ALERT-TYPE field allows the sender to specify the nature of the alert (e.g. "EMAIL", "VOICEMAIL", etc.). This allows the ATA or receiver to processes the alert correctly (e.g. filtering). Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 10] draft-kocheisen-alert-format-00.txt 19 October 1999 Example: Message-Id: <12444@surfcity.att.net> From: mailserver@att.net To: jean@alerting.att.net Date: Thu, 26 Aug 1999 16:00:05 -0700 MIME-Version: 1.0 Subject: New email Alert-Type: EMAIL Content-Type: message/rfc822 Message-Id: <12345@surfcity.att.net> From: frankie@att.net To: jean@att.net Date: Thu, 26 Aug 1999 16:00:05 -0700 Subject: Check this out! Jean, Very cool site http://www.att.net Frankie 5 Threads of Alerts The alert format introduces the notion of alert threads. A thread of alerts is defined as all alerts that are related and are tagged accordingly. This allows the sender of an alert to replace a previously sent alert with a new one. The handling of threads depends on the implementation of the ATA or receiver. An ATA or receiver might replace a previously received alert by the new alert, aggregate an entire thread, etc., or it might not support threads at all. The sender of an alert MUST assume that the new alert replaces all previously sent alerts of the same thread. An ATA or receiver that wants to determine the correct sequence of the alerts within a thread MUST use the DATE field. The REFERENCES field [RFC822] is used to identify alerts of the same thread. The REFERENCES field of an alert replacing another alert of the same thread SHOULD include the msg-id [RFC822] of the first alert of the same thread. It also MAY include one or more msg-ids of other members of the same thread. Alert 1: Message-Id: Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 11] draft-kocheisen-alert-format-00.txt 19 October 1999 Alert 2: Message-Id: References: Alert 3: Message-Id: References: Alert 4: Message-Id: References: However, it is NOT RECOMMENDED to only include the msg-id of the previous alert (which is not the first alert of the thread). The previous alert might have been lost, in which case, the thread would break up. Alert 5: Message-Id: References: NOT RECOMMENDED! An ATA or receiver implementing the replacement feature SHOULD replace all alerts listed in the REFERENCES field. The sender MAY decide to delete a previously sent alert by sending a replacement alert with the ALERT-EXPIRATION field set in the past. In this case, the SUBJECT or body of the alert SHOULD contain a meaningful message in case the receiver does not implement the thread mechanism. If an alert scheduled for future delivery is received by an ATA or receiver that implements queuing, this alert will replace all queued alerts belonging to the same thread. The ALERT-DELIVERY-DATE MUST be set for future delivery otherwise it MAY not enter the queue (see "3.3.1 ALERT-DELIVERY-DATE"). The following is an example of a traffic alert service using threads to update previous alerts. The first alert informs the recipient about a traffic jam on highway 101. 20 minutes later, a second alert informs the user about the new situation. Finally, a third alert is sent that deletes all previously received alerts of the same thread. Note, the last alert contains a meaningful message, in case the receiver does not implement threads. Example: Alert 1: First alert about the traffic jam. From: baytraffic@traffic.att.net To: pierre@alerting.att.net Date: Thu, 26 Aug 1999 08:30:05 -0700 Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 12] draft-kocheisen-alert-format-00.txt 19 October 1999 Alert-Expiration: Thu, 26 Aug 1999 10:30:00 -0700 Message-Id: <12345@traffic.att.net> Subject: Backup: 101 North, Exit Willow and University Traffic jam on 101, North bound, between exits Willow Road and University Ave. Alert 2: Updating the situation. From: baytraffic@traffic.att.net To: pierre@alerting.att.net Date: Thu, 26 Aug 1999 08:50:05 -0700 Alert-Expiration: Thu, 26 Aug 1999 10:50:00 -0700 Message-Id: <66666@traffic.att.net> References: <12345@traffic.att.net> Subject: Backup: 101 North, Exit Willow 6 miles backup. Accident on 101, North bound, turned over tractor trailer, 6 miles backup from exit Willow Road, Police are on the scene. Alert 3: Removing all members of the same alert thread. From: baytraffic@traffic.att.net To: pierre@alerting.att.net Date: Thu, 26 Aug 1999 9:55:05 -0700 Alert-Expiration: Fri, 1 Jan 1999 00:00:01 -0700 Message-Id: <77777@traffic.att.net> References: <12345@traffic.att.net> Subject: Cleared: 101 North, Exit Willow Accident on 101 North, exit Willow Rd, has been cleared. 6. Phone Number Representation Some alert services use phone numbers in order to address devices rather then users. When using phone number, this document refers to the phone number specification defined by VPIM v2 [VPIM2] or any document that will obsolete VPIM v2 in the future. Example: From: +15555551234@mycompany.com 7. Implementation Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 13] draft-kocheisen-alert-format-00.txt 19 October 1999 7.1 Minimal ATA Implementation Requirement An ATA MUST implement at least the SMTP protocol for receiving alerts. 7.2 HTTP Implementation An ATA MUST use the content-type message/alert when an alert is delivered using the HTTP protocol. The posted alert consists of a standard alert header and alert body as defined in this document. Example: POST /cgi-bin/alertreceiver.cgi HTTP/1.0 Host: www.foo.com Content-type: message/alert Content-Length: 184 From: michael@att.net To: jocelyn@alerting.att.net Date: Thu, 26 Aug 1999 16:00:05 -0700 Message-id: <123@myid.com> Subject: Very Urgent Please call me as soon as possible. 8 Representation of Alert Types The alert format has several types of predefined alerts ("EMAIL", "VOICEMAIL", etc.) which represent common network events. This section defines the format of how these network events are represented in an unambiguous way allowing arbitrary ATA and receivers to process these alerts. 8.1 Email Event An alert which represents a notification about the status of an email in the network is a reference alert of type EMAIL. It consists of an alert header and a body of MIME type message/rfc822 or message/external-body [MIME2] . The content type depends on whether the alert contains the email or parts of it, or if the email is only being referenced. The alert can also consists of a multipart/mixed or Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 14] draft-kocheisen-alert-format-00.txt 19 October 1999 multipart/alternative. In this case, the body MUST contain one body part of content type message/rfc822 or message/external-body and SHOULD be the first part of the body. If the sender decides to send only parts of the entire email or just the header, an appropriate comment for the recipient SHOULD be placed where the message has been truncated. In this case, it is RECOMMENDED to include an additional MIME part of type message/external-body to allow receivers to retrieve the entire message. 8.1.1 Partial or Entire Email If the alert contains the entire email or parts of it, the body MUST be of content type message/rfc822. In case the message/rfc822 is wrapped in a multipart/* type, the message/rfc822 SHOULD be the first body part. Example: Message-Id: <12555@surfcity.att.net> From: mailserver@att.net To: jean@alerting.att.net Date: Thu, 26 Aug 1999 16:00:05 -0700 MIME-Version: 1.0 Subject: New email Alert-Type: EMAIL Content-Type: multipart/alternative; boundary=myboundary --myboundary Content-Type: message/rfc822 Message-Id: <12345@surfcity.att.net> From: frankie@att.net To: jean@att.net Date: Thu, 26 Aug 1999 16:00:05 -0700 Subject: Check this out! Jean, Very cool site http://www.att.net Frankie --myboundary Content-Type: text/html Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 15] draft-kocheisen-alert-format-00.txt 19 October 1999
From: frankie@att.net  
To: jean@att.net
Subject: Check this out!
Date: Thu, 26 Aug 1999 16:00:05 -0700


      Jean,

      Very cool site http://www.att.net

      Frankie
--myboundary-- 8.1.2 External Email The sender of an alert might decide not to include any information about the email itself but rather a reference to the message. In this case the content type of the alert (or, in case of a multipart/*, one of the body parts) SHOULD be message/external-body. RFC 2046 [MIME2] doesn't provide a standard way to access a message on a particular mail server. However, URLs provide a universal mechanism for accessing content on other servers. For example, RFC 2192 [IMAPURL] and RFC 2384 [POPURL] specify URL schemas for accessing IMAP and POP mail servers. Because of this, URLs are used to identify an external message. The URL is passed in the body of the message/external-body part as the value of the field "Content-URL:". Syntax: content-url = "Content-URL" ":" url Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 16] draft-kocheisen-alert-format-00.txt 19 October 1999 Example: Message-Id: <12666@surfcity.att.net> From: mailserver@att.net To: jean@alerting.att.net Date: Thu, 26 Aug 1999 16:00:05 -0700 MIME-Version: 1.0 Subject: New email Alert-Type: EMAIL Content-Type: message/external-body; access-type=mail-server server="jean@surfcity.att.net"; Content-URL: imap://jean@surfcity.att.net/myfolder;UID=35 Content-ID: <12345@surfcity.att.net> The use of the message/external-body type in conjunction with the CONTENT-URL field has certain security implications. In particular, a receiver SHOULD NOT automatically retrieve a message without prior permission of the user. See also the "Security Consideration" sections of the RFCs which define the "message/external-body" [MIME1] and the URL schemes for mail server access [POPURL][IMAPURL]. 8.1.3 Example of a Partial Email The following is an example of an alert about a new email where the email has been truncated by the alert generating service because of its size. Beside the partially truncated message, the sender also included an message/external-body part that references the email on a mail server. Message-Id: <12666@surfcity.att.net> From: mailserver@att.net To: jean@alerting.att.net Date: Thu, 26 Aug 1999 16:00:05 -0700 MIME-Version: 1.0 Subject: New email Alert-Type: EMAIL Content-Type: multipart/alternative; boundary=myboundary --myboundary Content-Type: message/rfc822 Message-Id: <12346@surfcity.att.net> From: frankie@att.net To: jean@att.net Date: Thu, 26 Aug 1999 16:00:05 -0700 Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 17] draft-kocheisen-alert-format-00.txt 19 October 1999 Subject: Library of Congress Jean, This email contains the first 10% of the Library of Congress as text attachments. Please read this by ... [Message truncated by Notification Service] --myboundary Content-Type: message/external-body; access-type=mail-server server="jean@surfcity.att.net"; Content-URL: pop://jean@surfcity.att.net Content-ID: <12346@surfcity.att.net> --boundary-- 8.2 Fax Event A fax event is a reference alert of type FAX. Because fax messages are very similar to email messages the same syntax is used (see "9.1 Email Event" above.). 8.3 NEWS Event A news event is represented by a reference alert of type NEWS. Because news messages are very similar to email message the same syntax is used (see "9.1 Email Event" above.). However, it is RECOMMENDED that the header information in the message/rfc822 header part is provided in the USENET format as specified in RFC 1036 [USENET]. Example: Message-Id: <12345@newscenter.att.net> From: master@newscenter.att.net To: frankie@alerting.att.net Date: Thu, 26 Aug 1999 16:00:05 -0000 MIME-Version: 1.0 Subject: Alert-Type: NEWS Content-Type: multipart/rfc822 From: news@news.att.net Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 18] draft-kocheisen-alert-format-00.txt 19 October 1999 Date: Thu, 26 Aug 1999 15:55:10 GMT Subject: Good news Expires: Sun, 26 Aug 1999 00:00:00 GMT Message-ID: Organization: AT&T Labs, Menlo Park, CA, USA Path: wherever.net!this.net!came.net!from.net Newsgroups: news.misc Distribution: World Lines: 1 No bad news today. 8.4 MIME Event Setting the ALERT-TYPE to MIME tells the ATA or receiver to use the CONTENT-TYPE field to identify the nature of the alert. Examples for a MIME alert are Calendar and To-Do events. The content type text/calendar specifies that the body contains an iCalendar object as defined by RFC 2445 [ICALENDAR]. Example: To: jsmith@host1.com From: jdoe@host1.com Mime-Version:1.0 Message-Id: Alert-Type: MIME Content-Type: text/calendar; method=REQUEST; charset=US-ASCII BEGIN:VCALENDAR METHOD:xyz VERSION:2.0 PRODID:-//ABC Corporation//NONSGML My Product//EN BEGIN:VEVENT DTSTAMP:19970324T1200Z SEQUENCE:0 UID:uid3@host1.com ORGANIZER:MAILTO:jdoe@host1.com ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host1.com DTSTART:19970324T123000Z DTEND:19970324T210000Z CATEGORIES:MEETING,PROJECT CLASS:PUBLIC SUMMARY:Calendaring Interoperability Planning Meeting DESCRIPTION:Discuss how we can test c&s interoperability using iCalendar and other IETF standards. LOCATION:LDB Lobby Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 19] draft-kocheisen-alert-format-00.txt 19 October 1999 ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/ conf/bkgrnd.ps END:VEVENT END:VCALENDAR 8.5 Phone Call Event An alert which represents a notification about the status of a phone call is a reference alert of type PHONECALL. The intent of defining a phone call event is not to implement a comprehensive signaling protocol, but to provide some basic information about the status of a phone call. The goal is to provide information about who is calling whom and when did the status of that phone call change. This document defines a way how the message/rfc822 content type is being used to specify phone call alerts. The header of message/rfc822 body part contains the following fields The FROM field containing the phone number of the calling party. The TO field providing information about the party that is being called. The TO field can contain multiple callees in case a conference call is in progress. The DATE field specifying the time when the phone event occurred. (Can differ from the DATE in the alert header.) The CALL-STATUS field specifying the status of the call. The syntax of the CALL-STATUS field is defined below. Syntax: call-status-field = "Call-Status" ":" call-status call-status = "RINGING" / "ONGOING" / "TERMINATED" / x-other Call termination is being signaled by setting the CALL-STATUS field to "TERMINATED". In this case the FROM field and the TO field MUST contain all parties that participated in the phone call just before it ended. This allows the ATA or receiver to apply the same filters as during the phone call. The following alert is an example of a 3-way conference call. Caller 1-555-666-1234 established a conference call to callees 1-555-777-4321 and 1-555-777-8765. Example: Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 20] draft-kocheisen-alert-format-00.txt 19 October 1999 From: telecom@platform.att.net To: amy@alerting.att.net Date: Thu, 26 Aug 1999 08:30:05 -0700 Message-Id: <12345@platform.att.net> Alert-Sender-Url: http://platform.att.net?cmd=callmanager&msg=12345 Alert-Priority: HIGH Alert-Type: PHONECALL Content-Type: message/rfc822 From: +15556661234@platform.att.net To: +15557774321@platform.att.com, +15557778765@platform.att.com Date: Thu, 26 Aug 1999 08:30:04 -0700 Call-Status: ONGOING Subject: Phone call in progress Dummy body. 8.6 Voice Mail Event A voice mail event is represented by a reference alert of type VOICEMAIL. Because voice mail is very similar to email the same syntax is applied (see "9.1 Email Event" above.). The following is an example of an alert where the entire voice mail is attached in VPIM [VPIM2] format. It is up to the receiver to decide how much of the content will be used. Example: To: recipient@alerting.att.net From: voicemail@platform.mycompany.com Date: Mon, 23 Aug 1999 10:20:21 -0700 Alert-Type: VOICEMAIL Message-Id: <12345@platform.mycompany.com> Content-Type: message/rfc822 To: +19725551212@vm1.mycompany.com To: +16135551234@VM1.mycompany.com From: "Parsons, Glenn" <+12145551234@VM2.mycompany.com> Date: Mon, 23 Aug 1999 10:20:20 -0700 MIME-Version: 1.0 (Voice 2.0) Content-type: Multipart/Voice-Message; Version=2.0; Boundary="MessageBoundary" Content-Transfer-Encoding: 7bit Message-ID: 123456789@VM2.mycompany.com Sensitivity: Private Importance: High Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 21] draft-kocheisen-alert-format-00.txt 19 October 1999 --MessageBoundary Content-type: Audio/32KADPCM Content-Transfer-Encoding: Base64 Content-Disposition: inline; voice=Originator-Spoken-Name Content-Language: en-US Content-ID: part1@VM2-4321 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Name data) fgdhgddlkgpokpeowrit09== --MessageBoundary Content-type: Audio/32KADPCM Content-Transfer-Encoding: Base64 Content-Description: Brand X Voice Message Content-Disposition: inline; voice=Voice-Message; filename=msg1.726 Content-Duration: 25 iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq (This is a sample of the base64 message data) zb8tFdLTQt1PXj u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9== --MessageBoundary Content-type: text/directory; charset=us-ascii; profile=vCard Content-Transfer-Encoding: 7bit BEGIN:VCARD N:Parsons;Glenn;;Mr.; EMAIL;TYPE=INTERNET:+12145551234@VM2.mycompany.com TEL:+1-217-555-1234 SOUND;TYPE=32KADPCM;ENCODING=URI: CID: REV:19951031T222710Z VERSION: 3.0 END:VCARD --MessageBoundary-- 9 Examples of an Advanced Alert The following is a more advanced example of a thread of alerts. A fictitious telecom platform generates an alert about an incoming phone call to 1-555-777-4321 (office). The alert priority is high since the alert recipient has to act quickly. The alert is received by the recipient on an alert client application that runs on the computer at home. The application recognizes the ALERT-SENDER-URL and Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 22] draft-kocheisen-alert-format-00.txt 19 October 1999 contacts the telecom platform. The telecom platform provides the recipient with the ability to forward the call at home. A second alert informs the client application about the forwarded phone call, and a third alert that the call was answered. At the end of the phone call the telecom platform sends again an alert which signals the end. It will automatically expire after 5 minutes. Example: Alert 1: The phone in the office is ringing From: telecom@att.net To: amy@alerting.att.com Date: Thu, 26 Aug 1999 08:30:05 -0700 Message-Id: <12345@att.net> Alert-Sender-Url: http://att.net?cmd=phonemanager&msg=12345 Alert-Priority: HIGH Alert-Type: PHONECALL Subject: Phone call Content-Type: message/rfc822 From: +15556661234@att.net To: +15557774321@att.net Date: Thu, 26 Aug 1999 08:30:04 -0700 Call-Status: RINGING Subject: Phone call from 1-555-666-1234 Content-Type: audio/x-special-ring RING! RING! RING! Alert 2: Replaces previous alert. Call was forwarded at home. From: telecom@att.net To: amy@alerting.att.com Date: Thu, 26 Aug 1999 08:30:15 -0700 Message-Id: <66666@att.net> References: <12345@att.net> Alert-Priority: HIGH Alert-Type: PHONECALL Subject: Call was forwarded at home Content-Type: message/rfc822 From: +15556661234@att.net To: +15558884321@att.net Date: Thu, 26 Aug 1999 08:30:14 -0700 Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 23] draft-kocheisen-alert-format-00.txt 19 October 1999 Call-Status: RINGING Subject: Forwarding call to 1-555-888-4321 Alert 3: Replaces previous alert. Call was answered at home. From: telecom@att.net To: amy@alerting.att.com Date: Thu, 26 Aug 1999 08:30:25 -0700 Message-Id: <66666@att.net> References: <12345@att.net> Alert-Priority: HIGH Alert-Type: PHONECALL Subject: Call was forwarded at home Content-Type: message/rfc822 From: +15556661234@att.net To: +15558884321@att.net Date: Thu, 26 Aug 1999 08:30:22 -0700 Call-Status: ONGOING Subject: Call answered Alert 4: Replaces previous alert. Call terminated. From: telecom@att.net To: amy@alerting.att.com Date: Thu, 26 Aug 1999 08:42:05 -0700 Message-Id: <67899@att.net> References: <12345@att.net> Alert-Priority: HIGH Alert-Type: PHONECALL Alert-Expiration: Thu, 26 Aug 1999 08:47:05 -0700 Subject: Call terminated Content-Type: message/rfc822 From: +15556661234@att.net To: +15558884321@att.net Date: Thu, 26 Aug 1999 08:42:04 -0700 Call-Status: TERMINATED Subject: Call terminated 5 cents were billed to your account for using the forwarding features. Thank you for using AT&T. 10 Security Considerations Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 24] draft-kocheisen-alert-format-00.txt 19 October 1999 The alert format is mostly based on the messaging format defined by RFC 822 and RFC 2045. The alerting format does not define any mechanisms for authentication, verification or encryption. Anybody can send alerts to an ATA or receiver pretending to be somebody else. In this sense sending alerts has a similar level of security as email. Implementors should pay special attention to the security implications of any content types that can cause the remote execution of any actions on the receiver. Security considerations in conjunction with the ALERT-SENDER-URL are discussed in section "ALERT-SENDER-URL". Security considerations in conjunction with message/external-body are discussed in section "External Email". 11 Syntax This section contains the complete BNF grammar for all the syntax specified by this document. By itself, however, this grammar is incomplete. It refers by name to several syntax rules that are defined by RFC 822, RFC 2045, RFC 1123, and RFC1738. Rather than reproduce those definitions here, and risk unintentional differences between the specifications, this document simply refers the reader to the original document for the remaining definitions. Wherever a term is undefined, it refers to the RFC 822 definition. extension-field = "Alert-Delivery-Date" ":" date-time / "Alert-Expiration" ":" alert-expiration / "Alert-Priority" ":" alert-priority / "Alert-Sender-Url" ":" alert-sender-url / "Alert-Type" ":" alert-type alert-delivery-date = date-time alert-expiration = date-time alert-priority = "LOWEST" / "LOW" / "NORMAL" / "HIGH" / "HIGHEST" alert-sender-url = url [ 1*SPACE Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 25] draft-kocheisen-alert-format-00.txt 19 October 1999 *1( ";" *SPACE "content-type=" content ) *1( ";" *SPACE "window-name=" word ) *1( ";" *SPACE "window-width=" window-size ) *1( ";" *SPACE "window-height=" window-size ) *1( ";" *SPACE x-other "=" word ) ] alert-type = "DIRECT" / "EMAIL" / "FAX" / "NEWS" / "MIME" /"PHONECALL" / "VOICEMAIL" / x-other call-status-field = "Call-Status" ":" call-status call-status = "RINGING" / "ONGOING" / "TERMINATED" / x-other content = content-url = "Content-URL" ":" url date-time = DIGIT = ; msg-id = SPACE = url = window-size = 1*DIGIT [ "%" ] word = x-other = "x-" 1word 12 References [ICALENDAR] F. Dawson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, Lotus, November 1998. [IMAPURL] C. Newman, "IMAP URL Scheme", Innosoft, RFC 2191, September 1997. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 26] draft-kocheisen-alert-format-00.txt 19 October 1999 [MIME1] N. Freed, "Multipurpose Internet Mail Extensions, (MIME) Part One", RFC 2045, Innosoft, November 1996. [MIME2] N. Freed, "Multipurpose Internet Mail Extensions, (MIME) Part Two: Media Types", RFC 2046, Innosoft, November 1996. [POP3] M. Rose, "Post Office Protocol - Version 3", RFC 1081, TWG, November 1988. [POPURL] R. Gellens, "POP URL Scheme", RFC 2384, Qualcomm Inc., August 1998. [REQUIREMENTS] R. Braden, "Requirements for Internet Hosts -- Application and Support", RFC 1123, October 1989. [RFC822] David H. Crocker, "Standard for the format of ARPA Internet text messages", RFC 822, University of Delaware, August 1982. [URL] T. Berners-Lee, "Uniform Resource Locators (URL)", RFC 1738, CERN, December 1994. [USENET] M. Horton, R. Adams, "Standard for Interchange of USENET Messages", AT&T Bell Laboratories, RFC 1036, December 1987. [VPIM2] G. Vaudreuil, "Voice Profile for Internet Mail - version 2", RFC 2421, Lucent Technologies, September 1998. 13 Contact Address Michael Kocheisen AT&T Labs 75 Willow Road Menlo Park, CA 94025, USA email: kocheisen@att.com Kocheisen, Cloutier, McNeil, Rioux, Tessier [Page 27]