Re: draft-ema-vpimv3-goals-01.txt

Eric.Burger@centigram.com
Thu, 16 Mar 2000 11:05:08 -0500

See my e-mail on VPIM v3/IVM Goals. The summary is that VPIM and IVM
address two, distinct, orthogonal problems. Thus, interoperability between
VPIM version 2 voice mail systems should not be a requirement (4.1).

-=-=-=-=-=-
Section 4.1.1: Under the paragraph starting "Any codes included in the VPIM
version 3 specification..."

Typo: Need open parenthesis in first bullet: "... most platforms (Windows,
Unix, Mac)"

Third bullet: Must all codes be low complexity to decode? The typical 1999
computer (300MHz P-II) has far more compute power than the typical 1999
voice messaging system (233MHz Pentium). Worse yet, hundreds of users share
the voice messaging system simultaneously.

Fourth bullet: I had trouble with the language. Saying a conditional must
be true doesn't sound right. How about "At least one codec must (1) be low
complexity to encode."

-=-=-=-=-=-
Section 4.1.2

At the end of the second paragraph, we speak of discard rules to back down
from v3 (IVM) to VPIM v2. I would suggest that IVM is different than VPIM
v2. If we go this route, we don't need discard rules. Either the message
destination is another voice mail platform or an Internet client. If the
destination is another voice mail platform, VPIM is the appropriate
transport profile. If the message destination is an Internet client, IVM is
the appropriate transport profile.

The same is true for the rest of the section.

-=-=-=-=-=-
Section 4.2

???

-=-=-=-=-=-
Section 4.4
If IVM and VPIM are different, this section goes away.

This archive was generated by hypermail 2.0b3 on Thu Mar 16 2000 - 19:23:36 IST propriate for desktop (e.g. MS-GSM)
   o Internet mail semantics:
       - Messages marked Private should be Private, but may not be
       - Messages marked for Return Receipt may never get notification
         or get notification too soon
       - Not all body parts may be delivered
       - Client (not server) interprets PNDN, MDN, DSN messages
   o Assumes hostile, open Internet environment

What is the practical value of splitting VPIM and IVM? Trying to make IVM
backwards compatible with VPIM is incredibly complex. It also brings little
value. VPIM is different enough from Internet e-mail that the surgery
necessary to make VPIM e-mail friendly would cause VPIM to lose its
benefits for inter-voice messaging system transport. Likewise, adding VPIM
extensions to IVM really doesn’t advance the state of the art. Who has a
G.726 player on their Macintosh?

Therefore, I propose we embrace the differences between VPIM and IVM. We
should build upon the experiences of VPIM. We should strive to make IVM
look like VPIM, wherever possible and where it is useful. However,
interoperability should not be a goal. If a VPIM system wants to exchange
mail with Internet clients (e.g. desktops), it must support IVM.

This archive was generated by hypermail 2.0b3 on Thu Mar 16 2000 - 19:23:36 IST