Charles Eliot (charle@Exchange.Microsoft.com)
Mon, 3 Apr 2000 18:11:35 -0700
This is a valuable proposal.
To paraphrase the group's concensus in Adelaide: "IVM is basically about
multi-media messaging from desktop to desktop, with particular emphasis on
voice. The Internet messaging infrastructure - SMTP, RFC 822, MIME, etc -
already does a great job for multimedia content. There are, however, a few
well-targeted tweaks that will make it even better."
The current "tweak list" looks like this:
- Presentation characteristics (Graham's proposal)
- "Desktop-friendly" default codecs
- Big headers (Greg Vaudreuil is working on this)
- Critical/primary content indication (Emily Candell is working on this)
- Partial non-delivery notification (Eric Burger is working on this)
- Routing semantics (Glenn Parsons is working on this)
- ENUM
- RESCAP (IVM v2?)
- CONNEG (IVM v2?)
Not all of these will make this cut of IVM. Some tweaks might be too
ambitious for IVM v1, and there is debate about whether some of the
proposals superset others (e.g. Does the proposal for explicit presentation
characteristics in the message header superset the on/off ramp problems
addressed by the routing semantics proposals? Do explicit presentation
characteristics obviate the need for critical content identification?)
-----Original Message-----
From: Graham Klyne [mailto:GK@dial.pipex.com]
Sent: Saturday, April 01, 2000 6:03 PM
To: IETF VPIM List
Subject: [VPIM] Universal inbox message tagging
Folks,
Following offline discussions with a few VPIM/UM interested folks at this
week's IETF, I believe that some of the key goals for UM handling may have
become obscured. This message is an attempt to clarify those goals. There
are, of course, many other possible goals that may need to be
addressed: this note addresses a particular set for which there seems to
be a constituency demand, and which appear to be easily addressed.
To echo a sentiment heard in the halls of past IETF meetings: "I'm just
trying to get lunch here, not solve world hunger".
The Problem
-----------
Multimedia messaging systems receive messages that may be presented in
variety of ways; e.g. traditional e-mail uses simple text messages that
are displayed and edited by the recipient; fax uses images that might be
printed; voice messaging uses audio data that may be played through a
telephone handset; document transfer uses arbitrary data that is processed
and/or presented by a desktop computer application. Emerging and future
developments may deliver other forms of information that have their own
characteristics for user presentation (e.g. video messages, small text
messages).
A required characteristic for multimedia messaging systems is to collect
received messages in a "universal inbox", and to offer them to a user as a
combined list.
In the context of "unified messaging" different message media may have
different implied semantics. For example, some users may perceive
voicemail has an implicit assumption of urgency, so may wish to be able to
gather them together and process them before other messages; hence the
end-user receiving agent needs to be able to identify voicemail and
distinguish it from other messages.
The presentation characteristic of each message may be used for a number of
purposes:
- display to the user (e.g. by a suitably evocative icon along with other
summary fields)
- prioritizing and grouping messages in the inbox list,
- suggesting appropriate default handling for presentation,
- suggesting appropriate default handling for reply, forward, etc.,
- filtering the message list for presentation via limited-capability user
interfaces (e.g. there is no point in offering images when the user is
connected by a voice-only telephone user interface).
A problem faced by multimedia messaging systems is that it is not always
easy to decide the presentation characteristics of a received message. For
example:
- a message that contains audio and image data: is this a fax message that
happens to have some voice commentary, or is it a voice message that is
accompanied by some supplementary diagrams, or is it a fully multimedia
message in which all parts are expected to carry equal significance?
- a message containing text and audio data: is this an email with an MP3
music attachment, or is it a voice message that happens to have been
generated with an initial text header for the benefit of non-voice-enabled
e-mail receivers?
Thus, the issue of presentation characteristics may be related to message
media content, but is not the same thing:
(a) The media type used in a message is not sufficient to indicate
presentation characteristics. When multiple media types are present, which
one is to be used? Also what about distinguishing traditional e-mail text
and SMS messages? They are the same media type, but have different
presentation characteristics;
(b) The presentation characteristics will affect the relationship between
body parts: according to MIME, and for traditional e-mail, nothing is said
about the various parts' relative importance; but for certain kinds of
multimedia message, some parts may be significantly more important that
others.
The final point above wanders into territory covered by the "critical
content" debate. (I.e. the parts of a message that must be delivered for
successful transfer to be declared). At this time, I am not sure whether
or not such critical content marking should be part of the problem covered
here. Having mentioned this issue, I'll not make any further explicit
reference to it.
Dimensions of presentation variation
------------------------------------
The following matrix is offered by way of a "scenarios" summary for using
presentation characteristics information. A number of different kinds of
message are identified along the top of the matrix, and possible components
of variation in their treatment are noted down the left hand side.
e-mail SMS voicemail fax multimedia
--------------------+----------+----------+----------+----------+----------+
Inbox display * * * * *
annotation
(icon, etc.)
--------------------+----------+----------+----------+----------+----------+
Priority lower? high higher? high low
--------------------+----------+----------+----------+----------+----------+
Default PC PC, TEL,MPC PC,PRINT MPC
presentation/ MOBILE MOBILE
interface device
--------------------+----------+----------+----------+----------+----------+
Default reply/ ?....
forward handling
--------------------+----------+----------+----------+----------+----------+
Message selection PC MOBIL:push MPC,TEL PRINT:push MPC
for access from PC PC
limited interface
devices
--------------------+----------+----------+----------+----------+----------+
Where:
PC= personal computer - workstation with general computing capabilities
MPC= multimedia PC
MOBILE= mobile phone
TEL= telephone handset
PRINT= printer/fax
Some other possible variations in treatment not considered here:
Critical content -- loss in transfer infrastructure (MTAs, etc)
Critical content -- loss in user agent rendering
Critical content -- sender signalling which parts are
Partial delivery notifications
Partial disposition notifications
Terminology
-----------
I have talked about "presentation characeristics" as a way of trying to
avoid stepping in any minefields left over from previous messaging
wars. We may want a better term; here are a few suggestions for
alternatives:
Presentation characteristic
Message type
Presentation mode
Use intent
Content paradigm
Message paradigm
That's all folks. Thank you for your attention. You may now throw rocks.
#g
------------
Graham Klyne
(GK@ACM.ORG)
This archive was generated by hypermail 2.0b3 on Tue Apr 04 2000 - 04:11:38 IDT