draft-ema-vpim-imap-01.txt Internet Draft Glenn Parsons Expires in six months Nortel Networks June 23, 1999 IMAP Voice Extensions 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. 1. Abstract This document is an overview of proposals for various extensions to IMAP to meet the requirements of voice mail systems. The topics included are - Binary Attachment transfer - External Reference - Alternate Codec Request - Streaming audio attachments - Message length Indicator - Body part read indicator 2. Overview Unified messaging' requires that systems are capable of sending and receiving each of several different message types. Typical unified messaging systems today consolidate fax messages, voice messages and email messages into a single system. There are certain requirements or restrictions that a voicemail or fax system has over those of electronic mail systems. For example, voicemail must be able to be accessed using a telephone. As the IMAP base specification was defined without concern for voice messaging, this document proposes these extensions to IMAP to meet the requirements of servers that handle voice messages. Parsons Expires 12/23/99 [Page 1] Internet Draft IMAP Voice June 23, 1999 3. Introduction This Internet Draft summarizes the proposed extensions as discussed at the IMAP-VOICE informal BOF at IETF, Orlando, December 1998 and includes modifications based on comments from the IMAP and IMAP-VOICE lists. The intent of this draft is to document the options and therefore facilitate discussions on the IMAP and IMAP-VOICE lists. It is envisaged that separate drafts will describe each extension option chosen. IMAP-VOICE is a BOF for discussion of extensions to IMAP4 in support of voice messaging applications, and the standardization of these in the IETF. For more information see http://www.imc.org/ietf-imap-voice/ Voice messaging transport over Internet Mail is defined by VPIM v2 (RFC 2421)[1]. For more information see http://www.ema.org/vpim/. 3.1 Conventions Used in this Document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [2]. 4. Binary Attachment Header Since VPIM optionally supports binary attachments, and since it may be beneficial for the client not to decode base64 encoded audio, it is desirable to have a method of retrieving binary body parts in IMAP. Note that this would be nice to have, however it is not needed for voice messaging. IMAP4rev1 Servers that support the transfer of binary attachments MUST list the keyword BINARY in their CAPABILITY response. Suggestions for accomplishing this are as follows. The favoured option is 4.2, closely followed by 4.4. 4.1 A DATA suffix inside a FETCH BODY[] construct Its syntax would be similar to that of HEADER.FIELDS as described in IMAP4rev1 [3]. The DATA part specifier MUST be prefixed by one or more numeric part specifiers. C: abc FETCH 1 (BODY[1.2.DATA(ENCODING BINARY)]) Parsons Expires 12/23/99 [Page 2] Internet Draft IMAP Voice June 23, 1999 The keyword ENCODING selects encoding as defined in the MIME Content-Transfer-Encoding Header Field. [4] "ENCODING BINARY" SHOULD request that the server not encode the binary into base64 or to decode the base64 back into binary, if already encoded. 4.2 A BINARY part specifier to the FETCH command C: abc FETCH 1 BODY[x.y.BINARY] This provides part x.y as a literal string containing data with no transfer encoding, pure binary data. BINARY is only permitted for leaf body parts, not for headers and not for composite body parts. 4.3 A new command that lists client capabilities, CCAPABILITY or a set of parameters for the CAPABILITY command. 4.3.1 S: CCAPABILITY C: CCAPABILITY BINARY 4.3.2 C: CAPABILITY BINARY FOOBAR S: CAPABILITY IMAP4rev1 BINARY FOOBAR 4.4 A new DECODE command The advantage of this is it can be implemented as independent code. C: tag DECODE BINARY BODY[1.2]{...} S: *1 DECODE BINARY BODY[1.2]{...} ...data... 4.5 A BFETCH command/response which is identical to FETCH except that it always removes content-transfer-encodings when a leaf body part is fetched. 5. External Reference To meet the requirements of voicemail systems, there is a need to support external reference, such as using a telephone for playback of voice messages. IMAP4rev1 servers that support the selected method for external reference MUST list the keyword EXTERNAL in their CAPABILITY response. Three suggestions of how this can be accomplished are as follows. The favoured option for External Reference is 5.2: 5.1 Use of an external reference mechanism requires split client support for Real Time Streaming Protocol (RTSP) as well as IMAP. Parsons Expires 12/23/99 [Page 3] Internet Draft IMAP Voice June 23, 1999 If using an external mechanism for playback, implementations may use RTSP as described in RFC 2326 [5], as the control protocol from the client to a proxy server. (Which could make the outcall to the phone) 5.2 A new optional keyword TO in the DATA part specifier, as described in 4.1, is accompanied by URL for which to send the data. The URL begins with a protocol. C: abc FETCH 1 (BODY[1.2.DATA(TO "rtp:155.5.1.23:4567")]) 5.3 IMAP URLs can be used to reference the message on the IMAP server as described in the IMAP URL Scheme [6]. The IMAP URL for a specific message or message part has the following form: imap:///[uidvalidity][isection] 6. Alternate Codec Request Clients today are using many different types of codecs. Because of this, there is a desire to have the server transcode and present the message in the appropriate codec for that client. IMAP4rev1 servers that support the transcoding of alternate codecs SHOULD advertise the available codecs in response to the CAPABILITY command. There are several suggestions for accomplishing this with the favoured option being 6.4: 6.1 The receiving IMAP Server should create multipart/alternative on reception with support for 'n codecs' where 'n codecs' are the codecs supported at that server. The client would then have the option of choosing the codec that it supports. 6.2 Optional keyword TYPE in the DATA suffix (as described in 4.1), if present, requests conversion of the content into the specified type. C: abc FETCH 1 (BODY[DATA(ENCODING BINARY TYPE("AUDIO" "GSM"))]) If the server can't accomplish the conversion, the FETCH fails. 6.3 As discussed in section 4.3, a client capabilities command/response that lists the preferred codec, or the supported codecs of the client. 6.3.1 S: CCAPABILITY C: CCAPABILITY GSM FOOBAR 6.3.2 C: CAPABILITY GSM FOOBAR S: CAPABILITY IMAP4rev1 GSM FOOBAR Parsons Expires 12/23/99 [Page 4] Internet Draft IMAP Voice June 23, 1999 6.4 New DECODE command, as opposed to modifying the FETCH command C: abc DECODE BINARY BODY[1.2(TYPE("AUDIO" "GSM")] 7. Streaming Audio Attachments Streaming is needed in such cases of large audio attachments, small clients, slow links to allow the user to listen to the message as it is being downloaded, rather than having to download the whole message first. One suggestion for accomplishing this is: 7.1 The streaming of audio attachments can be done using windowing. FETCH BODY[]<> Some issues concerning streaming by windowing are - latency - no set window size. 8. Message Length Indicator In the cases of large attachments, small clients and slow links there is also a need for the client to see the length of the message in a suitable format before opening it. A message length indicator suitable for voicemail and fax should indicate the length of the message using number of seconds for a voice message and using number of pages for a fax message. The client MUST support the chosen method. There are three suggested methods and among them, 8.3 is favoured: 8.1 MIME Header Content-Duration as described in RFC 2424 [7] For fax messages a new MIME Header, Content-Page-Length, would be defined, similar to Content-Duration with the exception that number of pages would be specified, rather than number of seconds. (e.g. Content-Page-Length:3). This would be created at originator. 8.2 FETCH item USERSIZE similar to FETCH items described in IMAP4rev1 [3]. This would be created at reception. 8.2.1 USERSIZE is a non-negative number. Its meaning depends on document type. C: abc FETCH 1:2 (USERSIZE) S: *1 FETCH (12) S: *2 FETCH (57) S: abc FETCH completed. 8.2.2 USERSIZE is a pair of number and unit. There is a small set of unit tokens. Parsons Expires 12/23/99 [Page 5] Internet Draft IMAP Voice June 23, 1999 C: abc FETCH 1:2 (USERSIZE) S: *1 FETCH (12 pages) S: *2 FETCH (57 seconds) S: abc FETCH completed. 8.2.3 USERSIZE is a sequence of pairs, in case something extends in more than one unit. C: abc FETCH 1:2 (USERSIZE) S: *1 FETCH (12 lines) S: *1 FETCH (57 pages 6 hours) S: abc FETCH completed. Servers that support USERSIZE SHOULD list the USERSIZE capability in response to the CAPABILITY command. 8.3 Message length indicated as a parameter of an existing Header Field [4]. This would be created at the source. This method would allow the message length to be passed to the client by default. 8.3.1 Content-Type Header Field Content-Type=audio/*; length=50 Content-Type=image/tiff; pages=3 8.3.2 Subject Header Field Subject=Voice Message (0:04) Subject=Fax Message (3) The advantage of the subject field is that it is automatically displayed to the user. 9. Body Part Read Indicator With the use of multipart messages there should be a separate BODY PART READ indicator for each body part or, at least, to only indicate READ when the primary body part has been read. There are two suggested methods. The favoured method is 9.1. IMAP4rev1 servers that support body part read indicators SHOULD list the keyword SEEN-BY-PART in response to the CAPABILITY command. 9.1 \SEEN per BODY PART For example, if a client retrieves the text part of a message without looking at the audio attachment, the indicator would show that only the text part had been read and not the entire message. 9.2 \SEEN only after Primary Message Type has been opened. Primary Message Type is discussed in VPIM Unified Message [8]. In the case of multiple attachments the \SEEN flag would be set after the first attachment of the primary content type has been opened. For example, if the primary content type is multipart/voice-message, Parsons Expires 12/23/99 [Page 6] Internet Draft IMAP Voice June 23, 1999 the \SEEN flag would be set after the first voice message is opened. This could be the spoken name of the sender or the spoken subject as opposed to the actual voice message. 10. References [1] Vaudreuil, G., Parsons, G., "Voice Profile for Internet Mail - version 2", RFC 2421, September 1998. [2] Bradner, S., "Key Words for use in RFCs To Indicate Requirement Levels", RFC 2119, March 1997. [3] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 2060, December 1996. [4] Freed, N., Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [5] Schulzrinne, H., Rao, A., Lanphier, R., " Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [6] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997 [7] Vaudreuil, G., Parsons, G., "Content Duration MIME Header Definition", RFC 2424, September 1998. [8] Parsons, G., Cohen, M., Vaudreuil, G., "VPIM Unified Message MIME Sub-Type Registration", , Work In Progress. 11. Security Considerations TBD 12. Author's Address Glenn W. Parsons Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Phone: +1-613-763-7582 Fax: +1-613-763-4461 Email: gparsons@nortelnetworks.com 13. Acknowledgements Cheryl Kinden assisted in the preparation of this document in summarizing IMAP-VOICE BOF meeting notes, email comments (notably from Mark Cripin, Jutta Degener, John Gardiner Myers and Chris Newman) and comments from the IMAP Mailing List. Parsons Expires 12/23/99 [Page 7] Internet Draft IMAP Voice June 23, 1999 14. 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 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 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." Parsons Expires 12/23/99 [Page 8]