Re: [VPIM] VPIM in the real world


Andrew Hobson (andrew.hobson@cbeyond.net)
23 Oct 2001 16:03:41 -0400


"Glenn Parsons" <gparsons@nortelnetworks.com> writes:

Thank you for taking the time to reply.

> > We are investigating deploying a Unified Messaging product in the near
> > term, and we really would like our customers to be able to forward a
> > voice mail with their MUA and have it recognized as a voice mail, even
> > if only by our own customers. We aren't comfortable asking our
> > customers to change their MUA.
> >
> With IVM you don't have to.

[...]

> I do not understand how support for IVM (which does not require any
> changes in what you call the MUA) will not meet your requirements.
> Its goal (perhaps you should read the IVM Requirements draft) sounds
> to be the same as yours. Could you clarify?

My reading of draft-ietf-vpim-ivm-02.txt, Section 4 *does* specify
Mail User Agent behavior. For example, it says:

    Any content type is permitted in a message, but the top level
    content type on origination of a new, forwarded or reply voice
    message SHOULD be multipart/mixed.

So, while I believe that IVM is definately the way that MUAs should be
going, unfortunately they aren't there today.

Overall, I think we are probably on the same page. I see the
following in the VPIM meeting minutes from the 10 August meeting:

    * If a Message-context of voice-message is not required, what
      makes a message an Internet Voice Message? Does it have to
      contains an approved voice content type (or rather any voice
      content type, as this is permitted)? Can a message with no voice
      content be an IVM? This is permitted for a Message-context of
      voice-message, but does it make sense for an Internet Voice
      Message? This could be addressed by rewording the requirement on
      content type as follows: "An Internet Voice Message MUST contain
      at least one audio part, which may be at any location within a
      message and SHOULD be contained in either an audio/wav or
      audio/basic content-type - the only exception being when the
      originator is aware that the recipient can handle other
      content."

I'm trying to answer the first question: what makes a message an IVM?

I don't believe that the presense of audio/wav is sufficient to be
considered an IVM because an email message sent with a wav attachment
would be considered a voice message. That kind of false positive is
not acceptable, IMHO.

A more fundamental problem exists because wav attachments are not
guaranteed to show up as audio/wav. I'm going to use Outlook Express
as an example, since it is the MUA that most of our customers use.
I'm looking for a solution that will interoperate with its current
behavior.

When Outlook Express forwards an email with an attachment, as far as I
can tell it regenerates the content-type for each attachment based on
the file extension. If the user does not have a handler configured
for the wav extension, then the attachment will be of type
"application/octet-stream". Granted, most email users will probably
have a wav handler installed, but I would prefer not to depend on it.

The only headers OE sends along are From, To, Sent, and Subject, so
any header based solution (such as depending on message-context) would
not work. That doesn't leave many options.

That's why I proposed an additional text attachment that contained all
of the relevent information. It seems to me that it would be
reasonably flexible and relatively easy to implement.

Does my position make more sense now?

Drew



This archive was generated by hypermail 2.0b3 on Tue Oct 23 2001 - 22:03:47 IST