Laile L. Di Silvestro (laile@unleashedworld.com)
Fri, 2 Feb 2001 16:44:37 -0800
Thanks for the work you all have put into this. I believe that resolving
some of the issues this draft broaches extend beyond the scope of VPIM, and
will be critical to the implementation of interoperable multimedia
messaging.
My comments are based on an underlying assumption that may not be shared by
the group: Mono-media messages, though still the norm, are no longer the
rule. There has been a proliferation of new terminals and user agents used
to generate and receive messages. These entities have varying capabilities
and have resulted in the content of messages evolving from text-only to
multiple media types, and many terminals already support the generation of
mixed-media messages. Gateways and servers are evolving to support automatic
conversion of data to support the varying terminal capabilities. Most
standards remain text-focused, however, and tend to assume mono-media
messages. The standards need to evolve quickly to support this new
multimedia environment.
My impression of the message-content proposal, is that it is intended to
resolve some of the difficulties associated with the rendering of multimedia
messages, particularly in desktop environments. Many desktop-based rendering
applications need to know whether a message contains video up front before
rendering the message. Visual interfaces that include list-based inboxes
need to be able to determine message content without parsing the entire
message.
While the message-content header resolves some issues associated with
multimedia messaging, I would like to see the proposal extended to cover
mixed media (rather than monomedia alone) and include the requirements of
terminals other than the desktop (such as web-enabled phones, videophones,
voice-only phones, etc).
My preliminary comments and questions follow:
BACKGROUND:
The content seems to reflect many unstated assumptions.
- What specific problem is the group resolving via the proposed
message-content header?
- Why don't existing solutions work?
- What is the scope of the problem and proposed solution?
- What future scenarios should the solution support? How is the solution
likely to evolve to support future scenarios?
- Who are the target implementers? UM vendors? VM vendors? UA vendors?
- What assumptions are made regarding the requirements and usage scenarios
of user agents and end users (both sending and receiving)?
GOALS & REQUIREMENTS:
I would like to see the goals of this solution more fully defined and
prioritized up front (using the RFC 2119 key words). Some suggestions:
- A set of concrete scenarios that the solution should support
- Feature requirements
- Performance requirements
- Interoperability including with legacy systems
- Terminal features to be supported
- VPIM and IFAX support
- Consistent/standard definition of contexts
DEFINITIONS:
- Please provide concrete definitions for terms whose meanings differ
depending on context or for which definitions are contested. Such terms
might include user agent, universal inbox, unified messaging, mixed-media
(vs. multimedia) messages, and user context.
- With the proliferation of terminals and user agents with varying
capabilities sending and receiving messages, the traditional definitions for
voice mail, fax message, multimedia message, and even message are no longer
universally accepted or applicable in some cases. More detailed definitions
and a more detailed discussion of user intent would help.
POTENTIAL SOLUTIONS:
Has the following alternative already been ruled out?
- Use of content-feature header
- Use of content-disposition to indicate clearly what is message content and
what is attachment
----- Original Message -----
Subject: [VPIM] I-D ACTION:draft-ietf-vpim-hint-02.txt
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-vpim-hint-02.txt
This archive was generated by hypermail 2.0b3 on Sat Feb 03 2001 - 02:42:21 IST