Request for Comments: 4417 IAB
Category: Informational P. Saint-Andre, Ed.
JSF
February 2006
Report of the 2004 IAB Messaging Workshop
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document reports the outcome of a workshop held by the Internet
Architecture Board (IAB) on the future of Internet messaging. The
workshop was held on 6 and 7 October 2004 in Burlingame, CA, USA.
The goal of the workshop was to examine the current state of
different messaging technologies on the Internet (including, but not
limited to, electronic mail, instant messaging, and voice messaging),
to look at their commonalities and differences, and to find
engineering, research, and architectural topics on which future work
could be done. This report summarizes the discussions and
conclusions of the workshop and of the IAB.
Table of Contents
1. Introduction ....................................................3
2. Methodology .....................................................4
3. Issues ..........................................................5
3.1. Authorization ..............................................5
3.2. Multiple Communication Channels ............................6
3.3. Negotiation ................................................8
3.4. User Control ...............................................9
3.5. Message Transport ..........................................9
3.6. Identity Hints and Key Distribution .......................10
4. Recommendations ................................................11
4.1. Authorization .............................................11
4.2. Multiple Communication Channels ...........................12
4.3. Negotiation ...............................................13
4.4. User Control ..............................................13
4.5. Message Transport .........................................14
4.6. Identity Hints and Key Distribution .......................16
5. Security Considerations ........................................16
6. Acknowledgements ...............................................16
Appendix A. Participants .........................................17
Appendix B. Pre-Workshop Papers ..................................18
1. Introduction
Current email infrastructure is a mixture of facilities to accomplish
its task of end-to-end communications through a relay mesh. That
mixture has come about as requirements have changed over the years.
Discussions recur over the years, often including complaints that
some desired features of email (such as internationalization,
efficient encoding of structured data, trusted communication) are
ill-served by the current infrastructure, or that some of the current
infrastructure seems to be adversely affected by current problems on
the Internet (most recently including problems such as spam, viruses,
and lack of security infrastructure). For many years, the daunting
task of revamping email infrastructure has been considered, with
justifiably little enthusiasm for taking on such a task. However,
there has been some recent informal discussion on the kinds of things
that would be desirable in a "next generation" email.
At the same time, other messaging infrastructures (including those
associated with "instant messaging" and "web logging") are currently
being deployed that appear to address many of the above desired
features and outstanding problems, while adding many features not
currently considered part of traditional email (like prior-consent-
based acceptance of messages). However, each of these technologies
(at least in their current deployment) seem to lack some of the
features commonly associated with email (such as selective and
partial message delivery, queued multi-hop relaying, offline message
management, and efficient non-textual content delivery).
The Internet Architecture Board (IAB) believed that the time was ripe
to examine the current state of messaging technologies on the
Internet and to see if there are areas of work that can be taken on
to advance these technologies. Therefore, the IAB held a workshop on
Internet messaging, taking some of the above issues as input, in
order to formulate some direction for future study of the area of
messaging.
The topic of messaging is broad, and the boundaries of what counts as
messaging are not always well-defined. Rather than limit themselves
to a philosophical discussion of the nature of messages, the workshop
participants adopted the attitude of "we know it when we see it" and
used as their primary examples such well-established types of
messaging as email and instant messaging (IM), while also discussing
more "peripheral" types of messaging such as voice messaging and
event notifications. (Message queuing systems with guaranteed
delivery and transactional integrity, such as those used in
enterprise workflow engines and some "web services" architectures,
were operationally if not intentionally out of scope.) The
participants worked to discover common themes that apply to all the
types of messaging under consideration. Among the themes identified
were the following:
o Authorization of senders and recipients
o Negotiation of messaging parameters
o Consent models and privacy
o Identity hints, reputation, and key distribution
o Cross-protocol unification of messaging models
o Enabling greater user control over messaging
o Transport issues (unreliable links, push/pull, etc.)
o Message organization (e.g., conversations and threading)
Purposely missing from the foregoing list is the topic of unsolicited
commercial email or unsolicited bulk email (UCE or UBE, colloquially
known as "spam") and analogous communications in other messaging
environments such as instant messaging ("spim") and Internet
telephony ("spit"). While this topic was an impetus for the IAB’s
holding the workshop, it was kept off the workshop agenda due to
concerns that it would crowd out discussion of other messaging-
related issues. The more general topics of authorization and
identity were thought to be broad enough to cover the architectural
issues involved with spam without devolving into more unproductive
discussions.
This document is structured so as to provide an overview of the
discussion flow as well as proposed recommendations of the workshop.
Section 3 summarizes the discussions that occurred during the
workshop on various topics or themes, while Section 4 provides an
overview of recommended research topics and protocol definition
efforts that resulted from the workshop. Section 5 provides some
perspective on the security-related aspects of the topics discussed
during the workshop. Appendix B lists the pre-workshop topic papers
submitted by workshop participants as background for the workshop
discussions.
2. Methodology
Prior to the workshop, brief topic papers were submitted to set the
context for the discussions to follow; a list of the papers and their
authors is provided in Appendix B of this document.
During the workshop itself, discussion centered on several topics or
themes, as summarized in the following sections. Naturally, it was
not possible in a two-day workshop to treat these topics in depth;
however, rough consensus was reached on the importance of these
topics, if not always on the details of potential research programs
and protocol standardization efforts that might address the issues
raised. It is hoped that these summaries will inspire work by
additional investigators.
The in-workshop discussions quite naturally fell into three kinds of
"tracks": (1) possible engineering tasks to recommend to the IESG and
other standardization groups, (2) "blue sky" research topics to
recommend to the IRTF and other researchers, and (3) general
architectural or "framework" issues for consideration by both
engineers and researchers alike. After a full-group discussion each
morning to identify possible topics for more in-depth investigation,
participants self-selected for involvement in one of three "break-
out" sessions. Toward the end of each day, the full groups
reconvened, gathered reports from the break-out discussion leaders,
and attempted to come to consensus regarding lessons learned and
recommendations for further research. The results of the two-day
workshop therefore consist of discussion issues and research/
engineering recommendations related to the six topics described in
this report.
3. Issues
3.1. Authorization
It is one thing for a sender to send a message, and another thing for
the intended recipient to accept it. The factors that lead a
recipient to accept a message include the identity of the sender,
previous experience with the sender, the existence of an ongoing
conversation between the parties, meta-data about the message (e.g.,
its subject or size), the message medium (e.g., email vs. IM), and
temporal or psychological factors. Authorization or acceptance
applies most commonly at the level of the message or the level of the
sender, and occasionally also at other levels (conversation thread,
medium, sender domain).
Traditionally, sender authorization has been handled by recipient-
defined block and allow lists (also called "blacklists" and
"whitelists"). Block lists are of limited value, given the ease of
gaining or creating new messaging identities (e.g., an email address
or IM address). Allow lists are much more effective (since the list
of people you like or want to communicate with is smaller than the
large universe of people you don’t), but they make it difficult for a
sender to initiate communication with a new or previously unknown
recipient. The workshop participants discussed several ways around
this problem, including reputation systems and better ways for one
person to introduce another person to a third party (e.g., through
signed invitations).
Reputation systems may be especially worthy of future research, since
they emulate a pattern that is familiar from real life. (It may also
be valuable to distinguish between (1) reputation as the reactive
assessment of a sender created by one or more recipients based on
message history and (2) accreditation as a proactive assessment
provided by trusted third parties.) Reputation might be based on
summing an individual’s "scores" provided by recipients on the
network. (Naturally, the more important reputation becomes, the more
bad actors might attempt to sabotage any given reputation system, so
that a distributed as opposed to centralized system might be more
desirable.) The actions taken by any given recipient based on the
sender’s reputation would not necessarily be limited to a simple
allow/deny decision; more subtle actions might include placing
messages from individuals with lower reputation scores into separate
inboxes or redirecting them to other media (e.g., from IM to email).
3.2. Multiple Communication Channels
It is a fact of life that many people use multiple forms of messaging
channels: phone, email, IM, pager, and so on. Unfortunately, this
can make it difficult for a sender or initiator to know the best way
to contact a recipient at any given time. One model is for the
initiator to guess, for example, by first sending an email message
and then escalating to pager or telephone if necessary; this may
result in delivery of redundant messages to the recipient. A second
model is for the recipient to publish updated contact information on
a regular basis, perhaps as one aspect of his or her presence; this
might enable the initiator to determine beforehand which contact
medium is most appropriate. A third model is for the recipient to
use some kind of "unifier" service that enables intelligent routing
of messages or notifications to the recipient based on a set of
delivery rules (e.g., "notify me via pager if I receive a voicemail
message from my boss after 17:00").
The workshop participants did not think it necessary to choose
between these models, but did identify several issues that are
relevant in unifying or at least coordinating communication across
multiple messaging channels:
o While suppression of duplicate messages could be enabled by
setting something like a "seen" flag on copies received via
different messaging media, in general the correlation of multi-
channel, multi-message exchanges is not well supported by existing
standards.
o A recipient could communicate his or her best contact mechanism to
the initiator by explicitly granting permission to the initiator,
perhaps by means of a kind of "authorization token".
o It may be worthwhile to define frameworks or protocols for
recipient-defined delivery rules. Currently, routing decisions
tend to be made mostly by the sender through the choice of a
messaging channel, but in the future the recipient may play a
larger role in such decisions.
o The logic behind contact publication needs to be explored, for
example, whether it is an aspect of or extension to presence and
whether contact addresses for one medium are best obtained by
communicating in a different medium ("email me to get my mobile
number").
A multiplicity of delivery channels also makes it more complex for a
senders to establish a "reliable" relationship with a recipient.
From the sender’s point of view, it is not obvious that a recipient
on one channel is the same recipient on another channel. How these
recipient "identities" are tied together is an open question.
Another area for investigation is that of recipient capabilities.
When the sender does not have capability information, the most common
result is downgrading to a lowest common denominator of
communication, which seriously underutilizes the capabilities of the
entire system. Previous standards efforts (e.g., LDAP, Rescap,
vCard, Conneg) have attempted to address parts of the capability
puzzle, but without great success.
The existing deployment model uses several out-of-band mechanisms for
establishing communications in the absence of programmatic
capabilities information. Many of these mechanisms are based on
direct human interaction and social policies, which in many cases are
quite efficient and more appropriate than any protocol-based means.
However, a programmatic means for establishing communications between
"arms length" parties (e.g., business-to-business and business-to-
customer relationships) might be very beneficial.
Any discussion of relationships inevitably leads to a discussion of
trust (e.g., "from what kinds of entities do I want to receive
messages?"). While this is a large topic, the group did discuss
several ideas that might make it easier to broker communications
within different relationships, including:
o Whitelisting is the explicit definition of a relationship from the
recipient’s point of view, consisting of a list of senders with
whom a recipient is willing to engage in conversation. While
allow lists can be a workable solution, they are a relatively
static authorization scheme.
o Token-based authorization enables the recipient to define a one-
time or limited-time relationship with a sender. The issuer
possesses a token that grants a limited-time right to communicate
with the recipient. This is a more dynamic authorization scheme.
o Rule-based authorization involves an algorithmic assessment of the
viability of a relationship based on a wide set of criteria. This
is a more general authorization scheme that can incorporate both
allow lists and tokens, plus additional evaluation criteria such
as message characterization and issuer characterization.
3.3. Negotiation
In the area of negotiation, the workshop participants focused mainly
on the process by which a set of participants agree on the media and
parameters by which they will communicate. (One example of the end
result of such a "rendezvous" negotiation is a group of colleagues
who agree to hold a voice conference, with a textual "groupchat" as a
secondary communications channel.) In order to enable cross-media
negotiation, it may be necessary to establish a bridge between
various identities. For example, the negotiation may occur via
email, but the communication may occur via phone, and in order to
authorize participants the conference software needs to know their
phone numbers, not their email addresses. Furthermore, the
parameters to be negotiated may include a wide variety of aspects,
including:
o Prerequisites for the communication (e.g., distribution of a
"backgrounder" document).
o Who will initiate the communication.
o Who will participate in the communication.
o The primary "venue" (e.g., a telephone number that all
participants will call).
o One or more secondary venues (e.g., a chatroom address).
o Backup plans if the primary or secondary venue is not available.
o The topic or topics for the discussion.
o The identities of administrators or moderators.
o Whether or not the discussion will be logged or recorded.
o Scheduling of the event, including recurrence (e.g., different
instances may have different venues or other details).
Indeed, in some contexts it might even be desirable to negotiate or
re-negotiate parameters after communication has already begun (e.g.,
to invite new participants or change key parameters such as logging).
While the workshop participants recognized that in-depth negotiation
of a full set of parameters is likely to be unnecessary in many
classes of communication, parts of a generalized framework or
protocol for the negotiation of multiparty communication might prove
useful in a wide range of applications and contexts.
3.4. User Control
A common perception among "power users" (and, increasingly, average
users) on the Internet is that messaging is not sufficiently under
their control. This is not merely a matter of unsolicited
communications, but also of managing multiple messaging media and
handling the sheer volume of messages received from familiar and
unfamiliar senders alike. Currently, individuals attempt to cope
using various personal techniques and ad hoc software tools, but
there may be an opportunity to provide more programmatic support
within Internet protocols and technologies.
One area of investigation is message filtering. Based on certain
information -- the identity of the sender and/or recipient(s), the
sender’s reputation, the message thread or conversational context,
message headers, message content (e.g., the presence of attachments),
and environmental factors such as time of day or personal mood -- a
user or agent may decide to take one of a wide variety actions with
regard to a message (bounce, ignore, forward, file, replicate,
archive, accept, notify, etc.). While it is an open question how
much formalization would be necessary or even helpful in this
process, the workgroup participants identified several areas of
possible investigation:
o Cross-media threads and conversations -- it may be helpful to
determine ways to tag messages as belonging to a particular thread
or conversation across media (e.g., a forum discussion that
migrates to email or IM), either during or after a message
exchange.
o Communication hierarchies -- while much of the focus is on
messages, often a message does not stand alone but exists in the
context of higher-level constructs such as a thread (i.e., a
coherent or ordered set of messages within a medium), a
conversation (i.e., a set of threads that may cross media), or an
activity (a set of conversations and related resources, such as
documents).
o Control protocols -- the workgroup participants left as an open
question whether there may be a need for a cross-service control
protocol for use in managing communications across messaging
media.
3.5. Message Transport
Different messaging media use different underlying transports. For
instance, some messaging systems are more tolerant of slow links or
lossy links, while others may depend on less loss-tolerant transport
mechanisms. Integrating media that have different transport profiles
can be difficult. For one, assuming that the same addressing
endpoint represents the same entity over time may not be warranted
(it is possible that further work in identifying, addressing, and
discovering endpoints may be appropriate, even at the URI level). It
is also possible that the same endpoint or entity could be available
via different transport mechanisms at different times, or even
available via multiple transports at the same time. The process of
choosing an appropriate transport mechanism when there are multiple
paths introduces addressing issues that have not yet been dealt with
in Internet protocol development (possible heuristics might include
predictive routing, opportunistic routing, and scheduled routing).
For links that can be unreliable, there may be value in being able to
gracefully restart the link after any given failure, possibly by
switching to a different transport mechanism.
Another issue that arises in cross-media and cross-transport
integration is synchronization of references. This applies to
particular messages but might also apply to message fragments. It
may be desirable for some message fragments, such as large ancillary
data, to be transported separately from others, for example small
essential text data. Message fragments might also be forwarded,
replicated, archived, etc., separately from other parts of a message.
One factor relevant to synchronization across transports is that some
messaging media are push-oriented (e.g., IM) whereas others are
generally pull-oriented (e.g., email); when content is pushed to a
recipient in one medium before it has been pulled by the recipient in
another medium, it is possible for content references to get out of
sync.
If message fragments can be transported over different media,
possibly arriving at separate times or through separate paths, the
issue of package security becomes a serious one. Traditionally,
messages are secured by encrypting the entire package at the head end
and then decrypting it on the receiving end. However, if we want to
allow transports to fragment messages based upon the media types of
the parts, that approach will not be feasible.
3.6. Identity Hints and Key Distribution
While it is widely recognized that both message encryption and
authentication of conversation partners are highly desirable, the
consensus of the workshop participants was that current business and
implementation models in part discourage deployment of existing
solutions. For example, it is often hard to get new root
certificates installed in clients, certificates are (or are perceived
to be) difficult or expensive to obtain, one-click or zero-click
service enrollment is a worthy but seemingly unreachable goal, and
once one has created a public/private key pair and certified the
public key, it is less than obvious how to distribute that
certificate or discover other people’s certificates.
One factor that may make widespread message encryption more feasible
is that email, instant messaging, and Internet telephony have quite
similar trust models. Yet the definition of communication differs
quite a bit between these technologies: in email "the message is the
thing", and it is a discrete object in its own right; in telephony
the focus is on the real-time flow of a conversation or session
rather than discrete messages; and IM seems to hold a mediate
position since it is centered on the rapid, back-and-forth exchange
of text messages (which can be seen as messaging sessions).
Another complicating factor is the wide range of contexts in which
messaging technologies are used: everything from casual conversations
in public chatrooms and social networking applications, through