2.1.13 Voice Profile for Internet Mail (vpim)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01


John Noerenberg <jwn2@qualcomm.com>
Glenn Parsons <glenn.parsons@nortel.ca>

Applications Area Director(s):

Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>

Applications Area Advisor:

Ned Freed <ned.freed@innosoft.com>

Mailing Lists:

General Discussion:vpim@lists.neystadt.org
To Subscribe: majordomo@lists.neystadt.org
In Body: subscribe vpim
Archive: http://www.ema.org/vpimdir/minutes.html

Description of Working Group:

The Voice Profile for Internet Mail (VPIM) Version 2 is currently a Proposed Standard (RFC 2421) Applicability Statement. It is an application of Internet Mail originally intended for sending voice messages between voice messaging systems. As such, VPIM imposes several restrictions on the message and transport to support the characteristics of voice messaging. Many voice mail vendors have implemented systems according to RFC 2421 and are in the process of deploying these systems around the world. Most vendors have completed (or are currently involved in) interoperability testing of VPIM products and have posted their results on the VPIM website. This working group will promote the advancement of VPIM v2 on the standards track.

Several minor problems with VPIM v2 have been identified during the development and testing of products. These problems can easily be fixed with minor clarifications to the protocol. A revised VPIM v2 (and related protocols as necessary) will be produced to reflect these clarifications. No protocol changes will be introduced in this update.
Though VPIM uses Internet Mail, its restrictions can be inconvenient when sending and receiving messages from traditional desktop email clients. As a result, there is interest in loosening the restrictions of VPIM in a new version and make it the voice component of a unified messaging protocol suite. This would make it easier for desktop clients to send, receive, and forward voice messages while maintaining support for the characteristics of a voice message.
The primary goal of Version 3 is to support interoperability with deployed desktop email clients. A secondary goal is to specify interoperability with Version 2. The result is that the semantics of a voice or fax message within an email message can be interpreted at as many clients as possible.
An initial proposal for VPIM v3 (also known as Internet Voice Mail (IVM)) is currently documented in several Internet Drafts (see draft-ema-vpimv3-*): VPIM v3 Goals, VPIM v3 Unified Messaging (Primary Content), VPIM Addressing and VPIM v3 Specification. As well, several supporting protocol extensions may need to be worked in this group or in collaboration with other groups. These are: IMAP voice extensions, voice directory profiles, content negotiation details for voice and partial non-delivery notifications.
The working group will initially focus on agreement of the goals and then define a set of protocol documents to address the media, addressing, and handling semantics. Finally, VPIM v2 - v3 Interworking will be documented separately if needed.
The voice mail vendors and several email vendors have been meeting in the VPIM work group at the Electronic Messaging Association (EMA) for several years. This team produced VPIM v1 (RFC 1911) and VPIM v2 (RFC 2421). This group meets three times a year in between IETF meetings and is regularly attended by core VPIM proponents. As a result, there is benefit to using this venue as an interim meeting.
In addition, the work of this group is related to similar work by the Internet Fax WG. It is intended that Version 3 will use at least the Simple Mode of Internet Fax.
As well, other IETF WGs may be interested in proposed voice extensions to protocols. There may be value in collaborating on some work items.

Goals and Milestones:

May 00


Issue revised VPIM v2 Internet Draft with minor clarifications

May 00


Issue initial IVM/VPIM v3 Internet Drafts in WG

Jun 00


Document interworking VPIM v2 implementations

Jul 00


Issue updated drafts of IVM/VPIM v3 Goals, IVM/VPIM v3 Specification and related protocol documents as Internet Drafts

Aug 00


Issue updated Internet Drafts of VPIM addressing

Aug 00


Issue updated Internet Drafts of VPIM directory

Aug 00


Issue updated VPIM v2 Internet Draft

Aug 00


WG last call on VPIM v3 Goals as Informational RFC

Sep 00


Issue updated Internet Drafts of VPIM IMAP extensions

Sep 00


Issue revised VPIM v3 Specification and related protocol documents as Internet Drafts

Oct 00


WG last call on IVM/VPIM v3 Specification and related protocol documents as Proposed Standards RFCs

Oct 00


Submit IVM/VPIM v3 Goals to IESG for consideration as Informational RFC

Oct 00


Submit VPIM addressing to IESG for consideration as a Proposed Standard

Oct 00


WG last call on revised VPIM v2 for Draft Standard

Nov 00


Submit VPIM v2 to IESG for consideration as a Draft Standard RFC

Nov 00


Submit IVM/VPIM v3 et al to IESG for consideration as a Proposed Standard

Nov 00


WG last call on VPIM IMAP extensions as Standards Track RFC

Dec 00


Submit VPIM IMAP extensions to IESG for consideration as Standards Track RFC

Dec 00


WG last call on VPIM addressing as Standards Track RFC

Dec 00


WG last call on VPIM directory profile as Standards Track RFC

Jan 01


Submit VPIM addressing to IESG for consideration as Standards Track RFC

Jan 01


Submit VPIM directory to IESG for consideration as Standards Track RFC

Jan 01


WG last call on IVM/VPIM v3 content negotiation as Proposed Standard RFC

Feb 01


Submit VPIM content negotiation to IESG for consideration as Proposed Standard RFC

Mar 01


Review final work items and close

No Request For Comments

Current Meeting Report

Voice Profile for Internet Mail WG
IETF 50 - Friday, March 23, 2001
Formal Meeting

Chairs: Glenn Parsons <gparsons@nortelnetworks.com>
John Noerenberg <jwn2@qualcomm.com>

Notes: Greg White <gregwhite@lucent.com>

Glenn presented the agenda, which didn't get bashed at all. Glenn also made the point that we may need to start thinking about how the work in the IDN WG (Internationalized Domain Names) and MIDTAX BOF (Middle Box Taxonomy) affects the work in this group. Glenn then presented some WG milestones that can be found on the WG webpage.


VPIM v2, rev. 2:

Still in the process of trying to move the spec to Draft Standard. Some fixes need to be made, and ambiguities need to be cleared up, but the big issue is making sure all the references are normative. The following need to be moved to Draft Standard:
- MDN: John Noerenberg has developed an interoperability checklist (see Lunch BOF).
- DSN: Greg Vaudreuil & Keith Moore will be pushing these, except the Enhanced Mail System Status Codes spec, which will be reworked by Ned Freed.
- Image/TIFF: being pushed by the FAX WG.
- vCard & Text/Directory: being dropped from spec.

There has not been a new version of the draft issued since the last IETF. Glenn suggested that we should get ready to do a WG Last Call on the following drafts: VPIM v2r2 (including multipart/voice-message), Toll Quality Voice (32KADPCM) Registration, Content-Duration.

VPIM Addressing:

It was reported that WG Last Call is complete, and we are waiting for the editor to make some small updates before forwarding the draft to the AD.

Voice Message Routing Service:

Based on ENUM, use ENUM to get information or LDAP URL. Document is ready for WG Last Call.

Voice Messaging Directory Service:

Editors need to clean up the ASN.1 and BNF. The editors also need to add codec identification. NOTE: this draft no longer exists in the IETF I-D repository.

VPIM Website Status:

EMA used to host the website vpim.org; this site is now temporarily unavailable. However, these pages can be found at http://welcome.to/vpim. It turns out that the reason for the website problem is that the management of the EMA has been transferred to The Open Group. The Open Group will host an EMA Forum, which in turn will manage a VPIM WG. The focus of this WG will be marketing & education and sponsoring interoperability events. It was noted that Declarations of Compatability & Interoperability can be found on the Interop website, and that results from the last bakeoff will be formatted and placed here in order to support the move of VPIM v2r2 to Draft Standard.

FAX WG Update:

Claudio Allocchio reported that the FAX Addressing drafts need to be reviewed by Ned before they are submitted for IETF Last Call.

ENUM WG Update:

Rich Shockey made the following presentation: ENUM WG did not meet this time, because the core protocol work is done (several drafts need to be finalized), and the discussion forums have moved to a highly political realm. He mentioned that at the ITU-T meetings in Geneva, an ENUM workshop was given to global PTT regulators. The outcome of this workshop was that ITU Study Group 2 is to create an ad-hoc group to develop a document for implementing ENUM among member states. RFC 2916 says to follow the national dialing plan, so ENUM administration becomes a nation-state responsibility. Recent activity shows that RFC 2916 will be implemented on a global scale. Also, there has been some minor discussion between the ITU & IAB on using e164.arpa as the global tree for ENUM.

Swedish PTT regulators were to have presented a report to the Swedish government on ENUM in Sweden on 4/1/01. The Netherlands, Belgium, & France are interested in ENUM testing as soon as possible. The U.S. has formed an ad-hoc group under Study Group A within the State Department. During the week following IETF, presentation were to have been made in Washington, D.C. outlining how ENUM should be implemented in the U.S.

Rich predicts that the actual deployment of zones within e164.arpa is 4Q2001 at the earliest. Rich stated that VPIM can deploy on e164, and that a couple of companies have testbeds available with web-based, self-provisioning databases.

SIP WG Update:

Rohan Mahy was scheduled to report the status of the SIP MWI draft, but he did not show up at our meeting.


Glenn made the statement that to bring Voice Mail into the E-Mail world, our success still lies with educating the email folks. The email folks are still worried that some aspects of the IVM work does not fit into the traditional email model.

IVM Goals:

Emily Candell gave a presentation on this draft, noting that nothing major changed since the last IETF. After some discussion regarding the purpose of the draft, it was decided that this draft should be targeted for Informational status. After this IETF, and perhaps after some further codec word tweaking, the draft will be submitted for WG Last Call for Informational status. The question asked as to why this document wasn't called IVM Requirements - the author agreed that this was probably a better name and would make the change.


This draft still requires minor editorial changes, along with a description of the codec.

Message Context:

Eric Burger presented the status of this draft. Changes from -04.txt to -05.txt include better English, corrected ABNF, removed Video-Message and added Multimedia-Message to the list of message context types, and improved the definition of the Text-Message type. Eric asked Ned how to set up a new IANA registry for Message Context Types. Ned replied that there is a document explaining how to do it, and that Michelle at iana@iana.org could be contacted for more information. Ned also mentioned that the instructions for registering a new value should appear in this draft. Eric also wants to discuss the following issue on the list: is there a need for adding SMS-Message as a context type that is different from Text-Message of high priority, or is there a need for a "high-priority Text-Message" context type. The plan is to issue -06.txt for WG Last Call after this issue is resolved, the new IANA registry is set up, and other small changes are made.

Critical Content:

Eric also presented the status of this draft. Changes from -02.txt to -03.txt include the use of Content Gateway terminology, chapter reorganization, and cosmetic changes. Eric gave some background on why he chose to create a new parameter for the Content-Disposition field over create a new parameter for the Content-Type field or creating a Content-Criticality field. The plan for -04.txt is to use the new Content-Disposition parm, clean up the meaning of IMPORTANT, reaffirm MDN/DSN rules. Also planned is a complimentary MDN Notification Options draft.


After Glenn presented a slide showing the history of codec selection for VPIM v2, VPIM v3, IVM, etc., Glenn took a vote on the following:

What codecs are mandatory to receive/play for IVM?
1) MS-GSM packaged in WAV (audio/wav)
2) raw G.711 (audio/basic)
3) both 1) & 2)

The consensus of the room was for option 3) both, and this proposal will be taken to the list for confirmation.

IMAP Extensions:

This was basically a short rehash of the conversation from the Lunch BOF. Glenn then asked for volunteers to work on profiles to help explain how the new CHANNEL command would be used. Glenn said he would work on a profile for audio playback on a telephone, and Eric said he would work on a profile to stream video playback to a desktop viewer. A standing question is should these profiles go into the CHANNEL spec. Some concern was voiced that profile work would progress at different rates because of different levels of importance to different people.

Voice Messaging Client Behavior:

Plan is to submit the draft for WG Last Call for Informational status.

Calling Line ID for VPIM Messages:

Waiting for the editor to make update based on received comments. Also need to determine the charset and make it an unstructured field. A question was raised as to whether ther were more related fields to store in the RFC822 header. Greg Vaudreuil has a list of other things he would like stored, but that list has not been discussed.


John Neystadt presented his idea for the Smart Notification & Alarm Protocol (SNAP). It is defined to enable messaging servers to notify the outside world about mailbox events. It will have an XML- or MIME-based schema for required content fields, and it will define one or more bindings to transports (SMTP, HTTP, SIP, etc.). The question was raised as to what are the differences between SNAP & ENP (I think ENP was the term used), but I didn't catch the answer. The group decided that SNAP is worth investigating, and John will develop a draft for the list.


Voice Profile for Internet Mail WG
IETF 50 - Wednesday, March 21, 2001
Lunch BOF

Chairs: Glenn Parsons <gparsons@nortelnetworks.com>
John Noerenberg <jwn2@qualcomm.com>

Notes: Greg White <gregwhite@lucent.com>

Glenn arranged a Lunch BOF for all interested people. This was done because the formal WG meeting was not until Friday morning, when many people were scheduled to have already left the conference. The BOF was held in Eric Burger's suite, and Eric also picked up the tab for lunch. Thank you, Eric.

IMAP Extensions

BINARY: The IMAPEXT folks had a BOF and came to an agreement on how to determine decoded message size. A new FETCH command attribute BINARY.SIZE has been created. One would perform a FETCH BODYSTRUCTURE, and then a FETCH BINARY.SIZE. The BINARYSTRUCTURE attribute has been eliminated. Another draft will come out with these updates.

CHANNEL: The first draft went out, but there was no notification that it went out. The draft is in rough template form; lots of information is still missing. It turns out that what Greg Vaudreuil wanted to do (get several body parts as concatenated segments) is not doable because of partial failure conditions. It was also noted that the partially-qualified URI specification needs work. The question was raised as to whether or not the CHANNEL feature was really needed, and the response was to do some profiling to determine how we want to use this feature.

NOTE: It was determined that the above drafts would be treated as individual submissions, rather than IMAPEXT WG submissions. It was also decided that the mailing list at <ietf-imap-voice@imc.org> would be used to discuss these drafts, in order to save VPIM folks from signing up for the IMAPEXT list, and vice versa. To subscribe, send mail to <ietf-imap-voice-request@imc.org>.

MDN Revisions:

John Noerenberg has developed an MDN interoperability checklist. The question was raised as to how this information would be obtained. Suggestions were to issue a WG call for contributions to the list, or perhaps to post a call for contributions to the notary list. We still need to determine who will make the document revisions. After the revs are made, Ned Freed will need to review them.

DSN Revisions:

It was determined that we do not need a DSN interoperability checklist; instead, only clarifications to the documents are needed. Also, it was noted that the rules concerning the Final-Recipient: field need to be loosened just a bit. Hopefully, some new drafts will appear in the May timeframe.
Critical Content:

The issue was "Is it wrong to have a "criticality" parameter in the Content-Disposition: field?" After some discussion, it was decided that defining the criticality parameter for that field is the right thing to do.


The debate continues. Does there need to be a RIFF header or a WAV header on a voice segment? What kind of filename extension do we use? Are there enough desktop players out there that play raw data? It was decided that the safe thing to do from the sender's point of view is to send a header. Then the question was where does the header definition go - in the VPIM spec or a different spec? What are the Microsoft IPR issues with the header? Should we push them to resolve the issue or just move forward without them? It was decided that the way to move forward was to determine the codec requirements on the receiver, then fashion the requirements for the sender.


A general discussion was held on the messaging activity in 3GPP (as a result of Last meeting's discussion). The 3GPP MMS WG is looking at the aspects (e.g., working mailbox (IMAP) or non-mailbox (POP)). No specific action was decided.


Goals for Internet Voice Mail
Message Context for Internet Mail
Critical Content of Internet Mail
Smart Notification and Alarm Protocol (SNAP) for Email