Network Working Group                                    P. Resnick, Ed.
Request for Comments: 4417                                           IAB
Category: Informational                              P. Saint-Andre, Ed.
                                                                     JSF
                                                           February 2006
        
Network Working Group                                    P. Resnick, Ed.
Request for Comments: 4417                                           IAB
Category: Informational                              P. Saint-Andre, Ed.
                                                                     JSF
                                                           February 2006
        

Report of the 2004 IAB Messaging Workshop

2004年IAB信息工作坊报告

Status of This Memo

关于下段备忘

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2006).

版权所有(C)互联网协会(2006年)。

Abstract

摘要

This document reports the outcome of a workshop held by the Internet Architecture Board (IAB) on the future of Internet messaging. The workshop was held on 6 and 7 October 2004 in Burlingame, CA, USA. The goal of the workshop was to examine the current state of different messaging technologies on the Internet (including, but not limited to, electronic mail, instant messaging, and voice messaging), to look at their commonalities and differences, and to find engineering, research, and architectural topics on which future work could be done. This report summarizes the discussions and conclusions of the workshop and of the IAB.

本文件报告了互联网体系结构委员会(IAB)举办的关于互联网信息未来的研讨会的结果。研讨会于2004年10月6日和7日在美国加利福尼亚州伯林盖姆举行。研讨会的目标是研究互联网上不同消息传递技术(包括但不限于电子邮件、即时消息和语音消息传递)的现状,了解它们的共性和差异,并找到工程,研究,以及未来可以进行工作的架构主题。本报告总结了研讨会和IAB的讨论和结论。

Table of Contents

目录

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

Current email infrastructure is a mixture of facilities to accomplish its task of end-to-end communications through a relay mesh. That mixture has come about as requirements have changed over the years. Discussions recur over the years, often including complaints that some desired features of email (such as internationalization, efficient encoding of structured data, trusted communication) are ill-served by the current infrastructure, or that some of the current infrastructure seems to be adversely affected by current problems on the Internet (most recently including problems such as spam, viruses, and lack of security infrastructure). For many years, the daunting task of revamping email infrastructure has been considered, with justifiably little enthusiasm for taking on such a task. However, there has been some recent informal discussion on the kinds of things that would be desirable in a "next generation" email.

当前的电子邮件基础设施是通过中继网完成端到端通信任务的各种设施的混合体。随着多年来需求的变化,这种混合已经出现。多年来反复出现讨论,通常包括抱怨电子邮件的某些预期功能(如国际化、结构化数据的有效编码、可信通信)不受当前基础设施的支持,或者当前的一些基础设施似乎受到互联网上当前问题的不利影响(最近包括垃圾邮件、病毒和缺乏安全基础设施等问题)。多年来,人们一直在考虑改造电子邮件基础设施这项艰巨的任务,但毫无理由对承担这项任务没有多少热情。然而,最近有一些非正式的讨论,讨论了“下一代”电子邮件中需要做的事情。

At the same time, other messaging infrastructures (including those associated with "instant messaging" and "web logging") are currently being deployed that appear to address many of the above desired features and outstanding problems, while adding many features not currently considered part of traditional email (like prior-consent-based acceptance of messages). However, each of these technologies (at least in their current deployment) seem to lack some of the features commonly associated with email (such as selective and partial message delivery, queued multi-hop relaying, offline message management, and efficient non-textual content delivery).

与此同时,目前正在部署其他消息传递基础设施(包括与“即时消息传递”和“web日志记录”相关的基础设施),这些基础设施似乎可以解决上述许多需要的功能和未决问题,同时添加了许多目前不被视为传统电子邮件的一部分的功能(如基于事先同意的邮件接收)。但是,这些技术(至少在当前部署中)似乎都缺少一些通常与电子邮件相关的功能(如选择性和部分邮件传递、排队多跳中继、脱机邮件管理和高效的非文本内容传递)。

The Internet Architecture Board (IAB) believed that the time was ripe to examine the current state of messaging technologies on the Internet and to see if there are areas of work that can be taken on to advance these technologies. Therefore, the IAB held a workshop on Internet messaging, taking some of the above issues as input, in order to formulate some direction for future study of the area of messaging.

互联网体系结构委员会(IAB)认为,现在时机已经成熟,可以检查互联网上消息传递技术的现状,并查看是否有可以推动这些技术的工作领域。因此,IAB举办了一个关于互联网信息的研讨会,将上述一些问题作为投入,以便为信息领域的未来研究制定一些方向。

The topic of messaging is broad, and the boundaries of what counts as messaging are not always well-defined. Rather than limit themselves to a philosophical discussion of the nature of messages, the workshop participants adopted the attitude of "we know it when we see it" and used as their primary examples such well-established types of messaging as email and instant messaging (IM), while also discussing more "peripheral" types of messaging such as voice messaging and event notifications. (Message queuing systems with guaranteed delivery and transactional integrity, such as those used in enterprise workflow engines and some "web services" architectures, were operationally if not intentionally out of scope.) The participants worked to discover common themes that apply to all the

消息传递的主题是广泛的,消息传递的边界并不总是很明确。研讨会参与者没有将自己局限于对信息本质的哲学讨论,而是采取了“我们看到它时就知道”的态度,并将电子邮件和即时消息(IM)等公认的信息类型作为主要示例,同时还讨论了更多的“外围”信息消息类型,如语音消息和事件通知。(具有保证交付和事务完整性的消息队列系统,如企业工作流引擎和某些“web服务”体系结构中使用的消息队列系统,如果不是有意的话,在操作上也超出了范围。)参与者努力发现适用于所有应用程序的共同主题

types of messaging under consideration. Among the themes identified were the following:

正在考虑的消息类型。确定的主题包括:

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

o 发件人和收件人的授权o消息传递参数的协商o同意模型和隐私o身份提示、信誉和密钥分发o消息传递模型的跨协议统一o使用户能够更好地控制消息传递o传输问题(不可靠链接、推/拉等)o消息组织(例如,对话和线程)

Purposely missing from the foregoing list is the topic of unsolicited commercial email or unsolicited bulk email (UCE or UBE, colloquially known as "spam") and analogous communications in other messaging environments such as instant messaging ("spim") and Internet telephony ("spit"). While this topic was an impetus for the IAB's holding the workshop, it was kept off the workshop agenda due to concerns that it would crowd out discussion of other messaging-related issues. The more general topics of authorization and identity were thought to be broad enough to cover the architectural issues involved with spam without devolving into more unproductive discussions.

上述列表中故意遗漏的主题是未经请求的商业电子邮件或未经请求的批量电子邮件(UCE或UBE,俗称“垃圾邮件”)以及其他消息传递环境中的类似通信,如即时消息传递(“spim”)和互联网电话(“spit”)。虽然这一主题推动了IAB举办研讨会,但由于担心它会排挤其他与信息传递相关的问题的讨论,因此被排除在研讨会议程之外。授权和身份等更一般的主题被认为足够广泛,可以涵盖垃圾邮件所涉及的体系结构问题,而不会演变成更没有成果的讨论。

This document is structured so as to provide an overview of the discussion flow as well as proposed recommendations of the workshop. Section 3 summarizes the discussions that occurred during the workshop on various topics or themes, while Section 4 provides an overview of recommended research topics and protocol definition efforts that resulted from the workshop. Section 5 provides some perspective on the security-related aspects of the topics discussed during the workshop. Appendix B lists the pre-workshop topic papers submitted by workshop participants as background for the workshop discussions.

本文件的结构旨在概述研讨会的讨论流程和建议。第3节总结了研讨会期间就各种主题进行的讨论,而第4节概述了建议的研究主题和研讨会产生的协议定义工作。第5节对研讨会期间讨论的主题的安全相关方面提供了一些看法。附录B列出了研讨会参与者提交的研讨会前专题文件,作为研讨会讨论的背景。

2. Methodology
2. 方法论

Prior to the workshop, brief topic papers were submitted to set the context for the discussions to follow; a list of the papers and their authors is provided in Appendix B of this document.

研讨会之前,提交了简短的专题文件,为随后的讨论确定背景;本文件附录B中提供了论文及其作者的列表。

During the workshop itself, discussion centered on several topics or themes, as summarized in the following sections. Naturally, it was not possible in a two-day workshop to treat these topics in depth; however, rough consensus was reached on the importance of these topics, if not always on the details of potential research programs and protocol standardization efforts that might address the issues

在研讨会期间,讨论集中在几个主题上,如下几节所述。当然,在为期两天的研讨会上不可能深入讨论这些主题;然而,就这些主题的重要性达成了粗略的共识,如果不总是就可能解决这些问题的潜在研究计划和方案标准化工作的细节达成一致的话

raised. It is hoped that these summaries will inspire work by additional investigators.

提高。希望这些总结将激励更多的研究人员开展工作。

The in-workshop discussions quite naturally fell into three kinds of "tracks": (1) possible engineering tasks to recommend to the IESG and other standardization groups, (2) "blue sky" research topics to recommend to the IRTF and other researchers, and (3) general architectural or "framework" issues for consideration by both engineers and researchers alike. After a full-group discussion each morning to identify possible topics for more in-depth investigation, participants self-selected for involvement in one of three "break-out" sessions. Toward the end of each day, the full groups reconvened, gathered reports from the break-out discussion leaders, and attempted to come to consensus regarding lessons learned and recommendations for further research. The results of the two-day workshop therefore consist of discussion issues and research/ engineering recommendations related to the six topics described in this report.

车间内的讨论很自然地分为三类“轨道”:(1)向IESG和其他标准化小组推荐的可能工程任务,(2)向IRTF和其他研究人员推荐的“蓝天”研究主题,以及(3)总体架构或“框架”供工程师和研究人员考虑的问题。在每天早上进行完整的小组讨论以确定可能的主题进行更深入的调查后,参与者自行选择参加三次“突破”会议中的一次。每天快结束时,整个小组重新召集,从突发讨论领导人那里收集报告,并试图就所吸取的教训和进一步研究的建议达成共识。因此,为期两天的研讨会的结果包括与本报告所述六个主题相关的讨论问题和研究/工程建议。

3. Issues
3. 问题
3.1. Authorization
3.1. 批准

It is one thing for a sender to send a message, and another thing for the intended recipient to accept it. The factors that lead a recipient to accept a message include the identity of the sender, previous experience with the sender, the existence of an ongoing conversation between the parties, meta-data about the message (e.g., its subject or size), the message medium (e.g., email vs. IM), and temporal or psychological factors. Authorization or acceptance applies most commonly at the level of the message or the level of the sender, and occasionally also at other levels (conversation thread, medium, sender domain).

发送者发送消息是一回事,而预期的接收者接受消息是另一回事。导致接收者接受消息的因素包括发送者的身份、先前与发送者的经历、双方之间正在进行的对话的存在、关于消息的元数据(例如,其主题或大小)、消息媒介(例如,电子邮件与IM)以及时间或心理因素。授权或接受通常应用于消息级别或发件人级别,偶尔也应用于其他级别(对话线程、媒体、发件人域)。

Traditionally, sender authorization has been handled by recipient-defined block and allow lists (also called "blacklists" and "whitelists"). Block lists are of limited value, given the ease of gaining or creating new messaging identities (e.g., an email address or IM address). Allow lists are much more effective (since the list of people you like or want to communicate with is smaller than the large universe of people you don't), but they make it difficult for a sender to initiate communication with a new or previously unknown recipient. The workshop participants discussed several ways around this problem, including reputation systems and better ways for one person to introduce another person to a third party (e.g., through signed invitations).

传统上,发送方授权由接收方定义的阻止和允许列表(也称为“黑名单”和“白名单”)处理。由于易于获取或创建新的消息身份(例如电子邮件地址或IM地址),阻止列表的价值有限。允许列表更有效(因为您喜欢或想与之交流的人的列表比您不喜欢或不想与之交流的人的列表要小),但它们使发件人很难与新的或以前未知的收件人开始交流。研讨会参与者讨论了围绕这个问题的几种方法,包括声誉系统和一个人向第三方介绍另一个人的更好方法(例如,通过签署邀请)。

Reputation systems may be especially worthy of future research, since they emulate a pattern that is familiar from real life. (It may also be valuable to distinguish between (1) reputation as the reactive assessment of a sender created by one or more recipients based on message history and (2) accreditation as a proactive assessment provided by trusted third parties.) Reputation might be based on summing an individual's "scores" provided by recipients on the network. (Naturally, the more important reputation becomes, the more bad actors might attempt to sabotage any given reputation system, so that a distributed as opposed to centralized system might be more desirable.) The actions taken by any given recipient based on the sender's reputation would not necessarily be limited to a simple allow/deny decision; more subtle actions might include placing messages from individuals with lower reputation scores into separate inboxes or redirecting them to other media (e.g., from IM to email).

声誉系统可能特别值得未来研究,因为它们模仿的是现实生活中熟悉的模式。(区分(1)由一个或多个收件人根据邮件历史记录创建的对发件人的反应性评估的声誉和(2)由可信第三方提供的主动性评估的认证也可能很有价值。)声誉可能基于对网络上收件人提供的个人“分数”的总和。(当然,声誉越重要,坏行为人就越可能试图破坏任何给定的声誉系统,因此分布式而非集中式系统可能更可取。)任何给定收件人基于发件人声誉采取的行动不一定局限于简单的允许/拒绝决定;更微妙的行动可能包括将来自声誉分数较低的个人的邮件放入单独的收件箱,或将其重定向到其他媒体(例如,从IM到电子邮件)。

3.2. Multiple Communication Channels
3.2. 多通信通道

It is a fact of life that many people use multiple forms of messaging channels: phone, email, IM, pager, and so on. Unfortunately, this can make it difficult for a sender or initiator to know the best way to contact a recipient at any given time. One model is for the initiator to guess, for example, by first sending an email message and then escalating to pager or telephone if necessary; this may result in delivery of redundant messages to the recipient. A second model is for the recipient to publish updated contact information on a regular basis, perhaps as one aspect of his or her presence; this might enable the initiator to determine beforehand which contact medium is most appropriate. A third model is for the recipient to use some kind of "unifier" service that enables intelligent routing of messages or notifications to the recipient based on a set of delivery rules (e.g., "notify me via pager if I receive a voicemail message from my boss after 17:00").

事实上,许多人使用多种形式的消息传递渠道:电话、电子邮件、IM、寻呼机等等。不幸的是,任何一个发起者或接收者在任何时候都很难知道这一点。一种模式是发起者猜测,例如,首先发送电子邮件,然后在必要时升级到寻呼机或电话;这可能会导致向收件人传递冗余邮件。第二种模式是接收者定期发布更新的联系信息,可能是作为其存在的一个方面;这可能使启动器能够事先确定哪种接触介质最合适。第三种模式是让收件人使用某种“统一”服务,该服务能够根据一组传递规则(例如,“如果我在17:00后收到老板的语音邮件,请通过寻呼机通知我”)将消息或通知智能路由到收件人。

The workshop participants did not think it necessary to choose between these models, but did identify several issues that are relevant in unifying or at least coordinating communication across multiple messaging channels:

研讨会参与者认为没有必要在这些模型之间进行选择,但确实确定了在统一或至少协调多个消息传递渠道之间的通信方面相关的几个问题:

o While suppression of duplicate messages could be enabled by setting something like a "seen" flag on copies received via different messaging media, in general the correlation of multi-channel, multi-message exchanges is not well supported by existing standards. o A recipient could communicate his or her best contact mechanism to the initiator by explicitly granting permission to the initiator, perhaps by means of a kind of "authorization token".

o 虽然可以通过在通过不同消息传递媒体接收的副本上设置类似于“可见”标志的内容来抑制重复消息,但现有标准通常不支持多通道、多消息交换的相关性。o接收者可以通过向发起人明确授予权限(可能是通过一种“授权令牌”)向发起人传达其最佳联系机制。

o It may be worthwhile to define frameworks or protocols for recipient-defined delivery rules. Currently, routing decisions tend to be made mostly by the sender through the choice of a messaging channel, but in the future the recipient may play a larger role in such decisions. o The logic behind contact publication needs to be explored, for example, whether it is an aspect of or extension to presence and whether contact addresses for one medium are best obtained by communicating in a different medium ("email me to get my mobile number").

o 为收件人定义的交付规则定义框架或协议可能是值得的。目前,路由决策往往主要由发送方通过选择消息传递通道来做出,但在未来,接收方可能会在此类决策中扮演更大的角色。o需要探索联系人发布背后的逻辑,例如,它是否是存在的一个方面或扩展,以及一种媒体的联系人地址是否最好通过在不同媒体中进行通信(“通过电子邮件向我发送电子邮件以获取我的手机号码”)。

A multiplicity of delivery channels also makes it more complex for a senders to establish a "reliable" relationship with a recipient. From the sender's point of view, it is not obvious that a recipient on one channel is the same recipient on another channel. How these recipient "identities" are tied together is an open question.

传递渠道的多样性也使得发送方与接收方建立“可靠”关系变得更加复杂。从发送者的角度来看,一个频道上的接收者是否与另一个频道上的接收者相同并不明显。这些收件人的“身份”是如何联系在一起的,这是一个悬而未决的问题。

Another area for investigation is that of recipient capabilities. When the sender does not have capability information, the most common result is downgrading to a lowest common denominator of communication, which seriously underutilizes the capabilities of the entire system. Previous standards efforts (e.g., LDAP, Rescap, vCard, Conneg) have attempted to address parts of the capability puzzle, but without great success.

另一个需要调查的领域是接受者的能力。当发送方没有能力信息时,最常见的结果是降低到通信的最低公分母,这严重低估了整个系统的能力。以前的标准工作(如LDAP、Rescap、vCard、Conneg)试图解决部分功能难题,但没有取得很大成功。

The existing deployment model uses several out-of-band mechanisms for establishing communications in the absence of programmatic capabilities information. Many of these mechanisms are based on direct human interaction and social policies, which in many cases are quite efficient and more appropriate than any protocol-based means. However, a programmatic means for establishing communications between "arms length" parties (e.g., business-to-business and business-to-customer relationships) might be very beneficial.

现有的部署模型使用几种带外机制,在缺少编程能力信息的情况下建立通信。这些机制中有许多是基于直接的人际互动和社会政策,在许多情况下,这些机制比任何基于协议的手段都更加有效和适当。然而,在“公平交易”各方(例如,企业对企业和企业对客户关系)之间建立沟通的程序化手段可能非常有益。

Any discussion of relationships inevitably leads to a discussion of trust (e.g., "from what kinds of entities do I want to receive messages?"). While this is a large topic, the group did discuss several ideas that might make it easier to broker communications within different relationships, including:

对关系的任何讨论都不可避免地导致对信任的讨论(例如,“我希望从哪种实体接收消息?”)。虽然这是一个很大的话题,但小组确实讨论了一些想法,这些想法可能会使在不同的关系中进行沟通变得更容易,包括:

o Whitelisting is the explicit definition of a relationship from the recipient's point of view, consisting of a list of senders with whom a recipient is willing to engage in conversation. While allow lists can be a workable solution, they are a relatively static authorization scheme.

o 白名单是从接收者的角度对关系的明确定义,包括接收者愿意与其进行对话的发送者列表。虽然允许列表是一个可行的解决方案,但它们是一个相对静态的授权方案。

o Token-based authorization enables the recipient to define a one-time or limited-time relationship with a sender. The issuer possesses a token that grants a limited-time right to communicate with the recipient. This is a more dynamic authorization scheme. o Rule-based authorization involves an algorithmic assessment of the viability of a relationship based on a wide set of criteria. This is a more general authorization scheme that can incorporate both allow lists and tokens, plus additional evaluation criteria such as message characterization and issuer characterization.

o 基于令牌的授权使收件人能够定义与发件人的一次性或有限时间关系。发卡机构拥有一个令牌,该令牌授予与接收方进行通信的有限时间权利。这是一个更动态的授权方案。o基于规则的授权涉及基于一系列标准对关系可行性的算法评估。这是一个更通用的授权方案,它可以合并允许列表和令牌,以及其他评估标准,如消息特征和颁发者特征。

3.3. Negotiation
3.3. 谈判

In the area of negotiation, the workshop participants focused mainly on the process by which a set of participants agree on the media and parameters by which they will communicate. (One example of the end result of such a "rendezvous" negotiation is a group of colleagues who agree to hold a voice conference, with a textual "groupchat" as a secondary communications channel.) In order to enable cross-media negotiation, it may be necessary to establish a bridge between various identities. For example, the negotiation may occur via email, but the communication may occur via phone, and in order to authorize participants the conference software needs to know their phone numbers, not their email addresses. Furthermore, the parameters to be negotiated may include a wide variety of aspects, including:

在谈判领域,讲习班与会者主要侧重于一系列与会者就其交流的媒体和参数达成一致意见的过程。(这种“会合”谈判的最终结果的一个例子是,一群同事同意举行语音会议,以文本“groupchat”作为第二通信渠道。)为了实现跨媒体谈判,可能需要在各种身份之间建立一座桥梁。例如,谈判可能通过电子邮件进行,但通信可能通过电话进行,为了授权与会者,会议软件需要知道他们的电话号码,而不是他们的电子邮件地址。此外,待协商的参数可包括多种方面,包括:

o Prerequisites for the communication (e.g., distribution of a "backgrounder" document). o Who will initiate the communication. o Who will participate in the communication. o The primary "venue" (e.g., a telephone number that all participants will call). o One or more secondary venues (e.g., a chatroom address). o Backup plans if the primary or secondary venue is not available. o The topic or topics for the discussion. o The identities of administrators or moderators. o Whether or not the discussion will be logged or recorded. o Scheduling of the event, including recurrence (e.g., different instances may have different venues or other details).

o 沟通的先决条件(如分发“背景”文件)。o谁将发起沟通。o谁将参与交流。o主要“地点”(例如,所有参与者将拨打的电话号码)。o一个或多个次要场所(例如聊天室地址)。o如果主要或次要场馆不可用,则制定备份计划。o讨论的一个或多个主题。o管理员或版主的身份。o讨论是否将被记录或记录。o活动安排,包括重复(例如,不同的实例可能有不同的地点或其他细节)。

Indeed, in some contexts it might even be desirable to negotiate or re-negotiate parameters after communication has already begun (e.g., to invite new participants or change key parameters such as logging). While the workshop participants recognized that in-depth negotiation of a full set of parameters is likely to be unnecessary in many classes of communication, parts of a generalized framework or protocol for the negotiation of multiparty communication might prove useful in a wide range of applications and contexts.

事实上,在某些情况下,甚至可能希望在通信已经开始后协商或重新协商参数(例如,邀请新参与者或更改关键参数,如日志记录)。虽然讲习班与会者认识到,在许多类别的通信中,可能不需要对一整套参数进行深入谈判,但多方通信谈判的一般框架或协议的某些部分可能在广泛的应用和环境中证明是有用的。

3.4. User Control
3.4. 用户控制

A common perception among "power users" (and, increasingly, average users) on the Internet is that messaging is not sufficiently under their control. This is not merely a matter of unsolicited communications, but also of managing multiple messaging media and handling the sheer volume of messages received from familiar and unfamiliar senders alike. Currently, individuals attempt to cope using various personal techniques and ad hoc software tools, but there may be an opportunity to provide more programmatic support within Internet protocols and technologies.

互联网上的“超级用户”(以及越来越多的普通用户)普遍认为,他们无法充分控制信息传递。这不仅仅是一个主动通信的问题,也是一个管理多个消息媒体和处理从熟悉和不熟悉的发件人收到的大量消息的问题。目前,个人试图使用各种个人技术和特别软件工具来应对,但可能有机会在互联网协议和技术中提供更多的编程支持。

One area of investigation is message filtering. Based on certain information -- the identity of the sender and/or recipient(s), the sender's reputation, the message thread or conversational context, message headers, message content (e.g., the presence of attachments), and environmental factors such as time of day or personal mood -- a user or agent may decide to take one of a wide variety actions with regard to a message (bounce, ignore, forward, file, replicate, archive, accept, notify, etc.). While it is an open question how much formalization would be necessary or even helpful in this process, the workgroup participants identified several areas of possible investigation:

调查的一个领域是消息过滤。基于某些信息——发送者和/或接收者的身份、发送者的声誉、消息线程或对话上下文、消息头、消息内容(例如,附件的存在),环境因素,如一天中的时间或个人情绪——用户或代理可能会决定对消息采取各种各样的操作之一(跳出、忽略、转发、归档、复制、归档、接受、通知等)。虽然在这一过程中,有多少形式化是必要的,甚至是有帮助的,这是一个悬而未决的问题,但工作组参与者确定了几个可能的调查领域:

o Cross-media threads and conversations -- it may be helpful to determine ways to tag messages as belonging to a particular thread or conversation across media (e.g., a forum discussion that migrates to email or IM), either during or after a message exchange. o Communication hierarchies -- while much of the focus is on messages, often a message does not stand alone but exists in the context of higher-level constructs such as a thread (i.e., a coherent or ordered set of messages within a medium), a conversation (i.e., a set of threads that may cross media), or an activity (a set of conversations and related resources, such as documents). o Control protocols -- the workgroup participants left as an open question whether there may be a need for a cross-service control protocol for use in managing communications across messaging media.

o 跨媒体线程和对话——在消息交换期间或之后,确定将消息标记为属于特定线程或跨媒体对话(例如,迁移到电子邮件或IM的论坛讨论)的方式可能会有所帮助。o通信层次结构——虽然大部分重点放在消息上,但消息通常不是独立的,而是存在于更高层次结构的上下文中,如线程(即,媒体中一致或有序的消息集)、对话(即,可能跨媒体的线程集)或活动(一组对话和相关资源,如文档)。o控制协议——工作组参与者留下了一个悬而未决的问题,即是否需要跨服务控制协议来管理跨消息传递媒体的通信。

3.5. Message Transport
3.5. 消息传输

Different messaging media use different underlying transports. For instance, some messaging systems are more tolerant of slow links or lossy links, while others may depend on less loss-tolerant transport mechanisms. Integrating media that have different transport profiles can be difficult. For one, assuming that the same addressing

不同的消息传递媒体使用不同的底层传输。例如,一些消息传递系统更能容忍慢速链路或有损链路,而另一些则可能依赖于较低的容错传输机制。集成具有不同传输模式的介质可能很困难。首先,假设相同的地址

endpoint represents the same entity over time may not be warranted (it is possible that further work in identifying, addressing, and discovering endpoints may be appropriate, even at the URI level). It is also possible that the same endpoint or entity could be available via different transport mechanisms at different times, or even available via multiple transports at the same time. The process of choosing an appropriate transport mechanism when there are multiple paths introduces addressing issues that have not yet been dealt with in Internet protocol development (possible heuristics might include predictive routing, opportunistic routing, and scheduled routing). For links that can be unreliable, there may be value in being able to gracefully restart the link after any given failure, possibly by switching to a different transport mechanism.

端点在一段时间内代表同一个实体可能是不可靠的(识别、寻址和发现端点的进一步工作可能是适当的,即使是在URI级别)。同样的端点或实体也可能在不同的时间通过不同的传输机制可用,甚至可以在同一时间通过多个传输可用。当存在多条路径时,选择适当的传输机制的过程引入了解决Internet协议开发中尚未解决的问题(可能的启发式方法可能包括预测路由、机会路由和计划路由)。对于可能不可靠的链路,在任何给定故障后能够优雅地重新启动链路可能有价值,可能是通过切换到不同的传输机制。

Another issue that arises in cross-media and cross-transport integration is synchronization of references. This applies to particular messages but might also apply to message fragments. It may be desirable for some message fragments, such as large ancillary data, to be transported separately from others, for example small essential text data. Message fragments might also be forwarded, replicated, archived, etc., separately from other parts of a message. One factor relevant to synchronization across transports is that some messaging media are push-oriented (e.g., IM) whereas others are generally pull-oriented (e.g., email); when content is pushed to a recipient in one medium before it has been pulled by the recipient in another medium, it is possible for content references to get out of sync.

跨媒体和跨传输集成中出现的另一个问题是引用的同步。这适用于特定消息,但也可能适用于消息片段。可能需要将一些消息片段(例如大型辅助数据)与其他消息片段(例如小型基本文本数据)分开传输。消息片段也可以与消息的其他部分分开转发、复制、存档等。与跨传输同步相关的一个因素是,一些消息传递媒体是面向推的(例如IM),而其他媒体通常是面向拉的(例如电子邮件);当内容在一种媒体中被推送到另一种媒体中的收件人之前,内容引用可能会失去同步。

If message fragments can be transported over different media, possibly arriving at separate times or through separate paths, the issue of package security becomes a serious one. Traditionally, messages are secured by encrypting the entire package at the head end and then decrypting it on the receiving end. However, if we want to allow transports to fragment messages based upon the media types of the parts, that approach will not be feasible.

如果消息片段可以在不同的媒体上传输,可能在不同的时间或通过不同的路径到达,那么包安全性问题就成为一个严重的问题。传统上,通过在前端加密整个包,然后在接收端解密来保护消息。但是,如果我们希望允许传输根据部件的媒体类型对消息进行分段,那么这种方法是不可行的。

3.6. Identity Hints and Key Distribution
3.6. 身份提示和密钥分配

While it is widely recognized that both message encryption and authentication of conversation partners are highly desirable, the consensus of the workshop participants was that current business and implementation models in part discourage deployment of existing solutions. For example, it is often hard to get new root certificates installed in clients, certificates are (or are perceived to be) difficult or expensive to obtain, one-click or zero-click service enrollment is a worthy but seemingly unreachable goal, and

虽然人们普遍认为,消息加密和对话伙伴身份验证都是非常可取的,但研讨会参与者的共识是,当前的业务和实施模式在一定程度上阻碍了现有解决方案的部署。例如,通常很难在客户端中安装新的根证书,证书很难(或被认为)获得,或者很昂贵,一键或零键服务注册是一个有价值但似乎无法实现的目标,以及

once one has created a public/private key pair and certified the public key, it is less than obvious how to distribute that certificate or discover other people's certificates.

一旦创建了公钥/私钥对并认证了公钥,如何分发该证书或发现其他人的证书就不那么明显了。

One factor that may make widespread message encryption more feasible is that email, instant messaging, and Internet telephony have quite similar trust models. Yet the definition of communication differs quite a bit between these technologies: in email "the message is the thing", and it is a discrete object in its own right; in telephony the focus is on the real-time flow of a conversation or session rather than discrete messages; and IM seems to hold a mediate position since it is centered on the rapid, back-and-forth exchange of text messages (which can be seen as messaging sessions).

电子邮件、即时消息和互联网电话具有非常相似的信任模型,这可能使广泛使用的消息加密更加可行。然而,这些技术对通信的定义有很大的不同:在电子邮件中,“信息就是东西”,它本身就是一个离散的对象;在电话技术中,重点是对话或会话的实时流,而不是离散的消息;而即时通讯似乎占据了中间位置,因为它的核心是快速、来回地交换短信(可以看作是信息会话)。

Another complicating factor is the wide range of contexts in which messaging technologies are used: everything from casual conversations in public chatrooms and social networking applications, through communications between businesses and customers, to mission-critical business-to-business applications such as supply chain management. Different audiences may have different needs with regard to messaging security and identity verification, resulting in varying demand for services such as trusted third parties and webs of trust.

另一个复杂的因素是消息传递技术的广泛使用环境:从公共聊天室和社交网络应用程序中的随意对话,到企业与客户之间的通信,再到关键业务对企业应用程序,如供应链管理。不同的受众在消息传递安全性和身份验证方面可能有不同的需求,从而导致对服务(如受信任的第三方和信任网络)的不同需求。

In the context of communication technologies, identity hints -- shared knowledge, conversational styles, voice tone, messaging patterns, vocabulary, and the like -- can often provide more useful information than key fingerprints, digital signatures, and other electronic artifacts, which are distant from the experience of most end users. To date, the checking of such identity hints is intuitive rather than programmatic.

在通信技术的背景下,身份提示——共享知识、会话风格、声调、消息传递模式、词汇等——通常可以提供比关键指纹、数字签名和其他电子制品更有用的信息,而这些与大多数最终用户的体验相去甚远。迄今为止,这种身份提示的检查是直观的,而不是编程的。

4. Recommendations
4. 建议
4.1. Authorization
4.1. 批准

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

从授权讨论中得出的一个明显需要的工程项目是分布式信誉服务。与会者一致认为,无论在授权电文方面还需要做什么,电文接收人在某个时候都希望能够检查电文发送者的信誉。这对于收件人之前没有经验的发件人尤其有用;i、 例如,使用声誉服务作为获得“陌生人介绍”的一种方式。显然,这种声誉服务需要分散;虽然单一的集中式信誉服务在某些情况下可能有用,但它不能扩展到Internet范围的服务。

Two potential research topics in authorization were discussed. First, a good deal of discussion centered around the use of whitelists and blacklists in authorization decision, but it was thought that research was necessary to examine the relative usefulness of each of the approaches fully. It was clear to the participants that blacklists can weed out known non-authorized senders, but do not stop "aggressive" unwanted senders because of the ease of simply obtaining a new identity. Whitelists can be useful for limiting messages to only those known to the recipient, but would require the use of some sort of introduction service in order to allow for messages from unknown parties. Participants also thought that there might be useful architectural work done in this area.

讨论了授权中的两个潜在研究课题。首先,大量讨论集中在授权决策中白名单和黑名单的使用上,但认为有必要进行研究,以全面检查每种方法的相对有用性。参与者很清楚,黑名单可以清除已知的未经授权的发件人,但不能阻止“攻击性”的不需要的发件人,因为很容易获得新身份。白名单有助于将消息限制为收件人已知的消息,但需要使用某种介绍服务,以便允许来自未知方的消息。与会者还认为,在这一领域可能会开展有益的建筑工作。

The other potential research area was in recipient responses to authorization decisions. Upon making an authorization decision, recipients have to do two things: First, obviously the recipient must dispatch the message in some way either to deliver it or to deny it. But that decision will also have side effects back into the next set of authorization decisions the recipient may make. The decision may feed back into the reputation system, either "lauding" or "censuring" the sender of the message.

另一个潜在的研究领域是接收者对授权决策的反应。在做出授权决策时,收件人必须做两件事:首先,显然,收件人必须以某种方式发送消息以传递消息或拒绝消息。但这一决定也会产生副作用,影响接收者可能做出的下一组授权决定。这一决定可能会反馈到声誉系统,要么“赞扬”要么“谴责”消息发送者。

4.2. Multiple Communication Channels
4.2. 多通信通道

Several interesting and potentially useful ideas were discussed during the session, which the participants worked to transform into research or engineering tasks, as appropriate.

在会议期间,与会者讨论了一些有趣且可能有用的想法,并在适当情况下将其转化为研究或工程任务。

In the area of contact information management, the workshop participants identified a possible engineering task to define a service that publishes contact information such as availability, capabilities, channel addresses (routing information), preferences, and policies. While aspects of this work have been attempted previously within the IETF (with varying degrees of success), there remain many potential benefits with regard to managing business-to-business and business-to-customer relationships.

在联系信息管理领域,研讨会参与者确定了一项可能的工程任务,以定义发布联系信息(如可用性、功能、渠道地址(路由信息)、首选项和策略)的服务。虽然之前在IETF中已经尝试了这项工作的各个方面(取得了不同程度的成功),但在管理企业对企业和企业对客户关系方面仍然存在许多潜在的好处。

The problem of suppressing redundant messages is becoming more important as the use of multiple messaging channels becomes the rule for most Internet users, and as users become accustomed to receiving notifications in one channel of communications received in another channel. Unfortunately, there are essentially no standards for cross-referencing and linking of messages across channels; standards work in this area may be appropriate.

抑制冗余消息的问题变得越来越重要,因为使用多个消息通道已成为大多数互联网用户的规则,并且用户已习惯于在一个通道中接收在另一个通道中接收的通信通知。不幸的是,基本上没有跨渠道交叉引用和链接消息的标准;这方面的标准工作可能是适当的。

Another possible engineering task is defining a standardized representation for the definition and application of recipient message processing rules. Such an effort would extend existing work on the Sieve language within the IETF to incorporate some of the concepts discussed above.

另一个可能的工程任务是定义收件人消息处理规则的定义和应用的标准化表示。这样的努力将扩展IETF中关于筛语言的现有工作,以纳入上面讨论的一些概念。

Discussion of token-based authorization focused on the concept of defining a means for establishing time-limited or usage-limited relationships for exchanging messages. The work would attempt to define the identity, generation, and use of tokens for authorization purposes. Most likely this is more of a research topic than an engineering topic.

对基于令牌的授权的讨论集中在定义一种方法的概念上,该方法用于建立用于交换消息的时间限制或使用限制关系。这项工作将试图为授权目的定义令牌的身份、生成和使用。这很可能是一个研究课题,而不是一个工程课题。

Work on recipient rules processing and token-based authentication may be related at a higher level of abstraction (we can call it "recipient authorization processing"). When combined with insights into authorization (see Sections 3.1 and 4.1), this may be an appropriate topic for further research.

收件人规则处理和基于令牌的身份验证工作可能在更高的抽象级别上相关(我们可以称之为“收件人授权处理”)。当结合对授权的深入了解(见第3.1节和第4.1节)时,这可能是进一步研究的合适主题。

4.3. Negotiation
4.3. 谈判

Discussion in the area of negotiation resulted mostly in research-oriented output. The session felt that participants in a conversation would require some sort of rendezvous mechanism during which the parameters of the conversation would be negotiated. To facilitate this, a "conversation identifier" would be needed so that participants could identify the conversation that they wished to participate in. In addition, there are at least five dimensions along which a conversation negotiation may occur:

谈判领域的讨论主要产生以研究为导向的成果。会议认为,对话的参与者需要某种会合机制,在这种机制中,对话的参数将得到协商。为了方便这一点,需要一个“会话标识符”,以便参与者能够识别他们希望参与的会话。此外,对话协商至少有五个维度:

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

o 对话参与者o对话主题o日程安排和优先级参数o对话使用的机制o参与者的能力o对话的后勤细节

Research into how to communicate these different parameters may prove useful, as may research into the relationship between the concepts of negotiation, rendezvous, and conversation.

研究如何传达这些不同的参数可能是有用的,研究协商、会合和对话等概念之间的关系也可能是有用的。

4.4. User Control
4.4. 用户控制

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

从用户控制讨论中得出的一个明确的架构主题是关于活动、对话和线程的工作。在讨论过程中,用户将消息组织成线程的能力成为关注的焦点。参与者开始将线程定义为一组半有序的消息,一个对话

a set of threads, and an activity as a collection of conversations and related resources. The discussion expanded the traditional notion of a thread as an ordered tree of messages. Conversations can collect together threads and have them be cross-media. Messages can potentially belong to more than one thread. Threads themselves might have subthreads. All of these topics require an architectural overview to be brought into focus.

一组线程和一个活动,作为对话和相关资源的集合。讨论扩展了线程作为有序消息树的传统概念。对话可以将线程收集在一起,并使其跨媒体。消息可能属于多个线程。线程本身可能有子线程。所有这些主题都需要关注体系结构概述。

There is also engineering work that is already at a sufficient level of maturity to be undertaken on threads. Though there is certainly some simple threading work being done now with messaging, it is pretty much useful only for a unidirectional tree of messages in a single context. Engineering work needs to be done on identifiers that could used in threads that cross media. Additionally, there is likely work to be done for messages that may not be strictly ordered in a thread.

还有一些工程工作已经达到了足够的成熟度,可以在线程上进行。尽管现在消息传递确实有一些简单的线程工作正在进行,但它只对单个上下文中的单向消息树非常有用。需要对可用于跨媒体线程的标识符进行工程设计。此外,对于线程中可能没有严格排序的消息,可能需要做一些工作。

The topics of "control panels" and automated introductions were deemed appropriate for further research.

“控制面板”和自动介绍的主题被认为适合进一步研究。

4.5. Message Transport
4.5. 消息传输

A central research topic that came out of the transport session was that of multiple transports. It was felt that much research could be done on the idea of transporting pieces of messages over separate transport media in order to get the message to its final destination. Especially in some high-latency, low-bandwidth environments, the ability to run parallel transports with different parts of messages could be extremely advantageous. The hard work in this area is re-associating all of the pieces in a timely manner, and identifying the single destination of the message when addressing will involve multiple media.

传输会议的一个中心研究主题是多个传输。有人认为,可以对通过单独的传输媒体传输消息片段的想法进行大量研究,以便将消息传送到其最终目的地。特别是在一些高延迟、低带宽的环境中,使用消息的不同部分运行并行传输的能力可能非常有利。这一领域的艰巨工作是及时地重新关联所有信息,并在寻址涉及多种媒体时识别消息的单一目的地。

A common theme that arose in several of the discussions (including user control and message unification), but that figured prominently in the transport discussion, was a need for some sort of identifier. In the transport case, identifiers are necessary on two levels. Identifiers are needed to mark the endpoints in message transport. As described in the discussion, there are many cases where a message could reasonably be delivered to different entities that might all correspond to a single person. Some sort of identifier to indicate the target person of the message, as well as identifiers for the different endpoints, are all required in order to get any traction in this area. In addition, identifiers are also required for the messages being transported, as well as their component parts. Certainly, the idea of transporting different parts of a message over different mechanisms requires the identification of the containing message so that re-assembly can occur at the receiving end. However,

在一些讨论(包括用户控制和消息统一)中出现的一个共同主题是需要某种标识符,但在传输讨论中占据了突出位置。在传输情况下,标识符在两个级别上是必需的。需要标识符来标记消息传输中的端点。如讨论中所述,在许多情况下,消息可以合理地传递给可能全部对应于一个人的不同实体。为了在这一领域获得吸引力,需要某种标识符来指示消息的目标人,以及不同端点的标识符。此外,所传输的消息及其组件也需要标识符。当然,通过不同机制传输消息的不同部分的想法需要识别包含的消息,以便可以在接收端进行重新组装。然而

identifying the entire package is also necessary for those cases where duplicate copies of a message might be sent using two different mechanisms: The receiving end needs to find out that it has already received a copy of the message through one mechanism and identify that another copy of the message is simply a duplicate.

对于可能使用两种不同机制发送消息的副本的情况,也需要识别整个包:接收端需要发现它已经通过一种机制接收到消息的副本,并识别消息的另一个副本仅仅是副本。

Workshop participants felt that, at the very least, a standard identifier syntax was a reasonable engineering work item that could be tackled. Though there exist some identifier mechanisms in current messaging protocols, none were designed to be used reliably across different transport environments or in multiple contexts. There is already a reasonable amount of engineering work done in the area of uniform resource identifiers (URI) that participants felt could be leveraged. Syntax would be required for identifiers of messages and their components as well as for identifiers of endpoint entities.

研讨会参与者认为,至少标准标识符语法是可以解决的合理工程工作项。尽管当前的消息传递协议中存在一些标识符机制,但没有一种机制是为跨不同的传输环境或在多个上下文中可靠地使用而设计的。在统一资源标识符(URI)领域已经完成了相当数量的工程工作,参与者认为可以利用这些工作。消息及其组件的标识符以及端点实体的标识符都需要语法。

Work on the general problem of identifier use might have some tractable engineering aspects, especially in the area of message part identifiers, but workshop participants felt that more of the work was ripe for research. The ability to identify endpoints as belonging to a single recipient, and to be able to distribute identifiers of those endpoints with information about delivery preferences, is certainly an area where research could be fruitful. Additionally, it would be worthwhile to explore the collection of identified message components transported through different media, while delivering to the correct end-recipient with duplicate removal and re-assembly.

关于标识符使用的一般问题的工作可能有一些易于处理的工程方面,特别是在消息部分标识符领域,但研讨会参与者认为,更多的工作已经成熟,可以进行研究。能够将端点识别为属于单个接收者,并能够分发端点标识符和有关交付偏好的信息,这无疑是一个研究可能取得成果的领域。此外,有必要探索通过不同媒体传输的已识别消息组件的集合,同时通过删除和重新组装副本将其传递给正确的最终收件人。

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

包安全性被视为一个研究领域。如第3.5节所述,消息的不同组件可能会通过不同的媒体传输,并且需要在接收方端重新组装,这打破了当前所做的某些端到端安全假设。与会者认为,一个值得研究的目标是研究可用于此类多组件消息的安全机制,而不牺牲理想的安全特性。

Finally, a more architectural topic was that of restartability. Most current message transports, in the face of links with reliability problems, will cancel and restart the transport of a message from the beginning. Though some mechanisms do exist for restart mid-session, they are not widely implemented, and they certainly can rarely be used across protocol boundaries. Some architectural guidance on restart mechanisms would be a useful addition.

最后,一个更具体系结构的主题是可重启性。大多数当前的消息传输,在面临可靠性问题的链接时,会从一开始就取消并重新启动消息传输。虽然确实存在一些用于在会话中间重新启动的机制,但它们并没有得到广泛的实现,而且它们肯定很少能够跨协议边界使用。关于重启机制的一些体系结构指南将是一个有用的补充。

4.6. Identity Hints and Key Distribution
4.6. 身份提示和密钥分配

It would be helpful to develop Internet-wide services to publish and retrieve keying material. One possible solution is to build such a service into Secure DNS, perhaps as an engineering item in an existing working group. However, care is needed since that would significantly increase the size and scope of DNS. A more research-oriented approach would be to investigate the feasibility of building Internet-wide key distribution services outside of DNS. In doing so, it is important to keep in mind that the problem of distribution is separate from the problem of enrollment, and that name subordination (control over what entities are allowed to create sub-domains) remains necessary.

这将有助于发展互联网范围内的服务,以发布和检索键控材料。一种可能的解决方案是将此类服务构建到安全DNS中,可能作为现有工作组中的工程项目。但是,需要小心,因为这将显著增加DNS的大小和范围。一种更注重研究的方法是调查在DNS之外建立互联网范围的密钥分发服务的可行性。在这样做时,重要的是要记住,分发问题与注册问题是分开的,名称从属(控制允许哪些实体创建子域)仍然是必要的。

Research may be needed to define the different audiences for message security. For example, users of consumer-oriented messaging services on the open Internet may not generally be willing or able to install new trusted roots in messaging client software, which may hamper the use of security technologies between businesses and customers. By contrast, within a single organization it may be possible to deploy new trusted roots more widely, since (theoretically) all of the organization's computing infrastructure is under the centralized control.

可能需要进行研究,以确定消息安全性的不同受众。例如,开放互联网上面向消费者的消息传递服务的用户通常不愿意或无法在消息传递客户端软件中安装新的可信根,这可能会妨碍企业和客户之间使用安全技术。相比之下,在单个组织内可能更广泛地部署新的可信根,因为(理论上)组织的所有计算基础设施都在集中控制之下。

In defining security frameworks for messaging, it would be helpful to specify more clearly the similarities and differences among various messaging technologies with regard to trust models and messaging metaphors (e.g., stand-alone messages in email, discrete conversations in telephony, messaging sessions in instant messaging). The implications of these trust models and messaging metaphors for communications security have not been widely explored.

在定义消息传递的安全框架时,最好更清楚地说明各种消息传递技术在信任模型和消息传递隐喻(例如,电子邮件中的独立消息、电话中的离散对话、即时消息传递中的消息传递会话)方面的异同。这些信任模型和消息传递隐喻对通信安全的影响尚未得到广泛探讨。

5. Security Considerations
5. 安全考虑

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

本文件的几节讨论了安全性,特别是第3.5节、第3.6节、第4.5节和第4.6节。

6. Acknowledgements
6. 致谢

The IAB would like to thank QUALCOMM Incorporated for their sponsorship of the meeting rooms and refreshments.

IAB感谢高通公司对会议室和茶点的赞助。

The editors would like to thank all of the workshop participants. Eric Allman, Ted Hardie, and Cullen Jennings took helpful notes, which eased the task of writing this document.

编辑们要感谢所有的研讨会参与者。Eric Allman、Ted Hardie和Cullen Jennings做了有用的笔记,这简化了编写本文档的任务。

Appendix A. Participants
附录A.与会者

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

Eric Allman Nathaniel Borenstein Ben Campbell Dave Crocker Leslie Daigle Mark Day Mark Crispin Steve Dorner Lisa Dusseault Kevin Fall Ned Freed Randy Gellens Larry Greenfield Ted Hardie Joe Hildebrand Paul Hoffman Steve Hole Scott Hollenbeck Russ Housley Cullen Jennings Hisham Khartabil John Klesin John Levine Rohan Mahy Alexey Melnikov Jon彼得森·布莱克·拉姆斯代尔·皮特·雷斯尼克·乔纳森·罗森博格·彼得·圣安德烈·格雷格·沃德鲁伊

Appendix B. Pre-Workshop Papers
附录B.研讨会前文件

The topic papers circulated before the workshop were as follows:

讲习班前分发的专题文件如下:

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

日历集成(Nathaniel Borenstein)频道安全(Russ Housley)协作创作(Lisa Dusseault)基于同意的消息(John Klesin)内容安全(Blake Ramsdell)事件通知(Joe Hildebrand)扩展消息服务(Dave Crocker)组消息(Peter Saint Andre)身份和声誉(John Levine)消息传递中的即时消息和存在问题(Ben Campbell)大型电子邮件环境(Eric Allman)邮件/新闻/博客聚合(Larry Greenfield)消息传递和垃圾邮件(Cullen Jennings)消息传递隐喻(Ted Hardie)MUA/MDA、MUA/MSA和MUA/消息存储交互(Mark Crispin)基于同意的消息传递的存在(Jon Peterson)丰富的有效负载(Steve Hole)面向会话的消息(Rohan Mahy)移动设备的垃圾邮件预期(Greg Vaudreuil)难以到达的网络中的通信(Kevin Fall)IM的存储和转发需求(Hisham Khartabil)联合(Paul Hoffman)传输安全(Alexey Melnikov)VoIP对等和消息(Jonathan Rosenberg)Webmail,彩信和手机电子邮件(Randy Gellens)

Authors' Addresses

作者地址

Peter W. Resnick (Editor) Internet Architecture Board QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 US

Peter W.Resnick(编辑)互联网体系结构委员会高通公司5775 Morehouse Drive San Diego,CA 92121-1714美国

   Phone: +1 858 651 4478
   EMail: presnick@qualcomm.com
   URI:   http://www.qualcomm.com/~presnick/
        
   Phone: +1 858 651 4478
   EMail: presnick@qualcomm.com
   URI:   http://www.qualcomm.com/~presnick/
        

Peter Saint-Andre (Editor) Jabber Software Foundation P.O. Box 1641 Denver, CO 80201-1641 US

Peter Saint Andre(编辑)JabBER软件基金会邮政信箱1641丹佛,美国80201-1641

   Phone: +1 303 308 3282
   EMail: stpeter@jabber.org
   URI:   http://www.jabber.org/people/stpeter.shtml
        
   Phone: +1 303 308 3282
   EMail: stpeter@jabber.org
   URI:   http://www.jabber.org/people/stpeter.shtml
        

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (2006).

版权所有(C)互联网协会(2006年)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件及其包含的信息是按“原样”提供的,贡献者、他/她所代表或赞助的组织(如有)、互联网协会和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Intellectual Property

知识产权

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.

Acknowledgement

确认

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

RFC编辑器功能的资金由IETF行政支持活动(IASA)提供。