RFC 4417

Report of the 2004 IAB Messaging Workshop

📅 published February 2006, from ietf

RFC 4417: Report of the 2004 IAB Messaging Workshop 💌

okay bestie, let's get into it 🦋 This is RFC 4417, titled Report of the 2004 IAB Messaging Workshop. It's Informational, dated February 2006, and it's from the IAB (Internet Architecture Board) 🌸 P. Resnick, Ed. is the IAB editor and P. Saint-Andre, Ed. is the JSF editor. The title block doesn't list anything this document obsoletes or updates, so it stands on its own ✨

Status of This Memo

This memo gives information to the Internet community 📚 It does not specify an Internet standard of any kind, so nobody has to implement it to be compliant. Distribution is unlimited, so share it with everyone 💕

Copyright (C) The Internet Society (2006) ©️🎀

Abstract

okay so this doc reports what came out of a workshop the IAB ran on the future of Internet messaging 💬 It happened on 6 and 7 October 2004 in Burlingame, CA, USA. The goal was to look at how messaging tech is doing right now, including email, instant messaging, and voice messaging. They wanted to see what these have in common, where they differ, and which engineering, research, and architecture topics could be worked on next 🔥 The report covers the discussions and conclusions of both the workshop and the IAB itself ✨

Table of Contents

1. Introduction ....................................................3
2. Methodology .....................................................4
3. Issues ..........................................................5
   3.1. Authorization ..............................................5
   3.2. Multiple Communication Channels ............................6
   3.3. Negotiation ................................................8
   3.4. User Control ...............................................9
   3.5. Message Transport ..........................................9
   3.6. Identity Hints and Key Distribution .......................10
4. Recommendations ................................................11
   4.1. Authorization .............................................11
   4.2. Multiple Communication Channels ...........................12
   4.3. Negotiation ...............................................13
   4.4. User Control ..............................................13
   4.5. Message Transport .........................................14
   4.6. Identity Hints and Key Distribution .......................16
5. Security Considerations ........................................16
6. Acknowledgements ...............................................16
Appendix A.  Participants .........................................17
Appendix B.  Pre-Workshop Papers ..................................18

1. Introduction 🌈

okay so current email infrastructure is basically a mix of pieces that together do end-to-end communication through a relay mesh 🕸️ That mix built up as requirements changed over the years. People keep coming back to the same complaints: some things email should do, like internationalization, efficient encoding of structured data, and trusted communication, aren't handled well by the current setup. Some of that infrastructure also seems hurt by today's internet problems, especially spam, viruses, and the lack of security infrastructure 😭 Revamping email has been on the table for ages, but nobody has been very excited to take on that mountain. Still, there's been some recent informal chat about what a "next generation" email should look like 💅

At the same time, other messaging systems are getting deployed, including instant messaging and web logging. They seem to fix a lot of those same problems and add features that aren't really part of traditional email, like prior-consent-based acceptance of messages 🫶 But each one (at least as deployed right now) seems to be missing some features people associate 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) thought the timing was right to look at messaging on the Internet and find areas where work could move these technologies forward 🚀 So they held a workshop on Internet messaging, using some of those issues as input, to give direction for future study in the area ✨

Messaging is a really broad topic, and it's not always clear where its edges are 🦋 Instead of getting stuck on a philosophical debate about what a message even is, the participants went with a "we know it when we see it" attitude. Their main examples were well-established types like email and instant messaging (IM), and they also talked about more "peripheral" types like voice messaging and event notifications 🎀 (Message queuing systems with guaranteed delivery and transactional integrity, like the ones used in enterprise workflow engines and some "web services" architectures, were operationally, if not intentionally, out of scope 🙈) The participants looked for common themes across all the messaging types being considered. The themes they found were:

  • Authorization of senders and recipients
  • Negotiation of messaging parameters
  • Consent models and privacy
  • Identity hints, reputation, and key distribution
  • Cross-protocol unification of messaging models
  • Enabling greater user control over messaging
  • Transport issues (unreliable links, push/pull, etc.)
  • Message organization (e.g., conversations and threading)

Notice what's not on that list: unsolicited commercial email or unsolicited bulk email (UCE or UBE, colloquially known as "spam") and similar stuff in other messaging environments, like instant messaging ("spim") and Internet telephony ("spit") 👀 Spam was actually a big reason the IAB held the workshop, but it was kept off the agenda because people worried it would crowd out the other messaging issues 😤 The broader topics of authorization and identity were considered wide enough to cover the architectural issues around spam without turning into more unproductive arguments 💖

Here's how the doc is laid out 🗺️ Section 3 summarizes the discussions from the workshop on various topics or themes. Section 4 gives an overview of the recommended research topics and protocol definition efforts that came out of the workshop. Section 5 covers the security-related aspects of the topics discussed. Appendix B lists the pre-workshop topic papers that participants submitted as background for the discussions 📚

2. Methodology 🧚

okay so before the workshop, participants submitted brief topic papers to set the context for the discussions that followed. You'll find the list of papers and their authors in Appendix B of this document 📝

During the workshop, discussion centered on several topics or themes, which the following sections summarize. Obviously, two days isn't enough to go deep on all of them 😭 Still, the group reached rough consensus that these topics matter, even if they didn't always agree on the details of potential research programs and protocol standardization efforts that could address the issues raised. The hope is that these summaries will inspire more work from other investigators 🌸

The in-workshop discussions naturally split 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 both engineers and researchers to consider 🔥 Each morning, the full group had a discussion to pick possible topics for deeper investigation. Then participants picked one of three "break-out" sessions to join 💅 Toward the end of each day, the full groups came back together, collected reports from the break-out discussion leaders, and tried to reach consensus on lessons learned and recommendations for further research ✨ So the two-day workshop produced discussion issues and research/engineering recommendations on the six topics described in this report 🎀

3. Issues 💬

3.1. Authorization 🔐

okay this one's giving main character energy 👑 Sending a message and the recipient actually accepting it are two very different things 🙈 What makes a recipient accept a message includes the sender's identity, past experience with that sender, whether there's an ongoing conversation between them, metadata about the message (like its subject or size), the message medium (email vs. IM), and temporal or psychological factors 🧠 Authorization, or acceptance, usually happens at the level of the message or the level of the sender. Sometimes it happens at other levels too, like a conversation thread, a medium, or a sender domain 🦋

Traditionally, sender authorization has been handled with recipient-defined block and allow lists (also called "blacklists" and "whitelists") 💀 Block lists don't do much, honestly, because it's so easy to get or create new messaging identities, like an email address or IM address 😭 Allow lists work much better, since the list of people you like or want to talk to is way smaller than the huge universe of people you don't 💖 The catch is that they make it hard for a sender to start talking to a new or previously unknown recipient 🥺 The workshop participants talked through a few ways around that, including reputation systems and better ways for one person to introduce another to a third party, like through signed invitations 💌

Reputation systems might be especially worth future research, because they copy a pattern we already know from real life ✨ (It might also be useful to tell apart (1) reputation, which is the reactive assessment of a sender that one or more recipients make based on message history, and (2) accreditation, which is a proactive assessment from trusted third parties 🫶) Reputation could be based on adding up an individual's "scores" that recipients provide across the network 🔢 (Here's the tricky part: the more important reputation becomes, the more bad actors will try to sabotage whatever reputation system is in place. So a distributed system, instead of a centralized one, might be more desirable 🛡️) And the actions a recipient takes based on a sender's reputation don't have to be a simple allow/deny decision. More subtle moves could include putting messages from people with lower reputation scores into separate inboxes, or redirecting them to other media, like going from IM to email 📬🌈

3.2. Multiple Communication Channels 📱

Okay so people use SO many messaging channels at once: phone, email, IM, pager, the works 💅 That makes it really hard for a sender to figure out the best way to reach someone at any given moment 😭 One approach is for the initiator to just guess. Like, send an email first, then escalate to a pager or a phone call if needed. The catch is that the recipient might end up getting the same message more than once 🙈 A second approach is for the recipient to keep their contact info updated regularly, maybe as part of their presence. That way the initiator can check ahead of time which channel fits best ✨ The third option is a "unifier" service that routes messages or notifications to the recipient based on a set of delivery rules, like "notify me via pager if I receive a voicemail message from my boss after 17:00" 🔥

The workshop folks didn't think they needed to pick just one of these models 🫶 But they did flag some issues that matter when you're trying to unify, or at least coordinate, communication across several channels:

  • While duplicate messages could be suppressed by setting something like a "seen" flag on copies that arrive through different media, the correlation of multi-channel, multi-message exchanges just isn't well supported by existing standards 💀
  • A recipient could tell the initiator their best contact method by explicitly granting permission, maybe through some kind of "authorization token" 🎀
  • It might be worth defining frameworks or protocols for recipient-defined delivery rules. Right now routing decisions are mostly made by the sender when they pick a channel, but down the road the recipient may get a bigger say in that 👑
  • The logic behind contact publication needs more exploring. For example, is it part of presence or an extension of it? And should contact addresses for one medium be obtained by communicating in a different medium, like "email me to get my mobile number"? 🦋

Having lots of delivery channels also makes it harder for a sender to build a "reliable" relationship with a recipient 😩 From the sender's side, it isn't obvious that a recipient on one channel is the same person as the recipient on another channel. How those recipient "identities" get tied together is still an open question 🌸

Recipient capabilities are another area to look into ✨ When the sender doesn't have capability information, the usual result is falling back to the lowest common denominator of communication, which seriously underuses what the whole system can actually do 😭 Earlier standards efforts (LDAP, Rescap, vCard, and Conneg, for example) tried to tackle parts of this capability puzzle, but without great success 💔

Right now the deployment model leans on several out-of-band mechanisms to set up communication when there's no programmatic capability info. A lot of those rely on direct human interaction and social norms, and honestly, in many cases those are super efficient and a better fit than any protocol-based option 💖 Still, a programmatic way to set up communication between "arms length" parties, like business-to-business and business-to-customer relationships, could be really beneficial 🧚

Any talk about relationships eventually turns into a talk about trust. Think "from what kinds of entities do I want to receive messages?" 👀 That's a huge topic, but the group did discuss a few ideas that could make it easier to broker communication within different relationships:

  • Whitelisting is the explicit definition of a relationship from the recipient's point of view: a list of senders the recipient is willing to talk to. Allow lists can be a workable solution, but they're a relatively static authorization scheme 📜
  • Token-based authorization lets the recipient set up a one-time or limited-time relationship with a sender. The issuer holds a token that grants a limited-time right to communicate with the recipient. This is a more dynamic authorization scheme ⏳
  • Rule-based authorization means algorithmically assessing whether a relationship is viable based on a wide set of criteria. It's the most general option, since it can fold in both allow lists and tokens, plus extra evaluation criteria like message characterization and issuer characterization 🧠

3.3. Negotiation 🤝

When it comes to negotiation, the workshop participants mostly focused on how a group of participants agrees on the media and parameters they'll use to communicate 💜 (A good example of where a "rendezvous" negotiation ends up is a group of colleagues agreeing to hold a voice conference, with a text "groupchat" as a secondary channel.) To make cross-media negotiation work, you may need a bridge between different identities. For instance, the negotiation might happen over email, but the actual talk happens over the phone. To authorize participants, the conference software needs their phone numbers, not their email addresses 📞 The parameters being negotiated can cover a lot of ground, including:

  • Prerequisites for the communication, like distributing a "backgrounder" document 📄
  • Who will initiate the communication
  • Who will participate in the communication
  • The primary "venue," like a telephone number that everyone will call ☎️
  • One or more secondary venues, like a chatroom address 💬
  • Backup plans if the primary or secondary venue isn't available
  • The topic or topics for discussion
  • The identities of administrators or moderators 👑
  • Whether or not the discussion will be logged or recorded 📝
  • Scheduling of the event, including recurrence (for example, different instances might have different venues or other details) 🗓️

In some contexts, it might even be useful to negotiate or renegotiate parameters after communication has already started. For example, you might want to invite new participants or change key parameters like logging 🔄 The workshop folks realized that negotiating a full set of parameters in depth probably isn't needed for many kinds of communication. Still, parts of a general framework or protocol for negotiating multiparty communication could be useful across a wide range of applications and contexts 🌈

3.4. User Control 🎛️

"Power users" (and, more and more, regular users too) have a pretty common feeling that messaging isn't really under their control 😤 It's not just about unsolicited messages. It's also about juggling multiple messaging media and dealing with the sheer volume of messages from both familiar and unfamiliar senders. Right now people cope with personal habits and ad hoc software tools, but there may be a chance to offer more programmatic support within Internet protocols and technologies ✨

One area to investigate is message filtering 🔍 A user or agent may decide to take one of many actions on a message (bounce, ignore, forward, file, replicate, archive, accept, notify, etc.) based on certain information. That information could include the identity of the sender and/or recipient(s), the sender's reputation, the message thread or conversational context, message headers, message content (like whether there are attachments), and environmental factors like the time of day or personal mood 🌙 It's still an open question how much formalization would be necessary or even helpful here. But the workgroup participants pointed out a few areas worth exploring:

  • Cross-media threads and conversations: it may help to find ways to tag messages as belonging to a particular thread or conversation across media, like a forum discussion that migrates to email or IM 🧵
  • Communication hierarchies: messages often don't stand alone. They exist within higher-level structures like a thread (a coherent or ordered set of messages within one medium), a conversation (a set of threads that may cross media), or an activity (a set of conversations and related resources, such as documents) 🏗️
  • Control protocols: the workgroup participants left open whether there may be a need for a cross-service control protocol for managing communications across messaging media 🎮

3.5. Message Transport 🚚

Different messaging media run on different underlying transports 🛤️ Some messaging systems handle slow or lossy links better, while others depend on transport mechanisms that don't tolerate loss as well. Blending media with different transport profiles can be tricky 😵‍💫 For one thing, assuming the same addressing endpoint always represents the same entity over time may not be justified. More work on identifying, addressing, and discovering endpoints may be appropriate, even at the URI level 🔗 It's also possible that the same endpoint or entity is reachable via different transport mechanisms at different times, or even via several transports at once. Choosing the right transport when there are multiple paths brings up addressing issues that Internet protocol development hasn't dealt with yet. Possible heuristics might include predictive routing, opportunistic routing, and scheduled routing 🧭 For links that can be unreliable, it may be valuable to gracefully restart the link after any failure, possibly by switching to a different transport mechanism 🔁

Another issue in cross-media and cross-transport integration is synchronization of references 🔄 This applies to particular messages, but it might also apply to message fragments. Some fragments, such as large ancillary data, might be better transported separately from others, like small essential text data 📦 Message fragments might also be forwarded, replicated, archived, and so on, separately from other parts of a message. Here's one thing that affects synchronization across transports: some messaging media are push-oriented (like IM), while others are generally pull-oriented (like email). When content gets pushed to a recipient in one medium before the recipient has pulled it in another, content references can fall out of sync 😬

If message fragments can travel over different media, possibly arriving at different times or along different paths, package security becomes a serious concern 🔐 Traditionally, messages are secured by encrypting the entire package at the head end and then decrypting it at the receiving end. But if we want transports to be able to fragment messages based on the media types of their parts, that approach won't be feasible 🚫

Okay bestie, so 3.6 is about identity and key distribution, and this one is lowkey the most relatable section 🥺🔐

While everyone agrees that encrypting messages and checking who you're actually talking to are both super desirable, the workshop folks said current business and implementation models kind of discourage using the solutions we already have 🙃 Like, it's often hard to get new root certificates installed in clients, certificates are (or are perceived to be) difficult or expensive to get, one-click or zero-click service enrollment is a worthy goal that feels totally out of reach 😩, and even after you make a public/private key pair and certify the public key, it's less than obvious how to distribute that certificate or find other people's certificates. Main character problems 💀

One thing that might make widespread message encryption more doable is that email, instant messaging, and Internet telephony have pretty similar trust models 🫶 But the definition of communication is different across them. In email, "the message is the thing," and it's a discrete object in its own right 📧. In telephony, the focus is on the real-time flow of a conversation or session instead of discrete messages 📞. IM kind of sits in the middle, since it's centered on the rapid, back-and-forth exchange of text messages (which can be seen as messaging sessions) 💬 It's giving in-between energy ✨

Another complicating factor is the wide range of contexts where messaging gets used 🌈. We're talking casual convos in public chatrooms and social networking apps, communication between businesses and customers, and mission-critical business-to-business stuff like supply chain management 📦. Different audiences can have different needs for messaging security and identity verification, so the demand for things like trusted third parties and webs of trust varies a lot 🕸️

Now, in communication technologies, identity hints (shared knowledge, conversational styles, voice tone, messaging patterns, vocabulary, and the like) can often give you more useful info than key fingerprints, digital signatures, and other electronic artifacts 🔍 Those feel super distant from the experience of most end users, honestly. Right now, checking identity hints is intuitive rather than programmatic 🧠 which is a vibe, but not a scalable one 😅

4. Recommendations ✨

4.1. Authorization 💅

The one clearly desired engineering project that came out of the authorization discussion was a distributed reputation service 🔥 Everyone agreed that whatever else needs to happen with authorization of messages, at some point the recipient of a message is going to want to check the reputation of the sender. This is especially useful when the sender is someone the recipient has no prior experience with, i.e., using a reputation service to get an "introduction to a stranger" 👀 It was clearly needed to be decentralized. A single centralized reputation service can be useful in some contexts, but it doesn't scale to an Internet-wide service 🌐

Two potential research topics in authorization came up. First, a lot of the discussion centered on whitelists and blacklists in authorization decisions, but people thought research was needed to fully examine how useful each approach is 🧐 It was clear to the participants that blacklists can weed out known non-authorized senders, but they don't stop "aggressive" unwanted senders, because it's super easy to just get a new identity 🙄 Whitelists can be useful for limiting messages to only the ones known to the recipient, but they'd need some kind of introduction service to let in messages from unknown parties 🎟️ Participants also thought there might be useful architectural work in this area 🏗️

The other potential research area was recipient responses to authorization decisions. When making an authorization decision, recipients have to do two things. First, the recipient obviously has to dispatch the message somehow, either delivering it or denying it 📬 But that decision also has side effects on 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 came up during the session, and the participants worked to turn them into research or engineering tasks, as appropriate ✨

In the area of contact information management, the workshop participants identified a possible engineering task: defining a service that publishes contact information such as availability, capabilities, channel addresses (routing information), preferences, and policies 📇 Aspects of this work have been tried before within the IETF, with varying degrees of success 🫠 but there are still lots of potential benefits for managing business-to-business and business-to-customer relationships 💼

Suppressing redundant messages is becoming more important as using multiple messaging channels becomes the norm for most Internet users 📲 Users are also getting used to receiving notifications in one channel about communications that came in through another channel 🔔 The unfortunate part is that there are essentially no standards for cross-referencing and linking messages across channels 😭 Standards work in this area may be appropriate 🙏

Another possible engineering task is defining a standardized representation for defining and applying recipient message processing rules 🧩 That effort would extend the existing work on the Sieve language within the IETF to incorporate some of the concepts discussed above 🦋

Token-based authorization discussions focused on establishing time-limited or usage-limited relationships for exchanging messages ⏳ The work would try to define the identity, generation, and use of tokens for authorization purposes 🔑 This is most likely more of a research topic than an engineering one 🧪

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 about negotiation resulted mostly in research-oriented output 🔬 The session felt that participants in a conversation would need some kind of rendezvous mechanism where the conversation's parameters get negotiated 🗓️ To make that work, a "conversation identifier" would be needed so participants can identify the conversation they want to join 🆔 There are also at least five dimensions along which a conversation negotiation may occur 👇

  • The participants in the conversation
  • The topic for the conversation
  • The scheduling and priority parameters
  • The mechanism used for the conversation
  • The capabilities of the participants
  • The logistical details of the conversation

Research into how to communicate these different parameters may prove useful, and so may research into the relationship between 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 major focus 👑 The participants got a start on defining threads as a semi-ordered set of messages, a conversation as 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 threads together and have them be cross-media 🌍 Messages can potentially belong to more than one thread 🫧 Threads themselves might have subthreads 🪆 All of these topics need an architectural overview to bring them into focus 🔭

There's also engineering work that's already mature enough to be undertaken on threads 💪 Though some simple threading work is happening with messaging now, it's pretty much only useful for a unidirectional tree of messages in a single context 🙈 Engineering work needs to be done on identifiers that could be used in threads that cross media 🪪 There's likely also 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 ✨

okay so a big research topic from the transport session was multiple transports 🚚. The idea is to chop a message into pieces and send each piece over a different transport medium so it still reaches its final destination. Especially in high-latency, low-bandwidth environments, running parallel transports for different parts of a message could be extremely advantageous 🔥. The hard part is putting all the pieces back together in a timely way, and figuring out the single destination of the message when the addressing involves multiple media 🧩.

A recurring theme in several discussions (user control and message unification too) was the need for some kind of identifier 🆔, but it figured most prominently in transport. In transport, identifiers are needed on two levels. First, to mark the endpoints in message transport. As discussed, a message could reasonably be delivered to different entities that all correspond to one person 👀. So you need an identifier for the target person of the message, plus identifiers for the different endpoints, to get any traction here 💅. Second, identifiers are needed for the messages being transported and their component parts 📦. If you split parts across different mechanisms, you have to identify the containing message so reassembly can happen at the receiving end 🧷. Identifying the whole package also matters when duplicate copies might be sent over two different mechanisms. The receiver needs to figure out that it already got a copy through one mechanism, and recognise that another copy is just a duplicate 🙈.

Workshop participants felt that, at the very least, a standard identifier syntax was a reasonable engineering work item that could be tackled 🛠️. Some identifier mechanisms already exist in current messaging protocols, but none were designed to be used reliably across different transport environments or in multiple contexts 😤. There's already a reasonable amount of engineering work in 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 for message part identifiers, but participants felt more of it was ripe for research 🔬. Identifying endpoints as belonging to a single recipient, and distributing those endpoint identifiers along with delivery preference information, is definitely an area where research could be fruitful 💜. It would also be worthwhile to explore collecting identified message components sent through different media, while delivering to the correct end-recipient with duplicate removal and reassembly 🧩✨.

Package security was seen as an area for research 🔐. As described in Section 3.5, the possibility that different components of a message might travel over different media and need to be reassembled at the recipient end breaks certain end-to-end security assumptions that are currently made 😭. Participants felt a worthwhile research goal would be to examine security mechanisms that could be used for multi-component messages without sacrificing desirable security features 💖.

Finally, a more architectural topic: restartability 🔁. Most current message transports, when faced with links that have reliability problems, cancel and restart the transport of a message from the beginning 😩. Some mechanisms do exist for restart mid-session, but they aren't widely implemented, and they can rarely be used across protocol boundaries 🙃. Some architectural guidance on restart mechanisms would be a useful addition 🎀.

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. But care is needed, because 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's important to keep in mind that distribution is a separate problem from 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 centralized control 🏢.

In defining security frameworks for messaging, it would be helpful to specify more clearly the similarities and differences among various messaging technologies when it comes 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 haven't been widely explored yet 👀.

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

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

Appendix B. Pre-Workshop Papers 📄

The topic papers that circulated before the workshop were:

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

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

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. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📜.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt 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 required to implement this standard. Please send that 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) 🌈.

📦 where this page comes from