idnits 2.17.1 draft-iab-messaging-report-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 847. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 824. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 831. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 837. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2005) is 6862 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board P. Resnick, Ed. 3 Internet-Draft IAB 4 Expires: January 7, 2006 P. Saint-Andre, Ed. 5 JSF 6 July 6, 2005 8 Report of the 2004 IAB Messaging Workshop 9 draft-iab-messaging-report-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 7, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document reports the outcome of a workshop held by the Internet 43 Architecture Board (IAB) on the future of Internet messaging. The 44 workshop was held on 6 and 7 October 2004 in Burlingame, CA, USA. 45 The goal of the workshop was to examine the current state of 46 different messaging technologies on the Internet (including, but not 47 limited to, electronic mail, instant messaging, and voice messaging), 48 look at their commonalities and differences, and find engineering, 49 research, and architectural topics on which future work could be 50 done. This report summarizes the discussions and conclusions of the 51 workshop and of the IAB. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1 Authorization . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2 Multiple Communication Channels . . . . . . . . . . . . . 6 60 3.3 Negotiation . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.4 User Control . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.5 Message Transport . . . . . . . . . . . . . . . . . . . . 9 63 3.6 Identity Hints and Key Distribution . . . . . . . . . . . 10 64 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 11 65 4.1 Authorization . . . . . . . . . . . . . . . . . . . . . . 11 66 4.2 Multiple Communication Channels . . . . . . . . . . . . . 12 67 4.3 Negotiation . . . . . . . . . . . . . . . . . . . . . . . 13 68 4.4 User Control . . . . . . . . . . . . . . . . . . . . . . . 13 69 4.5 Message Transport . . . . . . . . . . . . . . . . . . . . 14 70 4.6 Identity Hints and Key Distribution . . . . . . . . . . . 15 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 74 A. Participants . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 B. Pre-Workshop Papers . . . . . . . . . . . . . . . . . . . . . 17 76 Intellectual Property and Copyright Statements . . . . . . . . 19 78 1. Introduction 80 Current e-mail infrastructure is a mixture of facilities to 81 accomplish its task of end-to-end communications through a relay 82 mesh. That mixture has come about as requirements have changed over 83 the years. Discussions recur over the years, often complaining that 84 some desired features of e-mail (such as internationalization, 85 efficient encoding of structured data, trusted communication) are 86 ill-served by the current infrastructure, or that some of the current 87 infrastructure seems to be adversely affected by current problems on 88 the Internet (most recently including problems like spam, viruses, 89 and lack of security infrastructure). For many years, the daunting 90 task of revamping e-mail infrastructure has been considered, with 91 justifiably little enthusiasm for taking on such a task. However, 92 there has been some recent informal discussion on the kinds of things 93 that would be desirable in a "next generation" e-mail. 95 At the same time, other messaging infrastructures (including those 96 associated with "instant messaging" and "web logging") are currently 97 deploying that appear to address many of the above desired features 98 and outstanding problems, while adding many features not currently 99 considered part of traditional e-mail (like prior-consent-based 100 acceptance of messages). However, each of these technologies (at 101 least in their current deployment) seem to lack some of the features 102 commonly associated with e-mail (such as selective and partial 103 message delivery, queued multi-hop relaying, offline message 104 management, and efficient non-textual content delivery). 106 The Internet Architecture Board (IAB) believed that the time was ripe 107 to examine the current state of messaging technologies on the 108 Internet and to see if there are areas of work that can be taken on 109 to advance these technologies. Therefore, the IAB held a workshop on 110 Internet messaging, taking some of the above issues as input, in 111 order to formulate some direction for future study of the area of 112 messaging. 114 The topic of messaging is broad, and the boundaries of what counts as 115 messaging are not always well-defined. Rather than limiting 116 themselves to a philosophical discussion of the nature of messages, 117 the workshop participants adopted the attitude of "we know it when we 118 see it" and used as their primary examples such well-established 119 types of messaging as email and instant messaging (IM), while also 120 discussing more "peripheral" types of messaging such as voice 121 messaging and event notifications. However, the participants 122 attempted to discover common themes that apply to all types of 123 messaging. Among the themes identified were the following: 125 o Authorization of senders and recipients 126 o Negotiation of messaging parameters 127 o Consent models and privacy 128 o Identity hints, reputation, and key distribution 129 o Cross-protocol unification of messaging models 130 o Enabling greater user control over messaging 131 o Transport issues (unreliable links, push/pull, etc.) 132 o Message organization (e.g., conversations and threading) 134 While an impetus for the IAB holding this workshop, prominently 135 missing from that list is the topic of unsolicited commercial email 136 or unsolicited bulk email (UCE or UBE, colloquially known as "spam") 137 and analogous communications in other messaging environments such as 138 instant messaging ("spim") and Internet telephony ("spit"). Because 139 that topic would have crowded out discussion of other messaging- 140 related issues, it was kept off the workshop agenda. The more 141 general topics of authorization and identity were thought to be broad 142 enough to cover the architectural issues involved with spam without 143 devolving into more unproductive discussions. 145 This document is structured so as to provide an overview of the 146 discussion flow as well as proposed recommendations of the workshop. 147 Section 3 summarizes the discussions that occurred during the 148 workshop on various topics or themes while, Section 4 provides an 149 overview of recommended research topics and protocol definition 150 efforts that resulted from the workshop. Section 5 provides some 151 perspective on the security-related aspects of the topics discussed 152 during the workshop. Appendix B lists the pre-workshop topic papers 153 submitted by workshop participants as background for the workshop 154 discussions. 156 2. Methodology 158 Prior to the workshop, brief topic papers were submitted to set the 159 context for the discussions to follow; a list of the papers and their 160 authors is provided in Appendix B of this document. 162 During the workshop itself, discussion centered on several topics or 163 themes, as summarized in the following sections. Naturally, it was 164 not possible in a two-day workshop to treat these topics in depth; 165 however, rough consensus was reached on the importance of these 166 topics, if not always on the details of potential research programs 167 and protocol standardization efforts that might address the issues 168 raised. It is hoped that these summaries will inspire work by 169 additional investigators. 171 The in-workshop discussions quite naturally fell into three kinds of 172 "tracks": (1) possible engineering tasks to recommend to the IESG and 173 other standardization groups, (2) "blue sky" research topics to 174 recommend to the IRTF and other researchers, and (3) general 175 architectural or "framework" issues for consideration by both 176 engineers and researchers alike. After a full-group discussion each 177 morning to identify possible topics for more in-depth investigation, 178 participants self-selected for involvement in one of three "break- 179 out" sessions. Toward the end of each day, the full groups 180 reconvened, gathered reports from the break-out discussion leaders, 181 and attempted to come to consensus regarding lessons learned and 182 recommendations for further research. The results of the two-day 183 workshop therefore consist of discussion issues and research/ 184 engineering recommendations related to the six topics described in 185 this report. 187 3. Issues 189 3.1 Authorization 191 It is one thing for a sender to send a message, and another thing for 192 the intended recipient to accept it. The factors that lead a 193 recipient to accept a message include the identity of the sender, 194 previous experience with the sender, the existence of an ongoing 195 conversation between the parties, meta-data about the message (e.g., 196 its subject or size), the message medium (e.g., email vs. IM), and 197 temporal or psychological factors. Authorization or acceptance 198 applies most commonly at the level of the message or the level of the 199 sender, and occasionally also at other levels (conversation thread, 200 medium, sender domain). 202 Traditionally, sender authorization has been handled by recipient- 203 defined block and allow lists (also called "blacklists" and 204 "whitelists"). Block lists are of limited value, given the ease of 205 gaining or creating new messaging identities (e.g., an email address 206 or IM address). Allow lists are much more effective (since the list 207 of people you like or want to communicate with is smaller than the 208 large universe of people you don't), but they make it difficult for a 209 sender to initiate communication with a new or previously unknown 210 recipient. The workshop participants discussed several ways around 211 this problem, including reputation systems and better ways for one 212 person to introduce another person to a third party (e.g., through 213 signed invitations). 215 Reputation systems may be especially worthy of future research, since 216 they emulate a pattern that is familiar from real life. (It may also 217 be valuable to distinguish between (1) reputation as the reactive 218 assessment of a sender created by one or more recipients based on 219 message history and (2) accreditation as a proactive assessment 220 provided by trusted third parties.) Reputation might be based on 221 summing an individual's "scores" provided by recipients on the 222 network. (Naturally, the more important reputation becomes, the more 223 bad actors might attempt to sabotage any given reputation system, so 224 that a distributed as opposed to centralized system might be more 225 desirable.) The actions taken by any given recipient based on the 226 sender's reputation would not necessarily be limited to a simple 227 allow/deny decision; more subtle actions might include placing 228 messages from individuals with lower reputation scores into separate 229 inboxes or redirecting them to other media (e.g., from IM to email). 231 3.2 Multiple Communication Channels 233 It is a fact of life that many people use multiple forms of messaging 234 channels: phone, email, IM, pager, and so on. Unfortunately, this 235 can make it difficult for a sender or initiator to know the best way 236 to contact a recipient at any given time. One model is for the 237 initiator to guess, for example by first sending an email message and 238 then escalating to pager or telephone if necessary; this may result 239 in delivery of redundant messages to the recipient. A second model 240 is for the recipient to publish updated contact information on a 241 regular basis, perhaps as one aspect of his or her presence; this 242 might enable the initiator to determine beforehand which contact 243 medium is most appropriate. A third model is for the recipient to 244 use some kind of "unifier" service that enables intelligent routing 245 of messages or notifications to the recipient based on a set of 246 delivery rules (e.g., "notify me via pager if I receive a voicemail 247 message from my boss after 17:00"). 249 The workshop participants did not think it necessary to choose 250 between these models, but did identify several issues that are 251 relevant in unifying or at least coordinating communication across 252 multiple messaging channels: 254 o While suppression of duplicate messages could be enabled by 255 setting something like a "seen" flag on copies received via 256 different messaging media, in general the correlation of multi- 257 channel, multi-message exchanges is not well supported by existing 258 standards. 259 o A recipient could communicate his or her best contact mechanism to 260 the initiator by explicitly granting permission to the initiator, 261 perhaps by means of a kind of "authorization token". 262 o It may be worthwhile to define frameworks or protocols for 263 recipient-defined delivery rules. Currently routing decisions 264 tend to be made mostly by the sender through the choice of a 265 messaging channel, but in the future the recipient may play a 266 larger role in such decisions. 268 o The logic behind contact publication needs to be explored, for 269 example, whether it is an aspect of or extension to presence and 270 whether contact addresses for one medium are best obtained by 271 communicating in a different medium ("email me to get my mobile 272 number"). 274 A multiplicity of delivery channels also makes it more complex for a 275 senders to establish a "reliable" relationship with a recipient. 276 From the sender's point of view, it is not obvious that a recipient 277 on one channel is the same recipient on another channel. How these 278 recipient "identities" are tied together is an open question. 280 Another area for investigation is that of recipient capabilities. 281 When the sender does not have capability information, the most common 282 result is downgrading to a lowest common denominator of 283 communication, which seriously underutilizes the capabilities of the 284 entire system. Previous standards efforts (e.g., LDAP, Rescap, 285 vCard, Conneg) have attempted to address parts of the capability 286 puzzle, but without great success. 288 The existing deployment model uses several out-of-band mechanisms for 289 establishing communications in the absence of programmatic 290 capabilities information. Many of these mechanisms are based on 291 direct human interaction and social policies, which in many cases are 292 quite efficient and more appropriate than any protocol-based means. 293 However, a programmatic means for establishing communications between 294 "arms length" parties (e.g., business-to-business and business-to- 295 customer relationships) might be very beneficial. 297 Any discussion of relationships inevitably leads to a discussion of 298 trust (e.g., "from what kinds of entities do I want to receive 299 messages?"). While this is a large topic, the group did discuss 300 several ideas that might make it easier to broker communications 301 within different relationships, including: 303 o Whitelisting is the explicit definition of a relationship from the 304 recipient's point of view, consisting of a list of senders with 305 whom a recipient is willing to engage in conversation. While 306 allow lists can be a workable solution, they are a relatively 307 static authorization scheme. 308 o Token based authorization enables the recipient to define a one- 309 time or limited-time relationship with a sender. The issuer 310 possesses a token that grants a limited-time right to communicate 311 with the recipient. This is a more dynamic authorization scheme. 312 o Rule-based authorization involves an algorithmic assessment of the 313 viability of a relationship based on a wide set of criteria. This 314 is a more general authorization scheme that can incorporate both 315 allow lists and tokens, plus additional evaluation criteria such 316 as message characterization and issuer characterization. 318 3.3 Negotiation 320 In the area of negotiation, the workshop participants focused mainly 321 on the process by which a set of participants agree on the media and 322 parameters by which they will communicate. (One example of the end 323 result of such a "rendezvous" negotiation is a group of colleagues 324 who agree to hold a voice conference, with a textual "groupchat" as a 325 secondary communications channel.) In order to enable cross-media 326 negotiation, it may be necessary to establish a bridge between 327 various identities; e.g., the negotiation may occur via email but the 328 communication may occur via phone, and in order to authorize 329 participants the conference software needs to know their phone 330 numbers, not their email addresses. Furthermore, the parameters to 331 be negotiated may include a wide variety of aspects, including: 333 o Prerequisites for the communication (e.g., distribution of a 334 "backgrounder" document). 335 o Who will initiate the communication. 336 o Who will participate in the communication. 337 o The primary "venue" (e.g., a telephone number which all 338 participants will call). 339 o One or more secondary venues (e.g., a chatroom address). 340 o Back up plans if the primary or secondary venue is not available. 341 o The topic or topics for the discussion. 342 o The identities of administrators or moderators. 343 o Whether or not the discussion will be logged or recorded. 344 o Scheduling of the event, including recurrence (e.g., different 345 instances may have different venues or other details). 347 Indeed, in some contexts it might even be desirable to negotiate or 348 re-negotiate parameters after communication has already begun (e.g., 349 to invite new participants or change key parameters such as logging). 350 While the workshop participants recognized that in-depth negotiation 351 of a full set of parameters is likely to be unnecessary in many 352 classes of communication, parts of a generalized framework or 353 protocol for the negotiation of multiparty communication might prove 354 useful in a wide range of applications and contexts. 356 3.4 User Control 358 A common perception among "power users" (and, increasingly, average 359 users) on the Internet is that messaging is not sufficiently under 360 their control. This is not merely a matter of unsolicited 361 communications, but also of managing multiple messaging media and 362 handling the sheer volume of messages received from familiar and 363 unfamiliar senders alike. Currently, individuals attempt to cope 364 using various personal techniques and ad-hoc software tools, but 365 there may be an opportunity to provide more programmatic support 366 within Internet protocols and technologies. 368 One area of investigation is message filtering. Based on certain 369 information -- the identity of the sender and/or recipient(s), the 370 sender's reputation, the message thread or conversational context, 371 message headers, message content (e.g., the presence of attachments), 372 and environmental factors such as time of day or personal mood -- a 373 user or agent may decide to take one of a wide variety actions with 374 regard to a message (bounce, ignore, forward, file, replicate, 375 archive, accept, notify, etc.). While it is an open question how 376 much formalization would be necessary or even helpful in this 377 process, the workgroup participants identified several areas of 378 possible investigation: 380 o Cross-media threads and conversations -- it may be helpful to 381 determine ways to tag messages as belonging to a particular thread 382 or conversation across media (e.g., a forum discussion that 383 migrates to email or IM), either during or after a message 384 exchange. 385 o Communication hierarchies -- while much of the focus is on 386 messages, often a message does not stand alone but exists in the 387 context of higher-level constructs such as a thread (i.e., a 388 coherent or ordered set of messages within a medium), a 389 conversation (i.e., a set of threads that may cross media), or an 390 activity (a set of conversations and related resources, such as 391 documents). 392 o Control protocols -- the workgroup participants left as an open 393 question whether there may be a need for a cross-service control 394 protocol for use in managing communications across messaging 395 media. 397 3.5 Message Transport 399 Different messaging media use different underlying transports. For 400 instance, some messaging systems are more tolerant of slow links or 401 lossy links, while others may depend on less loss-tolerant transport 402 mechanisms. Integrating media that have different transport profiles 403 can be difficult. For one, assuming that the same addressing 404 endpoint represents the same entity over time may not be warranted 405 (it is possible that further work in identifying, addressing, and 406 discovering endpoints may be appropriate, even at the URI level). It 407 is also possible that the same endpoint or entity could be available 408 via different transport mechanisms at different times, or even 409 available via multiple transports at the same time. The process of 410 choosing an appropriate transport mechanism when there are multiple 411 paths introduces addressing issues that have not yet been dealt with 412 in Internet protocol development (possible heuristics might include 413 predictive routing, opportunistic routing, and scheduled routing). 414 For links that can be unreliable, there may be value in being able to 415 gracefully restart the link after any given failure, possibly by 416 switching to a different transport mechanism. 418 Another issue that arises in cross-media and cross-transport 419 integration is synchronization of references. This applies to 420 particular messages but might also apply to message fragments. It 421 may be desirable for some message fragments, like large ancillary 422 data, to be transported separately from others, for example small 423 essential text data. Message fragments might also be forwarded, 424 replicated, archived, etc., separately from other parts of a message. 425 One factor relevant to synchronization across transports is that some 426 messaging media are push-oriented (e.g., IM) whereas others are 427 generally pull-oriented (e.g., email); when content is pushed to a 428 recipient in one medium before it has been pulled by the recipient in 429 another medium, it is possible for content references to get out of 430 sync. 432 If message fragments can be transported over different media, 433 possibly arriving at separate times or through separate paths, the 434 issue of package security becomes a serious one. Traditionally, 435 messages are secured by encrypting the entire package at the head end 436 and then decrypting it on the receiving end. However, if we want to 437 allow transports to fragment messages based upon the media types of 438 the parts, that approach will not be feasible. 440 3.6 Identity Hints and Key Distribution 442 While it is widely recognized that both message encryption and 443 authentication of conversation partners are highly desirable, the 444 consensus of the workshop participants was that current business and 445 implementation models in part discourage deployment of existing 446 solutions. For example, it is often hard to get new root 447 certificates installed in clients, certificates are (or are perceived 448 to be) difficult or expensive to obtain, one-click or zero-click 449 service enrollment is a worthy but seemingly unreachable goal, and 450 once one has created a public/private key pair and certified the 451 public key it is less than obvious how to distribute that certificate 452 or discover other people's certificates. 454 One factor that may make widespread message encryption more feasible 455 is that email, instant messaging, and Internet telephony have quite 456 similar trust models. Yet the definition of communication differs 457 quite a bit between these technologies: in email "the message is the 458 thing" and it is a discrete object in its own right, in telephony the 459 focus is on the real-time flow of a conversation or session rather 460 than discrete messages, and IM seems to hold a mediate position since 461 it is centered on the rapid, back-and-forth exchange of text messages 462 (which can be seen as messaging sessions). 464 Another complicating factor is the wide range of contexts in which 465 messaging technologies are used: everything from casual conversations 466 in public chatrooms and social networking applications, through 467 communications between businesses and customers, to mission-critical 468 business-to-business applications such as supply chain management. 469 Different audiences may have different needs with regard to messaging 470 security and identity verification, resulting in varying demand for 471 services such as trusted third parties and webs of trust. 473 In the context of communication technologies, identity hints -- 474 shared knowledge, conversational styles, voice tone, messaging 475 patterns, vocabulary, and the like -- can often provide more useful 476 information than key fingerprints, digital signatures, and other 477 electronic artifacts, which are distant from the experience of most 478 end users. To date, the checking of such identity hints is intuitive 479 rather than programmatic. 481 4. Recommendations 483 4.1 Authorization 485 The one clear engineering project that came out of the authorization 486 discussion was the desire for a distributed reputation service. It 487 was agreed that whatever else needed to be done in regard to 488 authorization of messages, at some point the recipient of the message 489 would want to be able to check the reputation of the sender of the 490 message. This is especially useful in the case of senders with whom 491 the recipient has no prior experience: i.e., using a reputation 492 service as a way to get an "introduction to a stranger". There was 493 clearly a need for this reputation service to be decentralized; 494 though a single centralized reputation service can be useful in some 495 contexts, it does not scale to an Internet-wide service. 497 Two potential research topics in authorization were discussed. 498 First, a good deal of discussion centered around the use of 499 whitelists and blacklists in authorization decision, but it was 500 thought that research was necessary to fully examine the relative 501 usefulness of each of the approaches. It was clear to the 502 participants that blacklists can weed out known non-authorized 503 senders, but do not stop "aggressive" unwanted senders because of the 504 ease of simply obtaining a new identity. Whitelists can be useful 505 for limiting messages to only those known to the recipient, but would 506 require the use of some sort of introduction service in order to 507 allow for messages from unknown parties. Participants also thought 508 that there might be useful architectural work done in this area. 510 The other potential research area was in recipient responses to 511 authorization decisions. Upon making an authorization decision, 512 recipients have to do two things: First, obviously the recipient must 513 dispatch the message in some way to either deliver it or deny it. 514 But that decision will also have side effects back into the next set 515 of authorization decisions the recipient may make. The decision may 516 feed back into the reputation system, either "lauding" or "censuring" 517 the sender of the message. 519 4.2 Multiple Communication Channels 521 Several interesting and potentially useful ideas were discussed 522 during the session, which the participants worked to transform into 523 research or engineering tasks as appropriate. 525 In the area of contact information management, the workshop 526 participants identified a possible engineering task to define a 527 service that publishes contact information such as availability, 528 capabilities, channel addresses (routing information), preferences, 529 and policies. While aspects of this work have been attempted 530 previously within the IETF (with varying degrees of success), there 531 remain many potential benefits with regard to managing business-to- 532 business and business-to-customer relationships. 534 The problem of suppressing redundant messages is becoming more 535 important as the use of multiple messaging channels becomes the rule 536 for most Internet users, and as users become accustomed to receiving 537 notifications in one channel of communications received in another 538 channel. Unfortunately, there are essentially no standards for 539 cross-referencing and linking of messages across channels; standards 540 work in this area may be appropriate. 542 Another possible engineering task is defining a standardized 543 representation for the definition and application of recipient 544 message processing rules. Such an effort would extend existing work 545 on the Sieve language within the IETF to incorporate some of the 546 concepts discussed above. 548 Discussion of token-based authorization focused on the concept of 549 defining a means for establishing time-limited or usage-limited 550 relationships for exchanging messages. The work would attempt to 551 define the identity, generation, and use of tokens for authorization 552 purposes. Most likely this is more of a research topic than an 553 engineering topic. 555 Work on recipient rules processing and token-based authentication may 556 be related at a higher level of abstraction (we can call it 557 "recipient authorization processing"). When combined with insights 558 into authorization (see Section 3.1 and Section 4.1), this may be an 559 appropriate topic for further research. 561 4.3 Negotiation 563 Discussion in the area of negotiation resulted mostly in research- 564 oriented output. The session felt that participants in a 565 conversation would require some sort of rendezvous mechanism during 566 which the parameters of the conversation would be negotiated. To 567 facilitate this, a "conversation identifier" would be needed so that 568 participants could identify the conversation that they wished to 569 participate in. In addition, there are at least five dimensions 570 along which a conversation negotiation may occur: 572 o The participants in the conversation 573 o The topic for the conversation 574 o The scheduling and priority parameters 575 o The mechanism used for the conversation 576 o The capabilities of the participants 577 o The logistical details of the conversation 579 Research into how to communicate these different parameters may prove 580 useful, as may research into the relationship between the concepts of 581 negotation, rendezvous, and conversation. 583 4.4 User Control 585 A clear architectural topic to come out of the user control 586 discussion was work on activities, conversations, and threads. In 587 the course of the discussion, the user's ability to organize messages 588 into threads became a focus. The participants got some start on 589 defining threads as a semi-ordered set of messages, a conversation as 590 a set of threads, and an activity as a collection of conversations 591 and related resources. The discussion expanded the traditional 592 notion of a thread as an ordered tree of messages. Conversations can 593 collect together threads and have them be cross-media. Messages can 594 potentially belong to more than one thread. Threads themselves might 595 have subthreads. All of these topics require an architectural 596 overview to bring into focus. 598 There is also engineering work that is already at a sufficient level 599 of maturity to be undertaken on threads. Though there is certainly 600 some simple threading work being done now with messaging, it is 601 pretty much useful only for a unidirectional tree of messages in a 602 single context. Engineering work needs to be done on identifiers 603 that could used in threads that cross media. Additionally, there is 604 likely work to be done for messages that may not be strictly ordered 605 in a thread. 607 The topics of "control panels" and automated introductions were 608 deemed appropriate for further research. 610 4.5 Message Transport 612 A central research topic that came out of the transport session was 613 that of multiple transports. It was felt that much research could be 614 done on the idea of transporting pieces of messages over separate 615 transport media in order to get the message to its final destination. 616 Especially in some high-latency, low-bandwidth environments, the 617 ability to run parallel transports with different parts of messages 618 could be extremely advantageous. The hard work in this area is re- 619 associating all of the pieces in a timely manner, and identifying the 620 single destination of the message when addressing will involve 621 multiple media. 623 A common theme that arose in several of the discussions (including 624 user control and message unification), but which figured prominently 625 in the transport discussion, was a need for some sort of identifier. 626 In the transport case, identifiers are necessary on two levels. 627 Identifiers are needed to mark the endpoints in message transport. 628 As described in the discussion, there are many cases where a message 629 could reasonably be delivered to different entities that might all 630 correspond to a single person. Some sort of identifier to indicate 631 the target person of the message, as well as identifiers for the 632 different endpoints, are all required in order to get any traction in 633 this area. In addition, identifiers are also required for the 634 messages being transported, as well as their component parts. 635 Certainly the idea of transporting different parts of a message over 636 different mechanisms requires the identification of the containing 637 message so that re-assembly can occur at the receiving end. However, 638 identifying the entire package is also necessary for those cases 639 where duplicate copies of a message might be sent using two different 640 mechanisms: The receiving end needs to find out that it has already 641 received a copy of the message through one mechanism and identify 642 that another copy of the message is simply a duplicate. 644 Workshop participants felt that at the very least, a standard 645 identifier syntax was a reasonable engineering work item that could 646 be tackled. Though there exist some identifier mechanisms in current 647 messaging protocols, none were designed to be used reliably across 648 different transport environments or in multiple contexts. There is 649 already a reasonable amount of engineering work done in the area of 650 uniform resource identifiers (URI) that participants felt could be 651 leveraged. Syntax would be required for both identifiers of messages 652 and their components as well as identifiers for endpoint entities. 654 Work on the general problem of identifier use might have some 655 tractable engineering aspects, especially in the area of message part 656 identifiers, but workshop participants felt that more of the work was 657 ripe for research. The ability to identify endpoints as belonging to 658 a single recipient, and to be able to distribute identifiers of those 659 endpoints with information about delivery preferences, is certainly 660 an area where research could be fruitful. Additionally the ability 661 to collect together identified message components transported through 662 different media, delivering to the correct end recipient with 663 duplicate removal and re-assembly, is also a worthwhile research 664 topic. 666 Package security was seen as an area for research. As described in 667 Section 3.5, the possibility that different components of messages 668 might travel over different media and need to be re-assembled at the 669 recipient end breaks certain end-to-end security assumptions that are 670 currently made. Participants felt that a worthwhile research goal 671 would be to examine security mechanisms which could be used for such 672 multi-component messages without sacrificing desirable security 673 features. 675 Finally, a more architectural topic was that of restartability. Most 676 current message transports, in the face of links with reliability 677 problems, will cancel and restart the transport of a message from the 678 beginning. Though some mechanisms do exist for restart mid-session, 679 they are not widely implemented, and they certainly can rarely be 680 used across protocol boundaries. Some architectural guidance on 681 restart mechanisms would be a useful addition. 683 4.6 Identity Hints and Key Distribution 685 It would be helpful to develop Internet-wide services to publish and 686 retrieve keying material. One possible solution is to build such a 687 service into Secure DNS, perhaps as an engineering item in an 688 existing working group. However, care is needed since that would 689 significantly increase the size and scope of DNS. A more research- 690 oriented approach would be to investigate the feasibility of building 691 Internet-wide key distribution services outside of DNS. In doing so, 692 it is important to keep in mind that the problem of distribution is 693 separate from the problem of enrollment, and that name subordination 694 (control over what entities are allowed to create sub-domains) 695 remains necessary. 697 Research may be needed to define the different audiences for message 698 security. For example, users of consumer-oriented messaging services 699 on the open Internet may not generally be willing or able to install 700 new trusted roots in messaging client software, which may hamper the 701 use of security technologies between businesses and customers. By 702 contrast, within a single organization it may be possible to deploy 703 new trusted roots more widely, since (theoretically) all of the 704 organization's computing infrastructure is under the centralized 705 control. 707 In defining security frameworks for messaging, it would be helpful to 708 more clearly specify the similarities and differences between various 709 messaging technologies with regard to trust models and messaging 710 metaphors (e.g., standalone messages in email, discrete conversations 711 in telephony, messaging sessions in instant messaging). The 712 implications of these trust models and messaging metaphors for 713 communications security have not been widely explored. 715 5. Security Considerations 717 Security is discussed in several sections of this document, 718 especially Section 3.5, Section 3.6, Section 4.5, and Section 4.6. 720 6. Acknowledgements 722 The IAB would like to thank QUALCOMM Incorporated for their 723 sponsorship of the meeting rooms and refreshments. 725 The editors would like to thank all of the workshop participants. 726 Eric Allman, Ted Hardie, and Cullen Jennings took helpful notes, 727 which eased the task of writing this document. 729 Authors' Addresses 731 Peter W. Resnick (editor) 732 Internet Architecture Board 733 QUALCOMM Incorporated 734 5775 Morehouse Drive 735 San Diego, CA 92121-1714 736 US 738 Phone: +1 858 651 4478 739 Email: presnick@qualcomm.com 740 URI: http://www.qualcomm.com/~presnick/ 741 Peter Saint-Andre (editor) 742 Jabber Software Foundation 743 P.O. Box 1641 744 Denver, CO 80201-1641 745 US 747 Phone: +1 303 308 3282 748 Email: stpeter@jabber.org 749 URI: http://www.jabber.org/people/stpeter.shtml 751 Appendix A. Participants 753 Eric Allman 754 Nathaniel Borenstein 755 Ben Campbell 756 Dave Crocker 757 Leslie Daigle 758 Mark Day 759 Mark Crispin 760 Steve Dorner 761 Lisa Dusseault 762 Kevin Fall 763 Ned Freed 764 Randy Gellens 765 Larry Greenfield 766 Ted Hardie 767 Joe Hildebrand 768 Paul Hoffman 769 Steve Hole 770 Scott Hollenbeck 771 Russ Housely 772 Cullen Jennings 773 Hisham Khartabil 774 John Klensin 775 John Levine 776 Rohan Mahy 777 Alexey Melnikov 778 Jon Peterson 779 Blake Ramsdell 780 Pete Resnick 781 Jonathan Rosenberg 782 Peter Saint-Andre 783 Greg Vaudreuil 785 Appendix B. Pre-Workshop Papers 787 The topic papers circulated before the workshop were as follows: 789 Calendaring Integration (Nathaniel Borenstein) 790 Channel Security (Russ Housely) 791 Collaborative Authoring (Lisa Dusseault) 792 Consent-Based Messaging (John Klensin) 793 Content Security (Blake Ramsdell) 794 Event Notifications (Joe Hildebrand) 795 Extended Messaging Services (Dave Crocker) 796 Group Messaging (Peter Saint-Andre) 797 Identity and Reputation (John Levine) 798 Instant Messaging and Presence Issues in Messaging (Ben Campbell) 799 Large Email Environments (Eric Allman) 800 Mail/News/Blog Convergence (Larry Greenfield) 801 Messaging and Spam (Cullen Jennings) 802 Messaging Metaphors (Ted Hardie) 803 MUA/MDA, MUA/MSA, and MUA/Message-Store Interaction (Mark Crispin) 804 Presence for Consent-Based Messaging (Jon Peterson) 805 Rich Payloads (Steve Hole) 806 Session-Oriented Messaging (Rohan Mahy) 807 Spam Expectations for Mobile Devices (Greg Vaudreuil) 808 Communication in Difficult-to-Reach Networks (Kevin Fall) 809 Store-and-Forward Needs for IM (Hisham Khartabil) 810 Syndication (Paul Hoffman) 811 Transport Security (Alexey Melnikov) 812 VoIP Peering and Messaging (Jonathan Rosenberg) 813 Webmail, MMS, and Mobile Email (Randy Gellens) 815 Intellectual Property Statement 817 The IETF takes no position regarding the validity or scope of any 818 Intellectual Property Rights or other rights that might be claimed to 819 pertain to the implementation or use of the technology described in 820 this document or the extent to which any license under such rights 821 might or might not be available; nor does it represent that it has 822 made any independent effort to identify any such rights. Information 823 on the procedures with respect to rights in RFC documents can be 824 found in BCP 78 and BCP 79. 826 Copies of IPR disclosures made to the IETF Secretariat and any 827 assurances of licenses to be made available, or the result of an 828 attempt made to obtain a general license or permission for the use of 829 such proprietary rights by implementers or users of this 830 specification can be obtained from the IETF on-line IPR repository at 831 http://www.ietf.org/ipr. 833 The IETF invites any interested party to bring to its attention any 834 copyrights, patents or patent applications, or other proprietary 835 rights that may cover technology that may be required to implement 836 this standard. Please address the information to the IETF at 837 ietf-ipr@ietf.org. 839 Disclaimer of Validity 841 This document and the information contained herein are provided on an 842 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 843 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 844 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 845 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 846 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 847 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 849 Copyright Statement 851 Copyright (C) The Internet Society (2005). This document is subject 852 to the rights, licenses and restrictions contained in BCP 78, and 853 except as set forth therein, the authors retain all their rights. 855 Acknowledgment 857 Funding for the RFC Editor function is currently provided by the 858 Internet Society.