VPIM BOF Minutes IETF 47, Adelaide March 27, 2000 Minutes by: John W Noerenberg II The usual agenda bashing left the agenda intact. During the meeting we reviewed our WG status, covered VPIM v2 status, and discussed the outstanding drafts for VPIM v3. The drafts included: draft-ema-vpim-address-01.txt draft-ema-vpimdir-schema-01.txt draft-vaudreuil-vpimdir-avs-00.txt draft-ema-vpimv3-goals-01.txt draft-ema-vpim-simplev3-01.txt draft-ema-vpim-voicemsg-00.txt draft-ema-vpim-pndn-01.txt draft-vaudreuil-enum-e164-00.txt draft-ema-vpim-imap-01.txt Glenn indicated that VPIM should be a WG shortly, they are waiting for the new Apps AD to take over before creating new WGs. Glenn's draft include changes necessary to advance VPIM v2 to DRAFT status. Some changes remain to be made. In addition, v2 is gated by some normative references which are not yet ready to advance to DRAFT. VPIM v2 contains normative references to the vCard PROPOSED STANDARD, RFC 2426. It must be clear that use of vCARD is optional to remove the dependency on vCard's progress. These include the update to RFC 1830 (binary data in MIME), and RFC 2298 (message disposition notification), and RFC 1327 (X.400 - 822 mapping). Advance of RFC 2298 depends on interoperability verification for MDNs which are unrelated to VPIM. The VPIM WG needs to monitor MDN's progress. John Noerenberg, Graham Klyne, Emily Candel, Greg White have volunteered to investigate MDN's status further. A similar situation exists for RFC 1894 et al (delivery status notification). Greg agreed to discuss moving this forward with co-author Keith offline. Normative references to RFC 1327 are not needed. The attendees concurred the language can be changed to eliminate the reference to RFC 1327. We discussed what to do in the case that some part of a multipart/voice message was unrenderable. The discussion was between whether the uninterpretable part should be discarded, or if the entire message should be rejected. The attendees at the meeting recommended that compliant implementations should render as much of the message as possible. The protocol should specify which part types are acceptable, and that other types should not be sent. In particular, text/directory is an acceptable type. Glenn led a brief discussion about the address draft. He presented the format of service selectors based on RFC 2303 and outlined their use. Some of the attendees questioned what additionally utility this offered over MIME labeling in the body. We moved on without resolving this question. Next we considered the schema draft and vpimdir. Both of these drafts have similar goals, but provide slightly incompatible schema methods. Greg offered to attempt resolving the differences. We considered the enum draft. This is subsumed by the ENum WG. The AD recommended the problem addressed in this draft should be incorporated into the protocol(s) developed by ENum. The VPIM WG would be left with describing how the VPIM application uses the Enum protocol. Glenn introduced discussion of the Goals document. The attendees considered whether VPIM v3 should be a revision of V2 or something more focused on Internet Voice Mail (IVM). The goals document doesn't require compliance with the v2 protocol. We discussed whether the delivery semantics should permit messages parts to be delivered or whether messages should be rejected if any part is undeliverable. The semantics concerning sensitivity labels need to encompass the possibility that legacy systems will not interpret v3 labeling. During discussion of the goals, we discussed whether there exist any encumbrances over the use of WAV. Someone asserted that Microsoft will indeed release WAV for use. However, Jutta Degener raised the possibility that Phillips has a patent over the GSM 6.10 encoder/decoder (Pat #4932061). This must be investigated further. We next turned our attention to the simplev3 and voicemsg drafts. These seem to overlap in purpose. Glenn agreed to take on the task of reconciling the two and producing a single successor. Eric Burger led a discussion of the PNDN draft. Partial Non-Delivery- Notifications are motivated by the perceived desire of senders to know what parts of a message are deliverable to a receiver, especially for legacy systems. During the discussion some attendees raised questions over the efficacy of PNDNs compared to DSNs and worried about whether legacy systems could usefully employ them. They indicated that there are several obstacles to realizing the aims of partial delivery notification. We were running out of time, extended discussion was not possible. We briefly discussed the IMAP extensions for VPIM, and recommended that be offered as a personal submission rather than as a WG document. There were a number of topics which could not be discussed as extensively as those attending the meeting would have liked. As a result, Glenn invited the attendees to organize Bar BOFs to continue the topics, in particular one to examine the IVM / VPIM v3 goals. With our business concluded, we were chased out by the group eager to get on with the next meeting. Besides, the promise of tea and biscuits was making the natives restless. So we fled the room.