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