One document matched: draft-ema-vpim-simplev3-01.txt
Differences from draft-ema-vpim-simplev3-00.txt
Internet Draft Glenn Parsons
Nortel Networks
March 10, 2000
Voice Profile for Internet Mail Version 3
A Simple Approach
<draft-ema-vpim-simplev3-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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 proposes an alternative simple approach to VPIM v3.
For more information on the VPIM industry activity see
http://www.ema.org/vpim/.
2. Conventions used in this document
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 RFC-2119 [2].
3. Introduction
Voice messaging transport over Internet Mail is defined by VPIM v2
(RFC 2421)[3].
Parsons Expires: 09/10/00 1
Internet Draft VPIM v3 March 10, 2000
The original detailed proposal for VPIM v3 is contained in [4].
This Internet Draft details a proposed simpler approach at VPIM v3.
It is intended to follow the baseline goals described in [5]. Given
that VPIM v2 [3] is a well defined (or will be when it is revised for
clarity and maturity elevation) description of networking voice-only
systems using Internet Mail, and that Internet Mail is being used as-
is for multimedia messaging, there is minimal need for a detailed
revision of VPIM to support Unified Messaging.
It is proposed, that all that is needed is an agreement to use
Internet Mail without modification and profile a minimal set of
Internet Mail standard features that a VPIM v3 compliant system MUST
support. As all devices become connected with email, VPIM v3
compliance will ensure the ability to communicate voice messages
between these devices.
4. Message Format
All messages MUST conform with the Internet Mail format as described
in DRUMS [6][7]. Any content type is allowed to be in a message.
The top level content type on origination of a new, forwarded or
reply message SHOULD typically be multipart/mixed. Although it may
also be any other multipart/* such as multipart/voice-message or
multipart/related.
The top level content type on origination of a delivery notification
message MUST be either multipart/report.
An implementation SHOULD use the multipart/voice-message content type
as described in [8] to package audio content together as a voice
message.
4.1 Voice Message Format
A message containing a multipart/voice-message content-type at the
top level or as the first on the second level (e.g., under
multipart/mixed) is implicitly primarily a voice message. The
recipient system may use this to decide to present the message as a
voice message.
Additionally, an originator may choose to indicate that one of the
body parts (e.g., the spoken message part) is critical for the
delivery of the message. This would ensure that this part is
delivered if others are dropped for delivery to less capable clients.
Note that there is no current proposal for this feature.
Parsons Expires 9/10/00 2
Internet Draft VPIM v3 March 10, 2000
5. Transport
All transport MUST support Internet Mail transport (SMTP/ESMTP) as
described in DRUMS [6].
6. Addressing
Any valid Internet Mail address MAY be used.
However, VPIM onramp and offramp implementations MAY require a
stricter addressing structure [9]. As a result, the VPIM addressing
structure of [9] MUST be supported for recipient addresses in inbound
messages and SHOULD be supported for the originator address if
required.
Discovery of an Internet Mail address for a recipient's voice mailbox
(and spoken name if applicable) by only knowing the E.164 phone
number of the recipient SHOULD be supported [10].
7. Notifications
DSN MUST be supported [11]. All non-delivery of messages MUST result
in a NDN. Partial DSNs (to indicate that one or more contents could
not be stored/relayed by the receiving MTA) SHOULD be supported [12].
MDN MUST be supported [13]. Partial MDNs (to indicate that one or
more contents could not be rendered at the client) SHOULD be
supported. Note that partial MDN is a new concept with no current
proposal.
8. Voice Contents
Voice messages may be contained at any location within a message and
MUST be contained in an audio/* content-type. The parameters
described in [3] MUST be used to identify them as voice messages or
spoken names.
The originator's spoken name SHOULD be included with a message.
Spoken names (for originators and recipients) SHOULD be included as
separate audio contents. These MAY be referenced from the message
header or a vCard. Spoken names MAY also be included inline with a
vCard. External references SHOULD NOT be used.
Any voice codec may be used. An implementation SHOULD determine the
recipient capabilities before the sending of a message if possible
and choose a codec accordingly (a CONNEG and RESCAP profile is
needed). In the absence of recipient knowledge, implementations
compliant with this document:
Parsons Expires 9/10/00 3
Internet Draft VPIM v3 March 10, 2000
MUST play & record: MS-GSM - audio/wav; codec=31 [14]
SHOULD play & record: G.726 - audio/32kadpcm [15]
Note for an implementation to interoperate with VPIM v2 it MUST, at a
minimum, support play & record of G.726.
Compliant implementations recording with a WAVE RIFF header MUST add
the codec parameter on origination. However, non-compliant systems
may send messages without this parameter.
9. IMAP
Implementations SHOULD support access to the voice message store
using IMAP [16]. The voice extensions described in [17] SHOULD be
supported.
10. Backwards Compatibility with VPIM v2
Because of the wide deployed base of VPIM v2, implementations are
encouraged to send messages in a format compatible with VPIM v2
systems as described in [3]. Simply, record and encode
audio/32kadpcm under a top level multipart/voice-message.
If a VPIM v3 system has knowledge that the recipient system is VPIM
v2 (via CONNEG, RESCAP, LDAP, etc.) it MUST send a VPIM v2 message.
A VPIM v2 system SHOULD reject a message it cannot render with a DSN
indicating the media is unsupported. A VPIM v3 compliant system
SHOULD record this information for future sending, and SHOULD resend
the original message in a VPIM v2 format.
11. Security Considerations
It is anticipated that there are no additional security issues beyond
those identified in VPIM v2.
12. References
1 Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
Parsons Expires 9/10/00 4
Internet Draft VPIM v3 March 10, 2000
3 Vaudreuil, G., Parsons, G., "Voice Profile for Internet Mail -
version 2", RFC 2421, September 1998.
4 Vaudreuil, G., Parsons, G., "Voice Profile for Internet Mail -
version 3", <draft-ema-vpimv3-00.txt>, Work in Progress.
5 Di Silvestro, Laile, "Goals for VPIM v3", <draft-ema-vpimv3-
goals-01.txt>, Work in Progress.
6 Klensin, J,. "Simple Mail Transfer Protocol", <draft-ietf-
drums-smtpupd-10.txt>, Work in Progress.
7 Resnick, P., "Internet Message Format Standard", <draft-ietf-
drums-msg-fmt-07.txt>, Work in Progress.
8 G. Vaudreuil and G. Parsons, "VPIM Voice Message: MIME Sub-
type Registration", RFC 2423, September 1998.
9 G. Parsons, G., "VPIM Addressing", <draft-ema-vpim-address-
01.txt>, Work in Progress.
10 Brown, A., Vaudreuil, G., _Telephone Number Based Directory
Service_, <draft-vaudreuil-enum-e164dir-00.txt>, Work in
Progress.
11 Moore, K., Vaudreuil, G., "An Extensible Message Format for
Delivery Status Notifications", RFC 1894, 01/15/1996.
12 Burger, Eric, _Partial Non-Delivery Notification_, <draft-ema-
vpim-pndn-01.txt>, Work in Progress.
13 Fajman, Roger, "An Extensible Message Format for Message
Disposition Notifications" RFC 2298, March 1998.
14 Baribault, G. et al, _ Waveform Audio File Format _ MIME
subtype registration_, <draft-ema-vpim-wav-00.txt>, Work in
Progress.
Baribault, G. et al, _ Microsoft GSM _ MIME subtype
registration_, <draft-ema-vpim-msgsm-00.txt>, Work in Progress.
15 G. Vaudreuil and G. Parsons, "Toll Quality Voice - 32 kbit/s
ADPCM: MIME Sub-type Registration", RFC 2422, September 1998.
16 Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 2060, December 1996.
17 Parsons, G., "IMAP Voice Extensions", <draft-ema-vpim-imap-
01.txt>, Work in Progress.
Parsons Expires 9/10/00 5
Internet Draft VPIM v3 March 10, 2000
13. Acknowledgements
This draft is a derivative of the original VPIM v2 work, hopefully
taking into account the views of both the voice mail and email
communities that have come together to work on VPIM v3 in the IETF
VPIM BOF/WG.
14. 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
15. Full Copyright Statement
Copyright (C) The Internet Society (2000). 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 9/10/00 6
| PAFTECH AB 2003-2026 | 2026-04-23 11:20:00 |