One document matched: draft-ema-vpim-imap-00.txt
Internet Draft Glenn Parsons
Expires in six months Nortel Networks
February 26, 1999
IMAP Voice Extensions
<draft-ema-vpim-imap-00.txt>
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://<iserver>/<enc_mailbox>[uidvalidity]<iuid>[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[]<<partial>>
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", <draft-ema-vpim-um-01.txt>, 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]
| PAFTECH AB 2003-2026 | 2026-04-23 17:17:00 |