Internet Draft Glenn Parsons Expires in six months Nortel Networks February 26, 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 onths 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. Introduction This Internet Draft summarizes the proposed extensions as discussed at the IMAP-VOICE informal BOF at IETF, Orlando, December 1998. 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]. The VPIM effort is led by the VPIM Working Group within the Electronic Messaging Association. For more information see http://www.ema.org/vpim/. Parsons Expires 8/26/99 [Page 1] Internet Draft IMAP Voice February 26, 1999 3. 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. One suggestion for accomplishing this is: 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)]) The keyword ENCODING selects encoding as defined in the MIME Content-Transfer-Encoding Header Field. [4] Servers that support the DATA part specifier SHOULD list the DATA capability in response to the CAPABILITY command. 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. Three suggestions of how this can be accomplished are: 5.1 Use of an external reference mechanism requires split client support for Real Time Streaming Protocol (RTSP) as well as IMAP. 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) Parsons Expires 8/26/99 [Page 2] Internet Draft IMAP Voice February 26, 1999 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. There are two suggestions for accomplishing this: 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. 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. Parsons Expires 8/26/99 [Page 3] Internet Draft IMAP Voice February 26, 1999 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: 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. 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. Parsons Expires 8/26/99 [Page 4] Internet Draft IMAP Voice February 26, 1999 8.3 Message length indicated as a parameter of the Content-Type 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. Content-Type=audio/*; length=50 Content-Type=image/tiff; pages=3 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: 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] 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. Parsons Expires 8/26/99 [Page 5] Internet Draft IMAP Voice February 26, 1999 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 and email comments (notably from Jutta Degener and John Gardiner Myers). 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 8/26/99 [Page 6]