Stuart McRae (stuart.mcrae@uk.ibm.com)
Tue, 20 Nov 2001 10:59:10 +0000
All,
As part of doing the revision of the IVM draft, I reviewed this entire
thread again. As a result, I have decided not to make any IVM changes
since I do not see any consensus on the list in support of Andrew's
position.
I do entirely sympathise with the problem (as do the others). However I
cannot support a solution which introduces an additional attachment into
the message since I believe that has a negative impact on the usability of
the resulting system. We should be working as a community of implementers
to get rid of the random attachments that inflict our users (especially in
an era of viruses), not architecting them into solutions. Even if it takes
some time, it is better to produce a clean solution, and then evolve the
clients to support it, than to put in a kludge we would have to live with
forever.
With respect to addressing the problem described, I believe there are two
aspects to it - indicating that this is a voice message, and ensuring that
the voice content can be processed.
There are solutions today which are able to categorise voice, fax and
e-mail messages successfully based on the presence of attachments of
different types (either indicated by the content type of the file
extension of the attachments). This approach has some problems (e.g. the
audio attachment might be a song not a voicemail message) and we need to
evolve towards a solution to that issue. With IVM, this is addressed using
the Message Context, which can be seen as overriding categorisation based
on message attributes, and so making that categorisation more reliable in
the long term as more and more originators and recipients adopt it - and,
specifically, relay it when forwarding messages.
The larger problem is that some UAs might render an attachment unusable by
removing the typing information when forwarding it (or not including it in
the first place). This is not a voicemail or IVM specific problem - at
least as I read Andrew's original problem statement. For example, the PC
on which I am typing this does not have Powerpoint installed on it, so
presumably as there is no handler for it a Powerpoint presentation is
going to be forwarded in a way that cannot be read by the recipient (or,
at least, it would be if the PC had installed Outlook on it!).
I am sorry, but I completely fail to see how anyone can consider an
implementation which loses perfectly valid typing information for a file
when forwarding that file as not having a bug. Any vendor who is serious
about supporting standards must be expected to fix a problem like that if
they are made aware of it, whether or not you can point to a line in a
standard that says it should work.
I believe that we are building IVM for use for the next hundred years, not
the next 3 years. If there is some pain necessary until the products get
fixed to implement a both usable and standard conformant mail environment,
then so be it. That is much better than building in a long term kludge to
our mail environment to fix the deficiencies of a few vendors products.
In the meantime, if there are folks that really think this problem needs
to be solved in the standards (and, as I said, I sympathise with the pain
and support the right of anyone to change things for the better), then I
believe this issue should be addressed in the general e-mail context, not
the Unified Messaging context (just as we created a generic message
context not a voice messaging specific one).
And I encourage anyone who suffers because their correspondents cannot
read attachments because of these problems to contact their UA vendors and
complain.
Regards,
Stuart
This archive was generated by hypermail 2.0b3 on Tue Nov 20 2001 - 13:08:54 IST