Internet Draft Greg Vaudreuil Expires in six months Lucent Technologies Obsoletes: RFC 1911, RFC 2423 Glenn Parsons & Marty Cohen Nortel Networks February 26, 1999 MIME Sub-type Registrations for unified messaging Status of this Memo This document is an Internet Draft. 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 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 a "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Overview This document describes the registration of the MIME sub-types multipart/voice-message and multipart/fax for use with the Voice Profile for Internet Mail (VPIM) for Unified Messaging. It also introduces the primary content type concept. A further description of usage can be found in the VPIM v3 specification. The VPIM WG home page is: http://www.ema.org/vpim Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 1] Internet Draft VPIM UM February 26, 1999 1. Introduction This document describes the registration of the MIME sub-types multipart/voice-message and multipart/fax-message for use with the Voice Profile for Internet Mail (VPIM) for Unified Messaging.. It also introduces the primary content type concept. A further description of usage can be found in the VPIM v3 specification [VPIM3]. This document revises earlier sub-type registrations in RFC 2423 [V-MSG] for [VPIM2] and RFC 1911 [VPIM1]. 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 [REQ]. 2. VPIM v3 Scope The VPIM v3 specification defines a profile of the Internet Mail protocols for use between unified or universal platforms. These platforms are intended to be full Internet Mail platforms with the ability to handle voice and fax media as well. Historically, voice, fax and email have existed on separate systems. Recently, email profiles have been created for both voice [VPIM2] and fax [IFAX] but these are restrictive to only that media and special-purpose computer systems they were intended for. VPIM v3 lifts these restrictions, but to facilitate efficient unified messaging benefits a primary content type semantic must be provided by multipart/voice-message and multipart/fax-message. 3. Primary Message Type In the early days of Internet Messaging, there was only one media type - text, and a message simply contained one text body. When the user viewed the text, the message was unequivocally "read". Today, systems can send and receive messages containing many different media (as different content types within a multipart/mixed). For example, a message may contain text with voice, fax and spreadsheet attachments. It may appear that all the media are given equal importance, but in fact, the text is given precedence. A typical email client may display the text in a preview pane. And when the message is "opened", the text will be displayed in the main window and the attachments will be iconified. Once the text has been displayed (within the preview pane, or upon opening the message), the client determines that the message has been "read", even though none of the attachments have been "seen". Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 2] Internet Draft VPIM UM February 26, 1999 This behaviour is particularly problematic if the sender has requested that a disposition notification (MDN) be issued when the message is viewed. The sender cannot know if any or all of the attachments have been viewed. The mechanism is not helpful if the sender is particularly interested in the disposition of a particular attachment - a fax attachment, for example. A solution to this problem is to introduce the concept of a primary message type. A multipart message has associated primary content type semantics. The primary content type of a multipart/voice-message is voice, the primary content type of a multipart/fax-message is fax, and so on. A client supporting the primary message type concept will not declare a message as "read" until the body part containing the primary media has been "seen". Only when this attachment has been "seen" will a client issue a requested MDN. It may be apparent that most mail clients currently consider the primary content type of a multipart/mixed message to be text/*. New mail clients may interpret the multipart/* content type and display the message appropriately. For example, upon selecting a multipart/fax-message, the client may display the fax attachment in a preview pane. 4. Unified Messaging Though many systems can send and receive messages containing many different media (as different content types within a multipart/mixed), all the media are given an equal importance. That is, a message with a voice, fax and spreadsheet attachment may be sent from a system to recipients on many different systems (with different capabilities). If the message was sent to a voice messaging system, and the primary content of the message was the voice Ð the fax and spreadsheet were merely FYI Ð the message would not be delivered because the other contents could not be rendered. However, if the message was identified as being primarily a voice message, the receiving voice-only system could detect that and deliver the voice but discard the informational attachments. Support of primary content type will differentiate true "unified messaging systems" from the "media-agnostic" messaging systems widely deployed today. Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 3] Internet Draft VPIM UM February 26, 1999 A "media-agnostic" messaging system is capable of rendering many body types- text, audio, fax, spreadsheets, etc., but text always takes precedence. A true "unified messaging system" will recognize the message type (text, voice, fax, etc.) and may indicate this to the user by displaying a differentiating icon. When a message is selected, appropriate action is taken for the type of message. For example, the fax content is immediately displayed, the audio player is launched and the voice is immediately played, and so on. The unified messaging system will change the status of a message from unread to read once the primary content has been rendered for the user. For example, this means that a voice message is "read" once the voice has been played, even if text annotation or an attached fax has not been seen. 5. Disposition Notification The message notification mechanism is described in [MDN]. The MDN is generated by the client (when requested in the message) upon disposition of the message. Examples of dispositions include: displayed, deleted, forwarded, or otherwise "processed". The MDN mechanism does not provide semantics enabling the sender of the message to determine with certainty which body parts were actually accessed by the recipient. The MDN mechanism does not allow the user to tag a specific body part for inclusion in the disposition report. As we have seen, most likely the user will be notified when the user has seen the text, even though a fax attachment may be the most important content. A client supporting primary message type will also provide the missing MDN semantics. Clearly, the client should only generate the disposition report when the primary message content has been seen, etc. For example, an MDN report when the voice content of a multipart/voice-message has been played, or when the fax content of a multipart/fax-message has been displayed or printed. 6. Discard Rules Existing email servers support messages containing any arbitrary content type. The email clients may or may not be capable of processing message attachments. The sender of the message will be unaware that an attachment could not be rendered unless explicitly informed by the recipient. Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 4] Internet Draft VPIM UM February 26, 1999 The VPIM v2 specification, on the other hand, requires different semantics. Recognizing that legacy voicemail systems do not support text, the specification does not allow text within a multipart/voice- message. However, the specification allows inclusion of an image/tiff attachment. If the recipient system does not support fax, the entire message must be rejected. These semantics are insufficient because they do not recognize that a message has a primary content. A more appropriate behaviour can now be defined: If the receiver does not support the primary message type, reject the entire message and generate an appropriate non- delivery report (DSN). For example, if a VPIM v3 system receives a message containing audio content encoded with an unsupported codec, the entire message must be rejected. If the receiver supports the primary message type, the message must be accepted. If the sender requested positive acknowledgment, the receiver must generate a positive delivery report. If the receiver accepts a message but does not support the media type of some attachments, the attachments may be deleted. However, if attachments are deleted, the recipient should be appropriately notified. For example, consider an Internet Fax device receiving a message with an audio/* body. The server could add notification to the cover page that there was an audio attachment that could not be played. If the sender has requested positive acknowledgment, the delivery report must contain an appropriate return code indicating some content was not delivered. If positive acknowledgement was not requested, a negative acknowledgement report must be returned containing an appropriate return code indicating that some content was not delivered. 7. Primary Media Content Types , As described earlier, the use of primary content types will allow unified messaging systems to view the message as intended (e.g., as a voice message using a plug-in). This could give the user the voice message (or fax message) interface Ð which would likely be slightly different than the generic view. Described below are two content types intended as a wrapper to indicate the semantic of primary content type. When used they MUST be the top level content of that message.. Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 5] Internet Draft VPIM UM February 26, 1999 7.1 multipart/voice-message The MIME sub-type multipart/voice-message is re-defined to hold an audio content and any number of other content type as described in [VPIM3]. Essentially, the sub-type provides a simple wrapper that easily identifies the entire content as being the components of a single voice message. The sub-type is similar in semantics and syntax to multipart/mixed, as defined in [MIME2]. The difference introduced in this revision is that the primary content of this multipart is voice (audio/*). As such, it may be safely interpreted as a multipart/mixed by systems that do not understand the sub-type (only the identification as being a voice message would be lost). If a receiving system downgrades an incoming message (i.e., drops non- voice contents for delivery), an appropriate non-delivery message MUST be sent to the originator indicating that contents were deleted to deliver the primary voice content. A notification SHOULD also be sent to the recipient indicating that contents were deleted to deliver the primary voice message. In addition to the MIME required boundary parameter, a version parameter is also REQUIRED for this sub-type. This is to distinguish this refinement of the sub-type from the previous definition in [VPIM1] and [V-MSG]. The value of the version parameter is "3.0" if the content conforms to the requirements of [VPIM3]. The default version value (when the parameter is missing) is 1, indicating the content conforms to the requirements of [VPIM1]. Note: [VPIM2] describes the restriction that only specific media types applicable to voice messaging (audio/*, image/*, message/rfc822 and application/directory), are valid Ônext-levelÕ contents of this sub- type (when version=2.0). 3.2 multipart/fax-message The MIME sub-type multipart/fax is defined to hold a fax image as described in [IFAX] and any number of other content types. Essentially, the sub-type provides a simple wrapper that easily identifies the entire content as being the components of a single fax message. The sub-type is similar in semantics and syntax to multipart/mixed, as defined in [MIME2]. The difference is that the primary content of this multipart is fax (image/tiff). As such, it may be safely interpreted as a multipart/mixed by systems that do not understand the sub-type (only the identification as being a fax message would be lost). Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 6] Internet Draft VPIM UM February 26, 1999 If a receiving system downgrades an incoming message (i.e., drops non- fax contents for delivery), a appropriate non-delivery message MUST be sent to the originator indicating that contents were deleted to deliver the primary fax content. A notification SHOULD also be sent to the recipient indicating that contents were deleted to deliver the primary fax message. 4. IANA Registration 4.1 multipart/voice-message To: ietf-types@iana.org Subject: Registration of MIME media type multipart/voice-message MIME media type name: multipart MIME subtype name: voice-message Required parameters: boundary, version The use of boundary is defined in [MIME2] The version parameter contains the value "3.0" if the enclosed content conforms to [VPIM3]. The version parameter contains the value "2.0" if the enclosed content conforms to [VPIM2]. The absence of this parameter indicates conformance to the previous version defined in RFC 1911 [VPIM1]. Optional parameters: none Encoding considerations: 7bit, 8bit or Binary Security considerations: This definition identifies the content as being a voice message. In some environments (though likely not the majority), the loss of the anonymity of the content may be a security issue. Interoperability considerations: Systems developed to conform with [VPIM1] and [VPIM2] may not conform to this registration. Specifically, there may be unrenderable content types received, in this case the recipient system should NDN the message. Also the VPIM v1 positional identification will likely be lost. Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 7] Internet Draft VPIM UM February 26, 1999 Published specification: This document [VPIM2] [VPIM3] Applications which use this media type: Primarily unified messaging Additional information: Magic number(s): ? File extension(s): .VPM Macintosh File Type Code(s): VPIM Person & email address to contact for further information: Glenn W. Parsons Glenn.Parsons@NortelNetworks.com Gregory M. Vaudreuil GregV@Lucent.Com Intended usage: COMMON Author/Change controller: Glenn W. Parsons & Gregory M. Vaudreuil 4.2 multpart/fax-message To: ietf-types@iana.org Subject: Registration of MIME media type multipart/fax-message MIME media type name: multipart MIME subtype name: fax-message Required parameters: boundary, version The use of boundary is defined in [MIME2] The version parameter that contains the value "1.0" if enclosed content conforms to [IFAX]. Optional parameters: none Encoding considerations: 7bit, 8bit or Binary Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 8] Internet Draft VPIM UM February 26, 1999 Security considerations: This definition identifies the content as being a fax message. In some environments (though likely not the majority), the loss of the anonymity of the content may be a security issue. Interoperability considerations: Systems developed strictly to conform with [IFAX] may not be able to receive multipart/fax-message (though this should be treate as multipart/mixed). In this case, interoperability would fail. Published specification: This document [IFAX] [VPIM3] Applications which use this media type: Primarily fax capable unified messaging systems. Additional information: Magic number(s): ? File extension(s): .FAX Macintosh File Type Code(s): FAX Person & email address to contact for further information: Glenn W. Parsons Glenn.Parsons@NortelNetworks.com Gregory M. Vaudreuil GregV@Lucent.Com Intended usage: COMMON Author/Change controller: Glenn W. Parsons & Gregory M. Vaudreuil Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 9] Internet Draft VPIM UM February 26, 1999 5. AuthorsÕ Addresses Glenn W. Parsons Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada Phone: +1-613-763-7582 Fax: +1-613-763-4461 Glenn.Parsons@NortelNetworks.com Marty S. Cohen Nortel Networks 522 University Ave. Toronto, Ontario, M5G 1W7 Canada Phone: +1-416-597-7264 martyc@nortelnetworks.com Gregory M. Vaudreuil Lucent Technologies 17080 Dallas Parkway Dallas, TX 75248-1905 United States Phone/Fax: +1-972-733-2722 GregV@Lucent.Com 6. References [MIME2] N. Freed and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types ", RFC 2046, Innosoft, First Virtual, Nov 1996. [MIME4] N. Freed and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, Innosoft, First Virtual, Nov 1996. [VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC 1911, Feb 1996. [VPIM2] Greg Vaudreuil and Glenn Parsons, "Voice Profile for Internet Mail - version 2", RFC 2026, September 1998. [VPIM3] Work in Progress, "Voice Profile for Internet Mail - version 3", February 1999. [V-MSG] Greg Vaudreuil and Glenn Parsons, "VPIM Voice Message: MIME Sub-type Registration", RFC 2423, September 1998. Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 10] Internet Draft VPIM UM February 26, 1999 [REQ] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels" ,RFC 2119, March 1997. [IFAX] Toyoda et al., "A Simple Mode of Facsimile Using Internet Mail", RFC 2305, March 1998. [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for Delivery Status Notifications", RFC 1894, 01/15/1996. [MDN] Fajman, Roger, "An Extensible Message Format for Message Disposition Notifications" RFC 2298, March 1998 7. Full Copyright Statement Copyright (C) The Internet Society (1999). 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 implmentation 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Vaudreuil, Parsons & Cohen Expires 8/26/99 [Page 11]