doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc4417.txt b/doc/rfc/rfc4417.txt
new file mode 100644
index 0000000..21c5f51
--- /dev/null
+++ b/doc/rfc/rfc4417.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+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]
+