One document matched: draft-ema-vpim-imap-01.txt
Differences from 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
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://<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.
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[]<<partial>>
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", <draft-ema-vpim-um-01.txt>, 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]
| PAFTECH AB 2003-2026 | 2026-04-23 11:21:11 |