IETF 45 VPIM BOF Minutes
Minutes taken by Stuart McRae <Stuart_McRae@lotus.com>
1. Welcome & Agenda Bashing
Several people indicated that they have been lost from the VPIM mailing list. Glenn will try to get EMA to put them all back.
In addition, Glenn will ensure that a link to the archive is put on the www.ema.org/vpimdir/index.html home page.
A mail archive is available for users who missed messages.
2. Charter Bashing
It was agreed at the last IETF that VPIM would be constituted as an IETF Working Group to facilitate cooperation with Internet Mail experts on VPIMv3.
The draft charter was reviewed, with the latest minor modifications.
There was discussion about the status of to the proposed additional "design meetings" at EMA. If they are purely to review proposals with the voice messaging industry, rather than to do design work, then this should be made clear so that people don't feel obligated to attend.
It was suggested that the addressing document should be standards track rather than informational.
There was concern that the goal as stated in the charter did not align precisely with the goal as defined in the goals document. It was agreed that these would be aligned, and that the text in the charter was preferable. It was also agreed that compatibility with VPIMv2 should be "where possible" rather than mandatory.
There was discussion around the use of the word "Profile" and it was agreed that this is a application of Internet Mail rather than a profile for Internet Mail, although it was proposed that the working group name not be changed.
It was further suggested that compatibility with Internet Fax should be a specific objective in the charter.
Other minor edits were agreed to the charter.
The room approved the charter as revised. The revised version will be sent to the last after Glenn has ensured that anyone who wished to re-subscribe is able to do so - contact Glenn if you are having problems with the list.
Later in the meeting it was further agreed that an explicit reference to fax would be added to the goals document, based around use of the Simple Mode fax RFC.
There was also discussion around the status of the IMAP extension, which is on a separate track within the VPIM WG (and remains there only because no-one else wanted to take it). There was consensus that IMAP extensions should NOT be required in the v3 document, but should be independent of the core standard.
3. VPIM v2 - Progression to Draft Standard (draft-ema-vpim-vpimv2r2-00.txt)
The distributed Draft was truncated and some appendices missing (including the list of changes). It will be resubmitted as a complete document (-01) before it is updated based on this meeting.
To progress to Draft Standard we need to:
- review initial clarification proposal
- generate report on implementations. Glenn will identify which features have be tested where in order to document interoperability of at least 2 implementations of every feature.
- determine the status of the referenced documents, and decide how to address the issues of any which are not yet Draft Standard. MDN was identified as an issue which may be addressed by driving forward that effort. vCard is another potential issue.
The VPIMv2 clarifications were then reviewed:
- The prose has been revised to use send and receive rules - a check is needed that this has been done systematically throughout.
- Addressing was clarified as followed...
- Non-mail-user was downgraded from MUST to SHOULD. Consensus in the room was that an empty FROM was illegal, but omitting the FROM in an embedded RFC822 message is acceptable.
- Reply-to use is discouraged
- Loss of Received headers in a gateway was downgraded to SHOULD NOT. The room felt that the document should call out that this should only be done when unavoidable.
Sensitivity
- Prohibition of forwarding a private message was downgraded from MUST to SHOULD
- ... but still MUST MDN if not supported.
A contrary view was presented that this should be left as MUST because it is only applicable to voicemail systems. It was agreed to take the discussion to the list.
There was concern in the room that downgrading all of these MUSTs to SHOULDs would require a rerun of the interoperability testing. The contrary view was that implementations could not rely on others using any of the specific features which have been downgraded.
vCard
- The Role was dropped as a MAY since no-one implemented it.
- It was proposed that the current "should" attach a spoken name should be changed to an "inline" spoken name. There are clearly advantages to supporting both forms, but this change would require cycling to Proposed Standard. One possible way an implementation could address the requirement would be to locally rewrite the vCard to include the spoken name inline. This will be discussed further on the list.
- The vCard now MAY be used for replies. DRUMS has come to the conclusion that you MAY use anything for replies, so this seems reasonable.
Fax
- Downgraded to MAY (from MUST NOT) discard the fax in order to deliver to the client - e.g. if it can deliver a message so some clients and not to others (but don't know which on reception) - but must indicate to the client that it has discarded the body part (on the assumption that the user could reread it with a different client).
- clarify action on receipt on non-voice content
4. VPIM v3
4.1 Goals (draft-ema-vpimv3-goals-00.txt)
The VPIM v3 Goals were reviewed.
Codecs were discussed at length. There was general agreement in the room that we needed less codecs. The choices were either to stay with one (G.726) and push to get it implemented on the desktops, or to add WAV/GSM as well. There was no support for other codecs. All the voicemail systems currently have to transcode from their proprietary codes to G.726, so they are more likely to be able to transcode than the recipient
Two codecs was seen as significantly better that 7 (3 x 2 encodings + G.726). If it is not possible to get consensus on one mandatory, then going to 7 alternative mandatories is not the answer.
The reason why WAV/GSM is the most attractive codec for VPIMv3 is that it supports almost all the desktops already deployed - Windows, Mac (in QuickTime) and various Unix. The IETF will not agree to put anything into a draft standard if they don't know how to deploy it.
Choices considered:
(1) be interoperable with VPIMv2 & make G.726 the mandatory codec
(2) go WAV/GSM to interoperate with the existing desktops, but lose interoperability with the deployed VPIMv2 systems
(3) require both, but this does not address the deployability concern of installing G.726 on all desktops.
There was strong support for option 2 because "Deployment experience shows you want to make it as easy as possible for the desktop clients as they are harder to get changes".
There was some support for options 1 and 3, based on: "Give us the codec code & we'll ship it".
In case 3 clients MUST send both, would allow interoperability with everyone, and make a deployment issue out of choosing which to send - it was assumed that everyone would default to sending WAV/GSM, but could resend G.726 if an NDN was returned (from a VPIMv2 server). For full interoperability with VPIMv2 would also have to be MUST receive G.726.
It was suggested that it would make sense to try to write a pure v3 specification first, and then decide what needs to change to be compatible with v2. It may also be appropriate to have two version: v3 and v3-with-v2-compatibility. If we separate v3 and v2+v3 than "n" years down the line we may be able to drop the v2+v3 requirements.
It was estimated that the deployed VPIMv2 capable servers will support around 100M voice mailboxes on hundreds of systems by the end of the year.
Consensus: if we must have V2 interoperability, then a V2+V3 environment requires send+receive G.726 & WAV/GSM, but a v3 only world would simply use WAV/GSM.
It was decided to take the room consensus on "go with the desktops" to the list.
The charter was reviewed again in the light of this discussion, and it was agreed that the primary goal should be interoperability with the deployed desktops. The secondary goal would be to specify of how this interoperates with v2 (rather than being backward compatible with v2).
<<<<the BOF resumed the following day>>>>
4.2 draft-ema-vpim-um-01
This document looks at how to identify a message as being a voice message by indicating "primary content", so that special clients could handle them specially, but others just see them as a regular series of attachments, particularly so as to ensure that voicemail semantics are applied to MDN generation by an aware client. There was a request for clarification on the issuing of DSNs and MDNs by the server and the client.
It is contended that current practice treats Multipart/mixed as primarily text.
On the other hand a multipart/voice-message might be expected to contain an audio part, a spoken name audio part, maybe a vCard, some fax parts, and maybe a forwarded audio message - hence the use of Multipart for this.
It was noted that this proposal is highly controversial. Particularly a whole series of different multimedia message types from different groups could create a problem.
The underlying requirement was clarified as: to identify the content as a voice or fax message, so you could: launch an appropriate helper app. Which receives all of the parts of the message for processing; deliver only the voice content to legacy voicemail; deliver only fax content if recipient is legacy fax; send NDN if voice or fax cannot be delivered; send partial NDN when content is dropped for delivery; indicate the message was "read" only when voice or fax part is played. It was proposed that an additional requirement was that for performance reasons this indication must be shown at the top level in the message.
There was also a suggestion that it would be attractive to have a separate indication of a voicemail message which was a call answer voicemail message (as a result of a failed call), as opposed to messages that were specifically generated as store and forward messages. This is because user's have a desire to handle these messages differentially. The issue of when the message is indicated as read is a local implementation issue, but some mechanism is required to indicate the desired semantics to help the client decide how it wants to handle the message.
An ad hoc team will meet during the week and propose an alternative mechanism to satisfy these requirements.
4.3 Addressing
Addressing preserves the VPIMv2 format for interoperability, but indicates that RFC 2303 service selectors that may be used for on-ramps and off-ramps. When neither VPIMv2 nor on-ramps/off-ramps are used, any addressing format may be chosen.
4.4 MSGSM Codec and WAV Specifications
An I-D has been published to document the Microsoft (as opposed to ETSI) version of GSM (draft-ema-vpim-msgsm-00.txt), and the definition of Wave and AUDIO/WAV (draft-ema-vpim-wav-00.txt) which is currently a de facto standard, not standardised.
4.5 Base VPIMv3 Document
Two variants exist - a long version (draft-ema-vpimv3-00.txt) and a short version (draft-ema-vpim-simplev3-00.txt). The long version does not profile Internet Mail features but simply refers to the existing documents. MDNs and DSNs are mandatory.
Work on Directory support is in progress (as a BCP).
The simple document abandons the primary content type and reverts to VPIM V2 multipart/voice-message, but the requirement to partial MDNs and DSNs remains outstanding. This can be considered on the list if an alternative primary content type proposal is created.
5. IMAP Extensions for Voice Messaging (draft-ema-vpim-imap-01.txt)
The requirements identified in the I-D are: Binary Attachment Transfer (e.g. Binary Fetch); External Reference (e.g. TO keyword on Data); Alternate Codec request (e.g. Decode command); Streaming Audio Attachments (e.g. FETCH STREAM); Message length indication (e.g. parameter); Body Part Read indication (e.g. Seen per body part).
A request was made to ensure that there is a clear definition of what is trying to be achieved, as opposed to possible solutions.
The question of where this should be progressed will be considered at the IMAP meeting later in the week (see the minutes of that meeting for full details, but it was agreed there that the Binary Transfer activity would be transferred to that WG, but not the other requirements).
6. Close