Andrew Hobson (andrew.hobson@cbeyond.net)
19 Oct 2001 14:39:11 -0400
The VPIM standard has a lot going for it. Using MIME to identify
voice mail messages is an elegant solution. It is what MIME was
designed for. Unfortunately, current MUA implementations destroy the
usefulness of VPIM.
When Outlook Express 5.50.4807.1700 forwards a MIME message, it
recreates the Content-Type for each attachment according to what it
thinks is correct based on the filename extension. For example, if
the first sample message in RFC 2421 is forwarded by OE, the
Content-Type of the attachment "msg1.726" will be set to
application/octet stream if no handler for the extension ".726" is
configured.
The implication of this is that UM products that use the VPIM RFC to
identify voice mail messages will not recognize voice mail that has
been forwarded via email by OE. Unfortunately, that makes the VPIM
RFC largely irrelevant if you want to have Unified Messaging today and
you want to use OE today.
It would behoove the VPIM community to come up with a standard that
will allow UM products to recognize voice mail messages that have been
forwarded using OE. Changing the behavior of OE would be ideal, but I
don't think that is a pragmatic solution. It's not clear that we
could get OE's behavior changed, and even if we could, it would take
too long for the new version to gain wide acceptance.
Any proposal should, IMHO, try to optimize for UM products that store
their messages in an IMAP store. I have a proposal, but it's not very
elegant. Ok, it's really a major hack. I won't flesh it out in full
detail, but I'll give enough detail (hopefully) that it will be a
starting point for a discussion. I'd love to see other opinions and
ideas.
Ideally, a UM product could use a IMAP SEARCH HEADER command to find
all voice messages. The current VPIM RFC facilitates this by
specifying that the Content-Type should be Multipart/Voice-Message.
Unfortunately, when an email is forwarded, the MUA chooses the
headers. I don't believe any solution that depends on a SEARCH HEADER
operation will work. That leaves two choices: use IMAP SEARCH BODY,
or use information provided by the IMAP FETCH command.
Having to do a full body search on each message will make scanning for
voice mails extremely slow when the IMAP folder is large. I don't
think that is a scalable solution.
Instead, I think we need to use IMAP FETCH to retrieve the MIME-IMB
body structure. A clever IMAP implementation could optimize retrieval
of the MIME-IMB body structure so that it does not need to scan the
entire message each time.
As I mentioned above, all MIME headers are destroyed by OE, so we
can't use any of them. The only thing that is preserved is the
filename.
I propose that an additional text attachment be included that contains
meta information that will be helpful to the UM application. The name
of that text file should be "vpim.txt". The contents of this text
file will be the MIME headers that *should* have been preserved.
A UM product that wishes to determine all voice messages can FETCH the
MIME-IMB body structure for every message. Again, a clever IMAP
implementation can optimize for this and make it a very fast
operation.
The UM product will examine the MIME-IMB body structures for any
message that has an attachment "vpim.text" and then examine only that
text attachment. If it has MIME headers that are conformant with the
VPIM RFC, then this is a voice message. This text file attachment
will specify the Content-Type and filename (again, according to the
VPIM RFC) for any attached voice messages so that the UM product will
be able to retrieve the appropriate attachment.
I believe this proposal will allow UM products to easily find all
voice messages in a particular IMAP folder.
I'd love to see true Unified Messaging deployed in the current,
imperfect MUA environment. Any comments, suggestions, feedback, and
brickbats are welcome.
Drew
This archive was generated by hypermail 2.0b3 on Fri Oct 19 2001 - 20:39:15 IST