Graham Klyne (GK@ninebynine.org)
Fri, 09 Feb 2001 07:29:52 +0000
Laile,
Thank you for your comments.
First, to address a couple of the general points you make:
- our proposal is intended to be agnostic with respect to multi- vs mono-
media content of messages, and to be of some assistance with all of
these. It is true that our initially defined message classes tend to be
for single media uses, but the extensibility here is precisely to allow for
multimedia and other cases as new requirements become clear. If you can
offer some specific proposals for multimedia message-context values, we
would be more than happy to consider them.
- this specification is, by very conscious intent, a small incremental
enhancement to the handling of diverse message types in email. It does not
attempt to solve every issue of multimedia messaging, because we really
don't think all the issues are sufficiently well understood. Rather, it
attempts to focus on one area in a very limited fashion, trying not to
stand in the way of other, more advanced multimedia specifications that may
follow. Our greatest concern is to not complicate life for those whose
designs may follow.
> > BACKGROUND:
> > The content seems to reflect many unstated assumptions.
We did try to make those assumptions explicit: sections 4 and 10 in
particular.
> > - What specific problem is the group resolving via the proposed
> > message-content header?
Actually, it's "message-context" (I mention this in case mis-reading the
name has created a different expectation of its intent).
Section 4 proposes six related but different uses.
> > - Why don't existing solutions work?
Section 4 goes on to explain. See also, section 6.
> > - What is the scope of the problem and proposed solution?
Section 2 pretty well covers this.
> > - What future scenarios should the solution support? How is the solution
> > likely to evolve to support future scenarios?
Through addition of new context values; see section 9. Also some of the
text in section 6.
Future scenarios are supported through the extensibility mechanism. I can
see that section 9 could usefully carry a few words about what would
reasonable be considered for a new message-context value.
> > - Who are the target implementers? UM vendors? VM vendors? UA vendors?
Er, yes -- anyone writing a UA that wants to communicate or use this kind
of contextual information.
> > - What assumptions are made regarding the requirements and usage
> > scenarios
> > of user agents and end users (both sending and receiving)?
Section 6.
> > 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
Actually, I happen to believe that RFC2119 keywords are very confusing for
describing requirement levels: they are intended for setting out
requirements of an implementation with respect to the features of a
specification.
> > 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.
I'm not aware that we use any of these terms in unusual or special
ways. However, a terminology section cannot harm.
> > - 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.
Actually, I kind-of agree with this... a point for us to revisit, I think.
> > POTENTIAL SOLUTIONS:
> > Has the following alternative already been ruled out?
> > - Use of content-feature header
No. (By which I mean, not ruled out; however content-features is intended
for describing the media features of message content, which is a very
different matter from the overall context of the message. Content-features
is also considerably more complex to handle. I regard message-context as a
wholly orthogonal issue.)
> > - Use of content-disposition to indicate clearly what is message content
> > and
> > what is attachment
This, too, is an orthogonal issue. See section 2.
#g
This archive was generated by hypermail 2.0b3 on Fri Feb 09 2001 - 09:44:57 IST