Minutes, VPIM BOF, 44th IETF Meeting, March 16, 1999
A historical background and overview of VPIM was presented. VPIM v2 (RFC 2421) evolved from VPIM v1 (RFC 1911), which evolved from AMIS. VPIM v2 is a Voice Profile for Internet Mail, and specifies MIME extensions (and restrictions) and SMTP extensions.
VPIM was developed under the auspices of the Electronic Messaging Association (EMA).
The EMA has established VPIM conformance testing procedures that provide confidence that products are conformant and do indeed inter-operate. EMA does not provide test labs or a reference system for verifying conformance. Rather, individual vendors initiate their own interoperability testing and register their conformance with the EMA. Many inter-vendor tests have been completed and more are planned as new VPIM v2 products are introduced this year.
VPIM v2 became a proposed standard in 1998. The next steps are to 1) document interoperability of vendor systems, 2) reissue the VPIM v2 specification by clarifying some ambiguities, and 3) progress the specification to draft standard, target Q3 1999.
There was a question whether the 6-month waiting period after reissuing the document applies before its progression, but since no new features or protocol changes are being introduced, this delay will not be necessary. Protocol changes will only be introduced in VPIM v3.
A suggestion was made that a VPIM v2 protocol change may be advisable for interoperability with Ifax (i.e. VPIM v2 should profile the use of the S profile of TIFF-FX instead of TIFF-F). This was debated, with the alternate suggestion made that changes be deferred until VPIM v3 and interoperability limitations be documented in an associated BCP document.
VPIM v3 Goals <draft-ema-vpimv3-goals-00.txt>
The profile must support interoperability with desktop clients and unified messaging systems. It must be backward compatible with VPIM v2. A minimum set of features must be supported by both profiles. Suggested that some minor VPIM v2 changes may be required, such as introducing new DSN status codes.
The profile must provide for multiple codecs. Some guidelines for selecting codecs include
a) supported on multiple platforms,
b) only a limited number to be profiled,
c) source code availability,
d) no IPR considerations,
e) decoding and encoding complexity,
f) bit rate,
g) support for VOIP
The profile will specify audio encoding requirements, provide support for streaming, allow text and other body parts (with critical content/primary content considerations driving discard rules), and provide support for audio incapable clients. The VPIM v3 conforming system will inter-operate in an email environment following common practices.
Unified Messaging and Primary Content <draft-ema-vpim-um-01.txt>
This Internet Draft describes the concept of a Primary Content Type of a message. The primary content of a VPIM message (multipart/voice-message) is voice; the primary content of a fax message (multipart/fax-message) is fax. Primary content-aware unified messaging clients can launch an appropriate viewer/player depending on type. Other semantics follow, such as discard rules, MDN generation, message status changes (unseen_seen).
While the requirement was supported, there was some opposition to the chosen method. The argument was that the same results can be achieved using multipart/related and marking the most important/primary body using the start tag.
Noted that it will be necessary to clean up the semantics of multipart/mixed, because it is used as a wrapper for many types of messages.
It was also noted that the primary content concept does not allow for messages where all/many parts are of equal importance.
VPIM Addresses <draft-ema-vpim-address-00.txt>
This presentation described VPIM v2 and VPIM v3 addressing. VPIM v2- addresses consist of a mailbox number + extension. Use of the international dialing plan is encouraged, and may be followed by an extension. Addresses are restricted due to limitations of a telephone.
VPIM v3- Addresses are unrestricted. New address service types are suggested for onramp/offramp support, including "VPIM=", "VOICE=" and "AMIS=".
VPIM v3 Profile <draft-ema-vpimv3-00.txt>
This presentation introduced and summarized the contents of the VPIM v3 draft. VPIM v3 will be a superset of VPIM v2 that is intended to support the huge installed base of desktops by unifying both email and voicemail. It must inter-operate with any generic client. The differences between the two profiles are "mostly philosophical". It will profile the use of the G.726 codec + other(s) (tbd) such as MS-GSM, G.711. It will include capability negotiation and other new features.
Someone suggested keeping the number of codecs small to maximize interoperability.
Someone suggested that scalability may be an issue, and that file size may have a significant impact on the server, but it was noted that the average voice message is only about 250KB, and that in any case, file size will depend on the codec used.
We were reminded of the IETF rules regarding IPR -- that if there are any IPR issues surrounding a proposal it must be disclosed, or the member must withdraw from the IETF (RFC 2026). Microsoft previously disclosed the incompatibility of MS-GSM with other GSM 6.10 implementations and stated that it was exploring the possibility of providing an IPR-free definition of MS-GSM, pending resolution of any IPR issues. In the BOF, Microsoft indicated that it was actively working on a such a resolution, but was unable to provide a resolution date. Possible adoption of the MS-GSM codec in VPIM v3 depends on the availability of an IPR-free definition of MS-GSM. It was noted that the G.723 codec has virtually been eliminated from consideration due to IPR. VPIM v3 may proceed simply with only G.726 and G.711 profiled. For capability negotiation, the profile may pick up the work in conneg.
VPIM v3 clearly states that the Primary Content of a VPIM message must be delivered or NDN'ed. Discard rules for other body parts are profiled. Alternatives to the primary content concept were again discussed, such as tagged multipart/mixed or multipart/related. A content disposition parameter could be used.
VPIM v3 introduces both send and receive rules, which will ensure consistent behaviour between systems.
The vCard is an essential body part as it enables a voice-message plug-in to reply to a VPIM message.
There were suggestions that there is no need to progress VPIM v2 if it is being superceded by VPIM v3 (i.e. deprecate VPIM v2). But VPIM v3 is a superset of VPIM v2, not a replacement. Furthermore, VPIM v2 is, and will continue to remain, useful in its domain (server-server).
There was consensus to form a VPIM working group as this will provide change control and considerable email experience to the profile development. The VPIM profile is currently being developed within the voice messaging committee of the EMA. The EMA technical meetings are open to everyone- you don't need to be a member. The committee meetings will be considered to be interim WG meetings. Minutes will need to conform to IETF standards. Meeting announcements must be posted to the IETF.