2.1.13 Voice Profile for Internet Mail (vpim)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01

Chair(s):

John Noerenberg <jwn2@qualcomm.com>
J Maruszak <gparsons@nortelnetworks.com>

Applications Area Director(s):

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

Applications Area Advisor:

Ned Freed <ned.freed@mrochek.com>

Mailing Lists:

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

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.

Collaboration

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

Internet-Drafts:
No Request For Comments

Current Meeting Report

VPIM Meeting Minutes, IETF 51, London
By: Stuart McRae <stuart.mcrae@uk.ibm.com>
Chair: Glenn Parsons <gparsons@nortelnetworks.com>

John Noerenberg has resigned as co-chair due to a change in his area of focus. The IESG is considering whether it is worth replacing him as the group is so near to completing its work

The Agenda was reviewed and agreed.

1. VPIM Charter & Milestones review (Glenn Parsons)

We are currently using www.ema.org/vpim as the repository for VPIM information, but hope to have vpim.org back soon (or another dedicated VPIM site).

The charter deliverable documents were reviewed. Most documents are in or ready to enter Working Group last call. Milestones have been updated as appropriate. This could be the last meeting of the group, or we may meet next time, depending on whether issues/loose ends remain to be cleared up. We also need to consider if we want to recharter and do additional work, so that may be a topic of conversation for the next IETF.

2. VPIM v2 r2 - 30 minutes

2.1 Voice Profile for Internet Mail - version 2 (Greg Vaudreuil)

- draft-ietf-vpim-vpimv2r2-03
- draft-ietf-vpim-vpimv2r2-32k-01
- draft-ietf-vpim-vpimv2r2-dur-01

The vpimv2r2 document now includes the IANA registration instead of having it as a separate document. These documents have completed working group last call and have gone to the IESG.

2.2 MDN drafts (Greg Vaudreuil )

Following discussions with folks present this week, Greg is close to having a document ready to post as a first draft revision of RFC 2298.

Only dispositions that seem to be implemented are "deleted" and "displayed". So the plan is to delete the others in the draft as not tested. Others that are useful can be built later as extensions (e.g. the fax working group have done further work in this area).

The objective is to get lots of review of the first draft and expect people to speak up if they have implemented things that are deleted. The key is therefore to get all the working groups who have used MDNs to review the draft.

Disposition Modifiers do not seem to be implemented. Therefore the proposal is to delete all except the extension modifier. It is assumed that no implementation experience is necessary to for a generic extension mechanism.

Greg requested clarification on the requirement for implementations. Ned responded that two senders and two receivers are enough - though more is better. We will need a list of which features are implemented in different implementations.

Greg will add additional advice on gatewaying to his draft.

There will be just one document. The title of the document will be revised to more accurately express the fact that it is self contained.

2.3 DSN drafts (Greg Vaudreuil)

- draft-moore-1891bis-00
- draft-vaudreuil-1892bis-00
- draft-vaudreuil-1893bis-00
- draft-vaudreuil-1893ext-00
- draft-vaudreuil-1894bis-00

These drafts revise RFC1891-RFC1894.

Greg is working with the IETF Editor to delete the "1983" draft that appeared due to a typographical error in the filename during submission!

The draft-vaudreuil-1893ext-00 draft is being used to collect additional status codes that need to be added.

Ned Freed said he would also put out a revision to RFC2034 (which is also mentioned in VPIMv2)

All of these documents refer to RFC821 and RFC822. They should remain this way until it is clear whether either of the updates (2821 and 2822) are going to have to be cycled.

These documents will stay as individual contribution, so Greg will tell Ned when they are ready for IETF Last Call.

3. VPIM Addressing (Glenn Parsons)

- draft-ietf-vpim-address-01

This document has completed working group last call and it has gone to the Area Directors for review.

The Fax addressing drafts have now been approved and will be published as Draft Standard. There is some concern that the broader applicability of this work beyond fax is not being recognised. Claudio has therefore requested that the IESG add a note to the generic document to indicate its applicability beyond fax. Ned is investigating if this is possible.

4. ENUM Update (Glenn Parsons)

ENUM is thinking of rechartering and coming back into existence to figure out some deployment issues.

5. VPIM Directory (Greg Vaudreuil)

5.1 Voice Message Routing Service

- draft-ietf-vpim-routing-01 (expired)

This draft has expired. It was based on ENUM feedback. The intention is to post a new draft that updates the date only. Comments/review is requested from anyone considering/implementing this. Greg expects to see more activity/trials in this space.

What should we do if the VPIM work group terminates? Does this become an individual submission, or do we finalise it and submit it? The consensus was that we should last call it the document as it is, and then it can be redone if ENUM changes (it is currently consistent with current ENUM documents).

5.2 Voice Messaging Directory Service (Schema)

draft-ietf-vpim-vpimdir-00 (expired)

This work is stalled because Anne has left the industry. Glenn is going to take over getting this revised and posted.

There are no known outstanding issues. The ASN1 and BNF need to be cleaned up, the codec identification added, and it needs to be made a subclass of inetOrgPerson (rather than stand alone).

6.0 IVM

6.1 Internet Voice Mail Requirements (Glenn Parsons)

- draft-ietf-vpim-ivm-goals-03

The Working Group Last call is complete as an Informational document. It has gone to the Area Directors for review.

6.2 Internet Voice Messaging (Stuart McRae)

- draft-ietf-vpim-ivm-02

The IVM draft has been updated in preparation for completion, removing editorial comments, making minor clarifications, updating the bibliography, reflection completion of the DRUMS revision, and aligning it with the latest co-dependent drafts (Message Context, Critical Content). It currently refers to both www.vpim.org and www.ema.org/vpim.

One correction was made - if a VPIMv2 message is created it MUST conform to the VPIMv2r2 RFC.

The other technical change was based on the codec consensus that an IVM Message SHOULD contain an audio/wav or audio/ basic content (except when it knows what else the recipient supports - e.g. VPIMv2). As a result the updated Codec table states that an IVM implementation:

- MUST read "audio/wav, codec=31" and audio/basic
- MUST write "audio/wav, codec=31" or audio/basic

+----------+--------+----------+--------+----------+
| | No VPIMv2 Support | VPIMv2 Support |
+----------+--------+----------+--------+----------+
| Codec | Record | Playback | Record | Playback |
+----------+--------+----------+--------+----------+
| MS-GSM | MAY* | MUST | MAY* | MUST |
| G.711 | MAY* | MUST | MAY* | MUST |
| 32KADPCM | MAY | MAY | MUST | MUST |
| Other | MAY | MAY | MAY | MAY |
+----------+--------+----------+--------+----------+
* MUST record at least one

Stuart went on to highlight some specific facts of interest about the current draft to ensure there was consensus ready for the last call (comments on these items will be solicited on the list):

* The draft states that you SHOULD create a message with a Message-context of voice-message - so what makes something an IVM message, if not that it has a Message Context of voice-message? The advantage of allowing IVM messages which do not contain a Message-context is that existing e-mail clients can conform (which is a goal). This could be achieved by leaving this as SHOULD, or reworded it to "The message header MUST indicate a message context of "voice-message" if the sender support Message-context (see [HINT])."

* If a Message-context of voice-message is not required, what makes a message an Internet Voice Message? Does it have to contains an approved voice content type (or rather any voice content type, as this is permitted)? Can a message with no voice content be an IVM? This is permitted for a Message-context of voice-message, but does it make sense for an Internet Voice Message? This could be addressed by rewording the requirement on content type as follows: "An Internet Voice Message MUST contain at least one audio part, which may be at any location within a message and SHOULD be contained in either an audio/wav or audio/basic content-type - the only exception being when the originator is aware that the recipient can handle other content."

* The current specification says a client SHOULD indicate Critical body parts, but MUST non-deliver if cannot render all Critical body parts. Hence a client that does not support Critical Content can conform when generating IVM messages but not when receiving them. This could either be resolved by changing MUST to SHOULD, or by revising the wording to "MUST non-deliver the entire message per [CRITICAL] if it supports Criticality".

* VPIMv2 support is listed as MAY. This is full support of VPIMv2. The goals state we SHOULD support interoperability with VPIMv2. The IVM document introduction states that it provides "some level of interoperability" with VPIMv2, and later it refers to "partial interoperability" (but what we actually specify is full compliance). In practice, if the codec is supported and nothing else, there is some level of interoperability (but we do not explicitly state this). The current language says we ruled "Interoperability out of scope" for the document - this could be changed to rule "gatewaying out of scope" to reflect the reality today. Our charter includes a separate document on gatewaying which has not been addressed (and therefore will not be completed as the group is nearly done).

Greg suggested that we should include a discussion of interoperability in the document. It could include gatewaying, and discussion of desktops which can display VPIMv2 but not process them fully, or can downloading plug-ins later providing deferred access to contents. Stuart agreed to send a proposal to the list for discussion.

* Security Considerations - currently we just refer to VPIMv2. However this does not cover the implications of the ability to include any body part type? This could be addressed with a reference to the MIME security considerations. Thoughts on other security considerations that should be addressed are welcomed (on the list).

* Greg commented that SHOULDs were generally a bad thing and there were quite a number of them in the document. Stuart agreed to review them with the intention of reducing the number (based on resolutions of the issues above).

This document needs to wait for MS-GSM and WAV drafts to be complete for a final revision, and then a Working Group last call can be made.

6.3 Critical Content of Internet Mail (Eric Burger)

- draft-ietf-vpim-cc-04

This document has completed working group last call and has it has gone to the Area Directors for review.

6.4 Message Context for Internet Mail (Eric Burger)

- draft-ietf-vpim-hint-07

This draft went to -07 (due to typo in 06) and has completed working group last call and has it has gone to the Area Directors for review.

6.5 Audio/wav with MS-GSM (Charles Eliot)

- draft-ema-vpim-msgsm-00 (deleted)
- draft-ema-vpim-wav-00 (deleted)

The drafts have expired (and the WAV has some technical errors). Consensus has been reached that we will support both MS-GSM/WAV and G.711 (as audio/basic) - so we still need the MS-GSM and WAV documents.

No progress on the documents has been made since San Diego, but this will change immediately as Charles has taken it over.

The WAV document needs the technical errors corrected - and a thorough rewrite! RFC 2361 already defines IANA Registrations for audio/vnd.wave codecs. Microsoft has no issues involving intellectual property around RIFF and WAV.

One proposal is to simplify the specification to only include what is needed to support IVM, rather than making it a generic definition of WAV. However this was rejecetd since we also need to generate something that is consistent with what is already in general use - which may prevent it from being too IVM specific (it needs, at least, to be extensible). It can reference existing RFCs and documents.

The consensus was to create a WAV draft as general as possible consistent with the primary aim of establishing a defined usage for audio/wav. Parameter specifics for encoding MS-GSM payloads inside WAV wrappers will be left to the IVM draft.

The MS-GSM draft seem to be technically correct. The current draft provides the IANA registration and documents the order/format of GSM encoding parameters for MS-GSM. The required definition will be for audio/wav not audio/ms-gsm to allow as much as possible of the existing deployed base to launch the correct application and to play the voice message correctly. Which is why this group also needs to be concerned with the broader definition of WAV in MIME.

This draft does not describe implementation of a GSM 6.10 codec (this is an external document). Given that, Microsoft do not believe that there are any IPR issues associated with this draft.

The consensus then was for the MS-GSM draft to deal narrowly with the bit orderings required to get a GSM payload to be recognizable to an MS-GSM codec, and will not define a new IANA registration for audio/ms-gsm.

Charles will create the new drafts for review in 3-4 weeks. Once there is consensus on those drafts we can update the IVM document and last call it.

7. VPIM Addenda

7.1 Binary & channel IMAP extensions for VPIM Messages (Lyndon Nerenberg)

- draft-nerenberg-imap-binary-04

Binary is pretty much a done deal - one more revision of the draft is expected and then it will go in as an individual submission for IETF Last Call (around Sept.).

- draft-nerenberg-imap-channel-00

There is a pretty good consensus that the syntax is good. There is still work to be done on the semantics of the URIs. This discussion will focus on the IMAP-Voice mailing list. Security recommendations are also going to be a major piece of work, since a request could invoke the use of something like FTP to move the message somewhere outside of the authentication realm of the server.

There is also a draft that has been posted to the IMAP Extension list to provide access to all the Content-* mime header information for a message. Obviously we would like to see Message Context included for VPIM, but it may make sense to generalise that further to provide all MIME Header information.

7.2 Calling Line Identification for VPIM Messages (Glenn Parsons)

- draft-ema-vpim-clid-02

This is an existing document that we put to Working Group last call (for an extended period as it includes the IETF meeting week).

The draft rules out of scope information providing information beyond what you get from the Caller Id. Specifically it rules out of bounds access to other, privileged network information.

Should it contain structured data? Previous consensus was that it should not. But the context in which the Caller Id information was captured is currently lost. Should it be possible to indicate if it is an e.164 number, or a local PBX number (internal extension), or something else (which is probably not algorithmically usable).

Is the SIP Remote Party Id header applicable? No, as that is more for system information.

If the originator knows enough about the context to turn it into an international number, it should be able to do so. Once you have the full e.164 number, or can derive it, how do you indicate that this is what you have (e.g. a "+" prefix?). It may be useful to provide both a display name (what you got) plus a url specification (from RFC2806). Or the Minimal PSTN Address Format (from RFC 2303) could be used. If a url is used, it could be allowed to contain either an RFC2806 URI or a mailto containing an RFC2303 address.

Greg offered to provide an initial proposal. This issue will be discussed further on the list.

7.3 Voice Messaging Client Behaviour (Glenn Parsons)

- draft-ema-vpim-cb-02

Existing work, based on the Voice Messaging IMAP Client Behaviour work, which has been put out to an extended Working Group last call.

7.4 SIP Message Waiting Indication (Rohan Mahy)

- draft-mahy-sip-message-waiting-02

The SIP group has a draft for MWI using SIP - now a proposed work item for the Sipping working group. The XML content format has been removed as no-one is using it (could be added back later). Comments from the VPIM group are invited. The meeting was positive to the idea of the Sipping working group progressing this.

7.5 SNAP Simple Notification and Alarm Protocol (Noam Shapira)

- draft-shapira-snap-01

SNAP is designed to allow a Notification Server to communicate with an E-Mail Server , Voice-Mail server, Calendar server (or whatever), and provide notifications to users via MWI, SMS, e-mail, etc. SNAP defines the Notification Server to E-Mail/V-Mail server interface. It is intended for high volume, high performance applications.

Issues discussed include:

* The fact that it is Push based - there was support in the room for such an approach for a highly scalable solution.

* Its Non-Subscription model for high performance - it needs to be provisioned by some other needs. There were questions about whether this actually gains you anything (if it does, it may well be at start up time only), and whether the provisioning oriented model is applicable to many real world situations. The author's clearly feel it is.

* The approach of being as informative as possible about the Notification state changes to provide maximum functionality (including being sufficient to implement current voicemail server behaviour). The syntax was felt to be rather fixed . The last draft has added XML as an alternative representation, but why have the overhead of 2 ways of doing the same thing? But you already need a parser for standard headers and is requiring an XML parser reasonable?

The next step is to address security issues and RFC 2822 compliance, and add Message Context support.

There was interest in making this a work item of the VPIM working group. As the group is looking to wrap up, it would not make sense to add it to the charter now. But it the group decides to recharter this could be one of the work items they address.

8. Wrap Up

There was a final discussion of open issues from the Charter not currently being addressed:

* IVM-VPIMv2 Interworking - we will look at putting this into the IVM draft, if it is not too large;

Content Negotiation - this is somewhat addressed via the LDAP Schema draft. There were no objections to dropping further work on this item.

The meeting closed.

Slides

Agenda
Internet Voice Messaging
Critical Content of Internet Mail
Message Context for Internet Mail
Status of WAV and MS-GSM RFCs
Smart Notification and Alarm Protocol (SNAP)