GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4417

Network Working Group P. Resnick, Ed. 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.

Resnick & Saint-Andre Informational [Page 1] RFC 4417 IAB Messaging Workshop February 2006

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

Resnick & Saint-Andre Informational [Page 2] RFC 4417 IAB Messaging Workshop February 2006

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

Resnick & Saint-Andre Informational [Page 3] RFC 4417 IAB Messaging Workshop February 2006

 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

Resnick & Saint-Andre Informational [Page 4] RFC 4417 IAB Messaging Workshop February 2006

 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).

Resnick & Saint-Andre Informational [Page 5] RFC 4417 IAB Messaging Workshop February 2006

 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".

Resnick & Saint-Andre Informational [Page 6] RFC 4417 IAB Messaging Workshop February 2006

 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.

Resnick & Saint-Andre Informational [Page 7] RFC 4417 IAB Messaging Workshop February 2006

 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.

Resnick & Saint-Andre Informational [Page 8] RFC 4417 IAB Messaging Workshop February 2006

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

Resnick & Saint-Andre Informational [Page 9] RFC 4417 IAB Messaging Workshop February 2006

 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

Resnick & Saint-Andre Informational [Page 10] RFC 4417 IAB Messaging Workshop February 2006

 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
 communications between businesses and customers, to mission-critical
 business-to-business applications such as supply chain management.
 Different audiences may have different needs with regard to messaging
 security and identity verification, resulting in varying demand for
 services such as trusted third parties and webs of trust.
 In the context of communication technologies, identity hints --
 shared knowledge, conversational styles, voice tone, messaging
 patterns, vocabulary, and the like -- can often provide more useful
 information than key fingerprints, digital signatures, and other
 electronic artifacts, which are distant from the experience of most
 end users.  To date, the checking of such identity hints is intuitive
 rather than programmatic.

4. Recommendations

4.1. Authorization

 The one clearly desired engineering project that came out of the
 authorization discussion was a distributed reputation service.  It
 was agreed that whatever else needed to be done in regard to
 authorization of messages, at some point the recipient of the message
 would want to be able to check the reputation of the sender of the
 message.  This is especially useful in the case of senders with whom
 the recipient has no prior experience; i.e., using a reputation
 service as a way to get an "introduction to a stranger".  There was
 clearly a need for this reputation service to be decentralized;
 though a single centralized reputation service can be useful in some
 contexts, it does not scale to an Internet-wide service.

Resnick & Saint-Andre Informational [Page 11] RFC 4417 IAB Messaging Workshop February 2006

 Two potential research topics in authorization were discussed.
 First, a good deal of discussion centered around the use of
 whitelists and blacklists in authorization decision, but it was
 thought that research was necessary to examine the relative
 usefulness of each of the approaches fully.  It was clear to the
 participants that blacklists can weed out known non-authorized
 senders, but do not stop "aggressive" unwanted senders because of the
 ease of simply obtaining a new identity.  Whitelists can be useful
 for limiting messages to only those known to the recipient, but would
 require the use of some sort of introduction service in order to
 allow for messages from unknown parties.  Participants also thought
 that there might be useful architectural work done in this area.
 The other potential research area was in recipient responses to
 authorization decisions.  Upon making an authorization decision,
 recipients have to do two things: First, obviously the recipient must
 dispatch the message in some way either to deliver it or to deny it.
 But that decision will also have side effects back into the next set
 of authorization decisions the recipient may make.  The decision may
 feed back into the reputation system, either "lauding" or "censuring"
 the sender of the message.

4.2. Multiple Communication Channels

 Several interesting and potentially useful ideas were discussed
 during the session, which the participants worked to transform into
 research or engineering tasks, as appropriate.
 In the area of contact information management, the workshop
 participants identified a possible engineering task to define a
 service that publishes contact information such as availability,
 capabilities, channel addresses (routing information), preferences,
 and policies.  While aspects of this work have been attempted
 previously within the IETF (with varying degrees of success), there
 remain many potential benefits with regard to managing business-to-
 business and business-to-customer relationships.
 The problem of suppressing redundant messages is becoming more
 important as the use of multiple messaging channels becomes the rule
 for most Internet users, and as users become accustomed to receiving
 notifications in one channel of communications received in another
 channel.  Unfortunately, there are essentially no standards for
 cross-referencing and linking of messages across channels; standards
 work in this area may be appropriate.

Resnick & Saint-Andre Informational [Page 12] RFC 4417 IAB Messaging Workshop February 2006

 Another possible engineering task is defining a standardized
 representation for the definition and application of recipient
 message processing rules.  Such an effort would extend existing work
 on the Sieve language within the IETF to incorporate some of the
 concepts discussed above.
 Discussion of token-based authorization focused on the concept of
 defining a means for establishing time-limited or usage-limited
 relationships for exchanging messages.  The work would attempt to
 define the identity, generation, and use of tokens for authorization
 purposes.  Most likely this is more of a research topic than an
 engineering topic.
 Work on recipient rules processing and token-based authentication may
 be related at a higher level of abstraction (we can call it
 "recipient authorization processing").  When combined with insights
 into authorization (see Sections 3.1 and 4.1), this may be an
 appropriate topic for further research.

4.3. Negotiation

 Discussion in the area of negotiation resulted mostly in research-
 oriented output.  The session felt that participants in a
 conversation would require some sort of rendezvous mechanism during
 which the parameters of the conversation would be negotiated.  To
 facilitate this, a "conversation identifier" would be needed so that
 participants could identify the conversation that they wished to
 participate in.  In addition, there are at least five dimensions
 along which a conversation negotiation may occur:
 o  The participants in the conversation
 o  The topic for the conversation
 o  The scheduling and priority parameters
 o  The mechanism used for the conversation
 o  The capabilities of the participants
 o  The logistical details of the conversation
 Research into how to communicate these different parameters may prove
 useful, as may research into the relationship between the concepts of
 negotiation, rendezvous, and conversation.

4.4. User Control

 A clear architectural topic to come out of the user control
 discussion was work on activities, conversations, and threads.  In
 the course of the discussion, the user's ability to organize messages
 into threads became a focus.  The participants got some start on
 defining threads as a semi-ordered set of messages, a conversation as

Resnick & Saint-Andre Informational [Page 13] RFC 4417 IAB Messaging Workshop February 2006

 a set of threads, and an activity as a collection of conversations
 and related resources.  The discussion expanded the traditional
 notion of a thread as an ordered tree of messages.  Conversations can
 collect together threads and have them be cross-media.  Messages can
 potentially belong to more than one thread.  Threads themselves might
 have subthreads.  All of these topics require an architectural
 overview to be brought into focus.
 There is also engineering work that is already at a sufficient level
 of maturity to be undertaken on threads.  Though there is certainly
 some simple threading work being done now with messaging, it is
 pretty much useful only for a unidirectional tree of messages in a
 single context.  Engineering work needs to be done on identifiers
 that could used in threads that cross media.  Additionally, there is
 likely work to be done for messages that may not be strictly ordered
 in a thread.
 The topics of "control panels" and automated introductions were
 deemed appropriate for further research.

4.5. Message Transport

 A central research topic that came out of the transport session was
 that of multiple transports.  It was felt that much research could be
 done on the idea of transporting pieces of messages over separate
 transport media in order to get the message to its final destination.
 Especially in some high-latency, low-bandwidth environments, the
 ability to run parallel transports with different parts of messages
 could be extremely advantageous.  The hard work in this area is
 re-associating all of the pieces in a timely manner, and identifying
 the single destination of the message when addressing will involve
 multiple media.
 A common theme that arose in several of the discussions (including
 user control and message unification), but that figured prominently
 in the transport discussion, was a need for some sort of identifier.
 In the transport case, identifiers are necessary on two levels.
 Identifiers are needed to mark the endpoints in message transport.
 As described in the discussion, there are many cases where a message
 could reasonably be delivered to different entities that might all
 correspond to a single person.  Some sort of identifier to indicate
 the target person of the message, as well as identifiers for the
 different endpoints, are all required in order to get any traction in
 this area.  In addition, identifiers are also required for the
 messages being transported, as well as their component parts.
 Certainly, the idea of transporting different parts of a message over
 different mechanisms requires the identification of the containing
 message so that re-assembly can occur at the receiving end.  However,

Resnick & Saint-Andre Informational [Page 14] RFC 4417 IAB Messaging Workshop February 2006

 identifying the entire package is also necessary for those cases
 where duplicate copies of a message might be sent using two different
 mechanisms: The receiving end needs to find out that it has already
 received a copy of the message through one mechanism and identify
 that another copy of the message is simply a duplicate.
 Workshop participants felt that, at the very least, a standard
 identifier syntax was a reasonable engineering work item that could
 be tackled.  Though there exist some identifier mechanisms in current
 messaging protocols, none were designed to be used reliably across
 different transport environments or in multiple contexts.  There is
 already a reasonable amount of engineering work done in the area of
 uniform resource identifiers (URI) that participants felt could be
 leveraged.  Syntax would be required for identifiers of messages and
 their components as well as for identifiers of endpoint entities.
 Work on the general problem of identifier use might have some
 tractable engineering aspects, especially in the area of message part
 identifiers, but workshop participants felt that more of the work was
 ripe for research.  The ability to identify endpoints as belonging to
 a single recipient, and to be able to distribute identifiers of those
 endpoints with information about delivery preferences, is certainly
 an area where research could be fruitful.  Additionally, it would be
 worthwhile to explore the collection of identified message components
 transported through different media, while delivering to the correct
 end-recipient with duplicate removal and re-assembly.
 Package security was seen as an area for research.  As described in
 Section 3.5, the possibility that different components of messages
 might travel over different media and need to be re-assembled at the
 recipient end breaks certain end-to-end security assumptions that are
 currently made.  Participants felt that a worthwhile research goal
 would be to examine security mechanisms that could be used for such
 multi-component messages without sacrificing desirable security
 features.
 Finally, a more architectural topic was that of restartability.  Most
 current message transports, in the face of links with reliability
 problems, will cancel and restart the transport of a message from the
 beginning.  Though some mechanisms do exist for restart mid-session,
 they are not widely implemented, and they certainly can rarely be
 used across protocol boundaries.  Some architectural guidance on
 restart mechanisms would be a useful addition.

Resnick & Saint-Andre Informational [Page 15] RFC 4417 IAB Messaging Workshop February 2006

4.6. Identity Hints and Key Distribution

 It would be helpful to develop Internet-wide services to publish and
 retrieve keying material.  One possible solution is to build such a
 service into Secure DNS, perhaps as an engineering item in an
 existing working group.  However, care is needed since that would
 significantly increase the size and scope of DNS.  A more research-
 oriented approach would be to investigate the feasibility of building
 Internet-wide key distribution services outside of DNS.  In doing so,
 it is important to keep in mind that the problem of distribution is
 separate from the problem of enrollment, and that name subordination
 (control over what entities are allowed to create sub-domains)
 remains necessary.
 Research may be needed to define the different audiences for message
 security.  For example, users of consumer-oriented messaging services
 on the open Internet may not generally be willing or able to install
 new trusted roots in messaging client software, which may hamper the
 use of security technologies between businesses and customers.  By
 contrast, within a single organization it may be possible to deploy
 new trusted roots more widely, since (theoretically) all of the
 organization's computing infrastructure is under the centralized
 control.
 In defining security frameworks for messaging, it would be helpful to
 specify more clearly the similarities and differences among various
 messaging technologies with regard to trust models and messaging
 metaphors (e.g., stand-alone messages in email, discrete
 conversations in telephony, messaging sessions in instant messaging).
 The implications of these trust models and messaging metaphors for
 communications security have not been widely explored.

5. Security Considerations

 Security is discussed in several sections of this document,
 especially Sections 3.5, 3.6, 4.5, and 4.6.

6. Acknowledgements

 The IAB would like to thank QUALCOMM Incorporated for their
 sponsorship of the meeting rooms and refreshments.
 The editors would like to thank all of the workshop participants.
 Eric Allman, Ted Hardie, and Cullen Jennings took helpful notes,
 which eased the task of writing this document.

Resnick & Saint-Andre Informational [Page 16] RFC 4417 IAB Messaging Workshop February 2006

Appendix A. Participants

 Eric Allman
 Nathaniel Borenstein
 Ben Campbell
 Dave Crocker
 Leslie Daigle
 Mark Day
 Mark Crispin
 Steve Dorner
 Lisa Dusseault
 Kevin Fall
 Ned Freed
 Randy Gellens
 Larry Greenfield
 Ted Hardie
 Joe Hildebrand
 Paul Hoffman
 Steve Hole
 Scott Hollenbeck
 Russ Housley
 Cullen Jennings
 Hisham Khartabil
 John Klensin
 John Levine
 Rohan Mahy
 Alexey Melnikov
 Jon Peterson
 Blake Ramsdell
 Pete Resnick
 Jonathan Rosenberg
 Peter Saint-Andre
 Greg Vaudreuil

Resnick & Saint-Andre Informational [Page 17] RFC 4417 IAB Messaging Workshop February 2006

Appendix B. Pre-Workshop Papers

 The topic papers circulated before the workshop were as follows:
 Calendaring Integration (Nathaniel Borenstein)
 Channel Security (Russ Housley)
 Collaborative Authoring (Lisa Dusseault)
 Consent-Based Messaging (John Klensin)
 Content Security (Blake Ramsdell)
 Event Notifications (Joe Hildebrand)
 Extended Messaging Services (Dave Crocker)
 Group Messaging (Peter Saint-Andre)
 Identity and Reputation (John Levine)
 Instant Messaging and Presence Issues in Messaging (Ben Campbell)
 Large Email Environments (Eric Allman)
 Mail/News/Blog Convergence (Larry Greenfield)
 Messaging and Spam (Cullen Jennings)
 Messaging Metaphors (Ted Hardie)
 MUA/MDA, MUA/MSA, and MUA/Message-Store Interaction (Mark Crispin)
 Presence for Consent-Based Messaging (Jon Peterson)
 Rich Payloads (Steve Hole)
 Session-Oriented Messaging (Rohan Mahy)
 Spam Expectations for Mobile Devices (Greg Vaudreuil)
 Communication in Difficult-to-Reach Networks (Kevin Fall)
 Store-and-Forward Needs for IM (Hisham Khartabil)
 Syndication (Paul Hoffman)
 Transport Security (Alexey Melnikov)
 VoIP Peering and Messaging (Jonathan Rosenberg)
 Webmail, MMS, and Mobile Email (Randy Gellens)

Resnick & Saint-Andre Informational [Page 18] RFC 4417 IAB Messaging Workshop February 2006

Authors' Addresses

 Peter W. Resnick (Editor)
 Internet Architecture Board
 QUALCOMM Incorporated
 5775 Morehouse Drive
 San Diego, CA  92121-1714
 US
 Phone: +1 858 651 4478
 EMail: presnick@qualcomm.com
 URI:   http://www.qualcomm.com/~presnick/
 Peter Saint-Andre (Editor)
 Jabber Software Foundation
 P.O.  Box 1641
 Denver, CO  80201-1641
 US
 Phone: +1 303 308 3282
 EMail: stpeter@jabber.org
 URI:   http://www.jabber.org/people/stpeter.shtml

Resnick & Saint-Andre Informational [Page 19] RFC 4417 IAB Messaging Workshop February 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Resnick & Saint-Andre Informational [Page 20]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4417.txt · Last modified: 2006/02/22 22:28 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki