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.
|Done||  ||Document interworking VPIM v2 implementations|
|Done||  ||Issue updated drafts of IVM/VPIM v3 Goals, IVM/VPIM v3 Specification and related protocol documents as Internet Drafts|
|Done||  ||WG last call on VPIM v3 Goals as Informational RFC|
|Done||  ||Issue updated VPIM v2 Internet Draft|
|Done||  ||Issue updated Internet Drafts of VPIM directory|
|Done||  ||Issue updated Internet Drafts of VPIM addressing|
|Done||  ||Issue updated Internet Drafts of VPIM IMAP extensions|
|Done||  ||Issue revised VPIM v3 Specification and related protocol documents as Internet Drafts|
|Done||  ||WG last call on IVM Specification and related protocol documents as Proposed Standards RFCs|
|Done||  ||Submit IVM Goals to IESG for consideration as Informational RFC|
|Done||  ||Submit VPIM addressing to IESG for consideration as a Proposed Standard|
|Done||  ||WG last call on revised VPIM v2 for Draft Standard|
|Done||  ||Submit IVM et al to IESG for consideration as a Proposed Standard|
|Done||  ||WG last call on VPIM client extensions as Standards Track RFC|
|Done||  ||Submit VPIM v2 to IESG for consideration as a Draft Standard RFC|
|Done||  ||Submit VPIM IMAP client extensions to IESG for consideration as Standards Track RFC|
|Done||  ||WG last call on VPIM addressing as Standards Track RFC|
|Done||  ||WG last call on VPIM directory profile as Standards Track RFC|
|Done||  ||Submit VPIM addressing to IESG for consideration as Standards Track RFC|
|Done||  ||Submit VPIM directory to IESG for consideration as Standards Track RFC|
|Done||  ||WG last call on IVM/VPIM v3 content negotiation as Proposed Standard RFC|
|Done||  ||Submit VPIM content negotiation to IESG for consideration as Proposed Standard RFC|
|Done||  ||Review final work items and close|
Current Meeting Report
VPIM WG meeting, 53rd IETF, Minneapolis, Minnesota
Chair: Glenn Parsons <email@example.com>
Scribe: Greg White <firstname.lastname@example.org>
Voice Profile for Internet Mail:
VPIM v2 suite - Glenn presented a current status slide. Ned said he will get on the IESG to do their thing to get these published as RFCs.
VPIM v2 - Glenn mentioned the construction of a interoperability website for moving the VPIM v2 draft to draft standard. He suggested that it is time for another event due to new products being introduced. He asked for coordinator/host volunteers. Andy Zmolek said he would inquire about Avaya hosting the event.
VPIM Addressing - Glenn stated that IETF Last Call has ended, and this draft will hopefully be on the next IESG agenda.
VPIM Routing Service - Greg V. asked people to look at this draft. Current questions are:
> 1-stage vs. 2-stage query
> does the list of supported content types make any sense
> should we change schema to add a list of supported message context, he feels would be fuzzier, but more useful.
> should we add a list of supported codecs other than the required codec.
> how to extend attributes
This spec will need to be reviewed by the LDAP Directorate. The LDAP Directorate rules are unknown. Ned was not sure, but suspects that we need to just send a note to the directorate list asking for a review, and that we need to do this as soon as the changes are made. It was also determined that we could do a WG Last Call in parallel with the directorate review.
DSN/MDN suite - Greg V. presented status. The errors in the IANA References section should be fixed in a couple of weeks. Greg sent out some DSN interoperability questionnaires, and still needs to collate the received information. He still needs to send out MDN interoperability questionnaires. He will then revise the drafts and submit new interoperability reports. These drafts are currently in IESG review, and they will remain there after the
Internet Voice Mail:
IVM Goals - spec is approved, waiting for the rest of the IVM specs to through so they can move together.
IVM Profile - no changes, waiting on the subsequent dependencies to stabalize...
Critical Content - IESG noted a clash with RFC 3204, and they have requested that this spec be aligned with RFC 3204. So, there needs to be another version of the draft. Eric Burger outlined the following upcoming changes:
> CRITICAL will be changed to HANDLING=REQUIRED,
> IGNORE will be changed to HANDLING=OPTIONAL
> REQUIRED is the default value.
> Title change to "Critical Content MIME Parameter."
> Eric thought there also might have to be a change to some SIP document.
After the changes are made, give the spec back to Ned; we will probably have to resubmit for IETF Last Call.
Message Context - Ned said that some folks are unhappy and that complaints have been registered at IESG. The issue seems to be that this is OPES-like, that this is a mechanism for licensing content transformation. Ned said he would chase this issue down and get specific recommendations for changes. He said that maybe all we need is an applicability statement, and a statement that message context is not to be used for licensing content transformation.
Codecs - There are 2 drafts, one for MSGSM, and one that contains a formal definition of audio/wav, including a discussion of the RIFF header. WG consensus was that MSGSM-WAV and raw G.711 (audio/basic) are mandatory for receive and play. These drafts were supposed to be updated for the last meeting, but weren't. Also, the final Microsoft IPR statement has not appeared. Glenn asked the group what we should do next, noting that the group agreed, at the last meeting, to drop MSGSM from the spec if MS IPR was not resolved. The group voted to make G.711 the only mandatory codec. Discussion ensued on how to reference MSGSM-WAV in the spec. The consensus is to remove the reference, take up contrary comments on the list, and notify Charles Eliot. Pete Resnick asked what RFC 2026 says about this issue. Apparently, these drafts have not been reissued because MS lawyers had concerns with the standard draft boilerplate. MS has apparently resolved this issue, but they have not issued revised drafts. Glenn is to contact Charles about the matter.
IMAP Extensions - status given by Alexey Melnikov
> CHANNEL - there have been a couple of meetings, there is a list of issues with the spec, particularly with the ABNF. There was a proposal for a UID CHANNEL command. Question: can CHANNEL be used to channel the entire message? A suggestion was made to add a parameter for authorization, and a type label. Discussions ensued re. how to use CHANNEL. Eric is going to put some use cases in the spec. Eric asked if the CHANNEL stuff should be one or two specs. Ned said do as two specs, the CHANNEL use spec will be informational, and make sure the specs get Last Call'ed together. Shooting for Last Call by May 1.
> BINARY - in AD review.
> Msg structure query - currently trying to fix a problem in the base IMAP spec, and how to grab full message header data.
ENUM WG update - presented by Rich Shockey. The group is back in business and has been completely rechartered. The core action item relevant to VPIM is RFC2916bis. Other items are revising NAPTR's, and developing and IANA registration procedure for the ENUM service field (define the field and the regular expression). Rich asked for VPIM WG input on service-related issues - what are the barriers, instructions to IANA & IESG for review process. He also asked the group when we would like to see RFC2916bis completed, and can we define the VPIM NAPTR service field and behavior. Greg V. suggested our specs reference RFC 2916, and then re-issue our specs with references to 2916bis when the bis is completed, but hopefully timetables will coincide such that we can just reference 2916bis straightaway. It was mentioned that "mailto" & "vpimdir" are services that were defined some time ago. Greg V. stated that the will revise the VPIM Routing Service spec to reference 2916bis. He also has no problems with 2916bis procedures, but has problems with how SIP uses ENUM. Rich believes 2916bis will be in IESG review prior to the next meeting, which our WG believe aligns well with our work. Rich also asked that the VPIM Routing Service spec be reviewed by the ENUM group
Calling Line ID - Glenn made some minimal changes to the draft after the last meeting, and will propose this draft for Last Call after this meeting. If the CLID is blocked, it will not been seen (in order to allievate a SIP problem).
Voice Messaging IMAP Client Behavior - This draft is on Ned's plate to review.
SIP MWI - this is now a work item in the Sipping WG.
SNAP - Eli presented slides that covered the latest round of minor changes. Open issue binding SNAP to BEEP vs. HTTP, and attachment names/number. Ned cautioned about binding to HTTP because of firewall problems. He also stated that the security model better be well laid out, and do not discuss tunneling through firewalls. It is mandatory to use a port other than 80, and do not discuss traversing firewalls.
New work for Unified Messaging was proposed. Currently, the group refers to UM as "Pink Lemonade" because of all the baggage associated with the term "UM," and we don't have another name yet. Eric presented the following
- PL considerations:
> consolidate messaging systems
> enable sensible interfaces
> essential completion of VPIM & IFAX work
> investigate IVM, 3GPP, and MMS
- PL goals:
> reuse existing protocols
> maintain protocol integrity
> sensible message context
> preserve internet infrastructure
> meet real-time telephony requirements
> scalability, espically for video
He noted there is a mailing list for this, <email@example.com>.
Greg V. presented the folowing:
- PL performance requirements:
> real-time playback
> avoid Base64 data inflation
- PL functional limitations:
> message context in mailbox summary
> message context in mailbox search
> message context in mailbox quota
> functional conventions such as Inbox, Sent Items, Deleted Items, Expired Items
> CLID restriction indication & preservation
> commited delivery to full mailbox
- Message submission limitations:
> forward without download
> quota-by-context enforcement
> future delivery support
He also noted that there is profiling work to be done - i.e. "this is what you need to do to be PL-compliant."
Glenn present 3 WG options for Pink Lemonade work:
1) add items to FAX & VPIM WG charters as appropriate
2) create a new WG chartered for only the new work, and leave FAX/VPIM WG's to finish their remaining items.
3) create new WG that includes remaining FAX/VPIM items AND the new PL work.
Glenn noted that the FAX WG voted for option #3, and that the FAX/VPIM WG's could meet during the same slot during the next meeting, and create a new WG/BOF for PL. The VPIM group voted for the same thing. Ned said that we don't need a BOF; just send a charter to IESG in order to already have the WG formed by the next meeting. The plan is to flesh out this charter on the FAX/VPIM/PF lists, get AD/IESG approval, and be a new WG in Yokohama. Also, request one 2.5 hour slot for joint FAX/VPIM meeting. After the meeting, Glenn, Greg V., and Claudio took the action item to draft the new charter.
3GPP Multimedia Messaging Service - Ileana Leuca gave a presentation that overviewed the choices of messaging technology for the upcoming Release 5. Goal is to merge SMS/EMS with Internet email in the next release. There is a lot of synergy with desired work in Pink Lemonade, and the new WG really
needs to investigate PL-MMS interaction.
Required Extensions for Pink Lemonade
Multimedia Messaging Service
Smart Notification and Alarm Protocol (SNAP)
ENUM for VPIM Telephone Number Mapping