Network Working Group P. Resnick, Ed.
Request for Comments: 4417 IAB
Category: Informational P. Saint-Andre, Ed.
JSF
February 2006
Report of the 2004 IAB Messaging Workshop
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（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）で開催されたワークショップの結果を報告します。ワークショップでは、バーリンゲーム、CA、USAで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
Current email infrastructure is a mixture of facilities to accomplish its task of end-to-end communications through a relay mesh. That mixture has come about as requirements have changed over the years. Discussions recur over the years, often including complaints that some desired features of email (such as internationalization, efficient encoding of structured data, trusted communication) are ill-served by the current infrastructure, or that some of the current infrastructure seems to be adversely affected by current problems on the Internet (most recently including problems such as spam, viruses, and lack of security infrastructure). For many years, the daunting task of revamping email infrastructure has been considered, with justifiably little enthusiasm for taking on such a task. However, there has been some recent informal discussion on the kinds of things that would be desirable in a "next generation" email.
現在の電子メールインフラストラクチャは、リレーメッシュを通してエンドツーエンドのコミュニケーションのそのタスクを達成するための施設の混合物です。要件は、長年にわたって変更されているように、その混合物を約来ました。議論は、多くの場合（例えば国際化、構造化データの効率的な符号化、信頼できる通信など）電子メールのいくつかの望ましい特徴は、現在のインフラストラクチャによって病気-提供されている苦情を含め、年間で再発、またはことは、現在のインフラストラクチャの一部が悪影響を受けているように見えますインターネット上の現在の問題で（最近、このようなスパム、ウイルス、およびセキュリティインフラの不足などの問題を含みます）。長年にわたり、電子メールインフラを刷新する困難な作業は、このようなタスクを取るための正当少し熱意をもって、考えられてきました。しかし、「次世代」メールに望ましいであろう物事の種類のいくつかの最近の非公式の議論がありました。
At the same time, other messaging infrastructures (including those associated with "instant messaging" and "web logging") are currently being deployed that appear to address many of the above desired features and outstanding problems, while adding many features not currently considered part of traditional email (like prior-consent-based acceptance of messages). However, each of these technologies (at least in their current deployment) seem to lack some of the features commonly associated with email (such as selective and partial message delivery, queued multi-hop relaying, offline message management, and efficient non-textual content delivery).
多くの機能を追加すると、現在の一部とは見なされないが、同時に、（「インスタントメッセージング」と「ウェブのログ」に関連したものを含む）他のメッセージングインフラストラクチャは、現在、上記の望ましい特徴と優れた問題の多くに対処するために表示される展開されています（メッセージの事前の同意・ベースの受け入れなど）の伝統的なメール。しかし、（少なくとも、彼らの現在の展開で）これらの技術のそれぞれは、一般的に（このような選択や部分的メッセージ配信などの電子メールに関連した機能の一部が欠けているように見える、マルチホップ中継、オフラインメッセージ管理、および効率的な非テキストコンテンツをキューに入れられました配信）。
The Internet Architecture Board (IAB) believed that the time was ripe to examine the current state of messaging technologies on the Internet and to see if there are areas of work that can be taken on to advance these technologies. Therefore, the IAB held a workshop on Internet messaging, taking some of the above issues as input, in order to formulate some direction for future study of the area of messaging.
インターネットアーキテクチャ委員会（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 types of messaging under consideration. Among the themes identified were the following:
メッセージングの話題は広く、メッセージングとしてカウントするものの境界は常に明確に定義されていません。むしろ、メッセージの性質の哲学的議論に自分自身を制限するよりも、ワークショップの参加者は、「私たちはそれを見たとき、我々はそれを知っている」の態度を採用し、その主な例は、電子メールやインスタントメッセージング（IMなどのメッセージのように十分に確立型として使用します）、また、音声メッセージングおよびイベント通知などのメッセージングのより多くの「周辺」の種類を議論しながら。 （例えば、企業のワークフローエンジンと、いくつかの「Webサービス」アーキテクチャで使用されるものとして保証された配信とトランザクションの整合性を持つメッセージ・キューイング・システムは、スコープの外に意図的に運用場合はありませんでした。）参加者は、すべてのタイプに適用される共通のテーマを発見するために働いていました検討中のメッセージング。特定されたテーマの中で次のようでした：
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、「スパム」として口語的に知られている）や、インスタントメッセージングなどの他のメッセージング環境における類似の通信（「スピム」）及びインターネット電話のトピックは、（」上記リストからされ行方不明つば "）。このトピックは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.
議論の流れの概要だけでなく、ワークショップの提案勧告を提供するように、この文書は、構成されています。第4節では、推奨の研究テーマやワークショップに起因プロトコル定義の取り組みの概要を提供しながら、第3節では、さまざまなトピックやテーマに関するワークショップ中に発生した議論をまとめたもの。第5節では、ワークショップで議論のトピックのセキュリティ関連の側面に関するいくつかの視点を提供します。付録Bは、ワークショップでの議論の背景としてワークショップ参加者から提出された事前ワークショップトピックの論文を示しています。
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.
次のセクションにまとめたように、ワークショップ自体の間、議論は、いくつかのトピックやテーマを中心に。当然、それは深さでこれらのトピックを治療するための2日間のワークショップでは不可能でした。しかし、大まかなコンセンサスは、潜在的な研究プログラムと提起された問題を解決する可能性があるプロトコルの標準化の取り組みの詳細にいない場合は常に、これらのトピックの重要性に達しました。これらの要約は、追加の研究者によって仕事を刺激することが期待されます。
The in-workshop discussions quite naturally fell into three kinds of "tracks": (1) possible engineering tasks to recommend to the IESG and other standardization groups, (2) "blue sky" research topics to recommend to the IRTF and other researchers, and (3) general architectural or "framework" issues for consideration by both engineers and researchers alike. After a full-group discussion each morning to identify possible topics for more in-depth investigation, participants self-selected for involvement in one of three "break-out" sessions. Toward the end of each day, the full groups reconvened, gathered reports from the break-out discussion leaders, and attempted to come to consensus regarding lessons learned and recommendations for further research. The results of the two-day workshop therefore consist of discussion issues and research/ engineering recommendations related to the six topics described in this report.
で、ワークショップの議論は、ごく自然に「トラック」の3種類に落ちた：（1）可能なエンジニアリング・タスクはIESGや他の標準化団体に推薦すること、（2）「青空」の研究課題は、IRTFおよび他の研究者にお勧めします（3）同様に、両方の技術者・研究者による検討のための一般的な建築や「フレームワーク」の問題を。フルグループディスカッションの後、毎朝のより詳細な調査のための可能なトピックを識別するために、参加者の自己選択した3つの「ブレイクアウト」セッションの1つの関与のために。一日の終わりに向けて、完全なグループは、再招集ブレークアウトディスカッション・リーダーからの報告を集め、そして学んだ教訓と今後の研究のための勧告に関するコンセンサスに来ることを試みました。 2日間のワークショップの結果は、したがって、この報告書で説明する6つのトピックに関連した議論の問題と研究/エンジニアリング勧告で構成されています。
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).
彼らは現実の生活からよく知られているパターンをエミュレートするため、評判システムは、今後の研究の特に価値があるかもしれません。 （また、信頼できるサードパーティが提供する積極的な評価として、メッセージ履歴及び（2）の認定に基づいて、1つまたは複数の受信者が作成した送信者の反応性の評価として、（1）の評判を区別する価値がある。）の評判をベースとするかもしれませんネットワーク上の受信者が提供する個人の「スコア」を合計するに。 （より望ましいかもしれない集中システムとは対照的に、配布されるように当然のことながら、より重要な評判になり、より多くの悪役は、任意の評判システムを妨害しようとする場合があります。）送信者の評判に基づいて、任意の受信者によって取られた行動だろう必ずしも簡単な許可/拒否の決定に制限されます。より微妙なアクションは別々の受信トレイに低いレピュテーションスコアを持つ個人からのメッセージを置いたり（電子メールで送信するIMから、例えば、）他のメディアにそれらをリダイレクトなどがあります。
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、ポケットベル、および：多くの人々が複数のメッセージング・チャネルのフォームを使用することを人生の事実です。送信者またはイニシエータが任意の時点で受信者に連絡するための最良の方法を知っているため残念ながら、これはそれを困難にすることができます。一のモデルは、例えば、最初の電子メールメッセージを送信した後、必要に応じてポケットベルまたは電話にエスカレートすることにより、推測するイニシエータのためのものです。これは、受信者への冗長メッセージの送達をもたらすことができます。第2のモデルは、おそらく彼または彼女の存在の一つの側面として、定期的に更新の連絡先情報を公開するための受信者です。これは、接触媒体が最も適切である事前に決定するためにイニシエータを有効かもしれません。第3のモデルは、配信ルールのセットに基づいて受信者にメッセージや通知のインテリジェントなルーティングを可能にし、「単一化」サービス（例えば、「私は私からのボイスメールメッセージを受信した場合、ページャを経由して私に通知のいくつかの種類を使用する受信者であります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受信者に定義された配信ルールのためのフレームワークまたはプロトコルを定義する価値があるかもしれ。現在、ルーティングの決定は、メッセージングチャネルを選択することにより、送信者が主に行われる傾向にあり、将来的には、受信者は、このような決定に大きな役割を果たしている可能性があります。接触出版物の背後にあるロジックは、最善の（別の媒体に通信することにより得られる1つの媒体のための連絡先が存在するかどうかの側面または拡張であるかどうか、例えば、探求する必要があります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.
調査のための別の領域は、受信者の能力のことです。送信者が能力情報を持っていない場合は、最も一般的な結果は、真剣に、システム全体の性能をunderutilizesコミュニケーションの最小公分母にダウングレードされます。前の標準化の努力は（例えば、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トークンベースの認証は、送信者と1時間または限られた時間の関係を定義するための受信者を可能にします。発行者は、受信者と通信するために限られた時間の権利を付与トークンを所有しています。これは、よりダイナミックな認証スキームです。 Oルール・ベースの許可は、基準の広いセットに基づいて、関係の生存能力のアルゴリズム評価を含みます。これは、リストやトークン、プラス、メッセージの特性評価および発行者の特性などの追加の評価基準の両方許可を組み込むことができ、より一般的な認証スキームです。
In the area of negotiation, the workshop participants focused mainly on the process by which a set of participants agree on the media and parameters by which they will communicate. (One example of the end result of such a "rendezvous" negotiation is a group of colleagues who agree to hold a voice conference, with a textual "groupchat" as a secondary communications channel.) In order to enable cross-media negotiation, it may be necessary to establish a bridge between various identities. For example, the negotiation may occur via email, but the communication may occur via phone, and in order to authorize participants the conference software needs to know their phone numbers, not their email addresses. Furthermore, the parameters to be negotiated may include a wide variety of aspects, including:
交渉の分野では、ワークショップの参加者は主に、参加者の集合は、彼らが通信することによって、メディアやパラメータに同意するプロセスに焦点を当てました。 （例えば、「ランデブー」交渉の最終結果の一例は、二次通信チャネルとしてテキスト「グループチャット」との音声会議を開催することに同意同僚の基である。）は、クロスメディアネゴシエーションを可能にするために、それ様々なアイデンティティ間のブリッジを確立する必要があるかもしれません。例えば、交渉は電子メールを介して発生することがありますが、通信は、電話を経由して、会議ソフトウェアは、自分の電話番号ではなく、自分のメールアドレスを知っている必要があり、参加を承認するために発生する可能性があります。さらに、ネゴシエートされるパラメータは、以下を含む、態様の広範囲を含んでもよいです。
o Prerequisites for the communication (e.g., distribution of a "backgrounder" document). o Who will initiate the communication. o Who will participate in the communication. o The primary "venue" (e.g., a telephone number that all participants will call). o One or more secondary venues (e.g., a chatroom address). o Backup plans if the primary or secondary venue is not available. o The topic or topics for the discussion. o The identities of administrators or moderators. o Whether or not the discussion will be logged or recorded. o Scheduling of the event, including recurrence (e.g., different instances may have different venues or other details).
通信のためのO前提条件（例えば、「背景説明」文書の配布）。 oだれが通信を開始します。 oだれが通信に参加します。プライマリ「場所」（例えば、すべての参加者が呼び出す電話番号）O。 1つの以上の二会場（例えば、チャットルームアドレス）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.
通信が既に開始された後実際に、いくつかの状況ではそれも交渉するか、パラメータを再交渉するのが望ましいかもしれない（例えば、新しい参加者を招待したりロギングなどの重要なパラメータを変更します）。ワークショップの参加者は、パラメータのフルセットの詳細な交渉はコミュニケーションの多くのクラスに不要である可能性が高い、マルチパーティ通信の交渉のための一般的なフレームワークやプロトコルの一部は、幅広い用途に有用であることが分かるかもしれないことを認識しつつ、コンテキスト。
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 - ワークグループの参加者は、メッセージング、メディア間での通信を管理する際に使用するためのクロスサービス制御プロトコルの必要性があるかもしれないかどうか、未解決の問題として残さ。
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レベルで、適切である可能性がある）保証されなくてもよいです。同じエンドポイントまたはエンティティは、異なる時間に異なるトランスポート機構を介して利用可能な、または同時に複数のトランスポートを介しても利用可能であり得ることも可能です。複数のパスが存在する場合、適切なトランスポート機構を選択するプロセスは、（可能なヒューリスティックが予測ルーティング、日和見ルーティング、およびスケジュールされたルーティングを含むかもしれない）はまだインターネットプロトコル開発で対処されていない問題に対処導入します。信頼できないリンクについては、正常におそらく異なる輸送機構に切り替えることによって、任意の所与の障害の後にリンクを再起動することができることに価値があるかもしれません。
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）であるということです。それは別の媒体で受信者によって引っ張られている前に、コンテンツを1つの媒体に受取人に押されたときに、コンテンツの参照が同期して取得することが可能です。
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.
メッセージ断片は、異なるメディア上で転送することができた場合は、おそらく別々の時間に到着するか、別の経路を通って、パッケージのセキュリティの問題が深刻なものとなります。伝統的に、メッセージは、ヘッドエンドでパッケージ全体を暗号化して、受信側でそれを解読することによって固定されています。我々はトランスポートは、部品のメディアタイプに基づいてメッセージを断片化することを可能にしたい場合は、そのアプローチは実行可能ではありません。
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.
広く、メッセージの暗号化と会話パートナーの認証の両方が強く望まれていることが認識されているが、ワークショップ参加者のコンセンサスは一部で、現在のビジネスと実装モデルは、既存のソリューションの展開を阻止するということでした。例えば、それがクライアントにインストールされ、新しいルート証明書を取得することは困難です、証明書がある（またはであることを認識されている）を取得することは困難または高価な、ワンクリック、またはゼロクリックのサービスの登録は価値があるが、一見到達不能の目標である、と一度1は、公開鍵/秘密鍵のペアを作成し、公開鍵を認定しました、その証明書を配布したり、他の人の証明書を発見する方法を明らかに満ちません。
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).
広範なメッセージの暗号化は、より実現可能にすることが一つの要因は、電子メール、インスタントメッセージング、およびインターネット電話は非常に似信頼モデルを持っているということです。しかし、通信の定義は、これらの技術の間でかなり異なります。メールに「メッセージはものです」、そして、それはそれ自体で個別のオブジェクトです。電話での焦点は、会話やセッションではなく、個別のメッセージのリアルタイムの流れにあります。そして、IMは、それが（メッセージングセッションとして見ることができる）テキストメッセージを迅速に、前後交換を中心としているので仲介位置を保持するようです。
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.
サプライチェーン管理などのミッションクリティカルなビジネス・ツー・ビジネスアプリケーションに、企業と顧客との間の通信を通じて、公共のチャットルームやソーシャル・ネットワーキング・アプリケーションでカジュアルな会話からすべて：もう1つの複雑な要因は、メッセージングテクノロジが使用される文脈の広い範囲であります。別の観客は、このような信頼できる第三者と信頼のウェブのようなサービスのための様々な需要が生じ、メッセージングセキュリティと本人確認に関して異なるニーズを持っていることがあります。
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.
通信技術の文脈では、アイデンティティのヒント - 知識の共有、会話スタイル、ボイストーン、メッセージングパターン、語彙、など - は、多くの場合、あるキーのフィンガープリント、デジタル署名、およびその他の電子成果物、より多くの有用な情報を提供することができますほとんどのエンドユーザーの経験から離れました。現在まで、そのようなアイデンティティのヒントのチェックは直感的ではなく、プログラムです。
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.
承認の議論から出てきた1つの明確に希望のエンジニアリングプロジェクトは、分散評判のサービスでした。これは、いくつかの点で、メッセージの受信者がメッセージの送信者の評判をチェックできるようにしたいでしょう、任意の他のメッセージの承認に関して行われるために必要なことが合意されました。これは、受信者が事前の経験を持っていない人と送信者の場合に特に有用です。すなわち、「見知らぬ人を紹介して」取得する方法として評判のサービスを使用して。分散化するには、この評判のサービスの必要性が明らかに存在しました。単一の集中評判サービスは、いくつかの状況では便利かも知れません、それはインターネット全体のサービスに拡張できません。
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.
他の潜在的な研究領域は、許可の決定に受信者の回答にありました。許可の決定を行う際に、受信者は2つのことをしなければならない。まず、明らかに受信者がそれを提供するか、それを否定するか何らかの方法でメッセージを送出する必要があります。しかし、その決定はまた、レシピエントが作ることが認可決定の次のセットに戻す副作用を持つことになります。いずれかの「賞賛」や、メッセージの送信者を「censuring」、バック評判システムに供給することができる決定。
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内のSieve言語で既存の作業を拡張することになります。
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を参照）の認可についての洞察と組み合わせると、これはさらなる研究のための適切なトピックかもしれません。
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:
交渉の分野での議論は、研究志向の出力にはほとんどなりました。セッションは、会話の中で、参加者が会話のパラメータが交渉されるであろう時のランデブーメカニズムのいくつかの並べ替えが必要になると感じていました。参加者は、彼らが参加することを望んだ会話を識別することができるようにこれを容易にするために、「会話識別子は、」必要とされるであろうまた、会話交渉が発生する可能性があり、それに沿って少なくとも5つのディメンションがあります。：
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.
交渉、ランデブー、および会話の概念間の関係に研究があり、これらの異なるパラメータを通信する方法の研究は、有用であろう。
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.
「コントロールパネル」と自動化された紹介のトピックは、今後の研究のために適切であると考えられました。
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.
（ユーザーコントロールとメッセージ一元化を含む）の議論のいくつかで起こったが、それは輸送ディスカッションに目立つ考え出し共通のテーマは、識別子のいくつかの並べ替えのために必要でした。輸送場合、識別子は、2つのレベルで必要です。識別子は、メッセージ・トランスポート内のエンドポイントをマークするために必要とされます。議論で述べたように、メッセージが合理的にすべてが一人に対応している場合があり、異なるエンティティに配信することができ、多くの場合があります。いくつかのメッセージの対象者を示すために、識別子の一種、ならびに異なるエンドポイントの識別子は、すべてこの領域で任意のトラクションを得るために必要とされています。また、識別子はまた、搬送されるメッセージ、ならびにそれらの部品のために必要とされます。再アセンブリは、受信側で発生できるように確かに、異なるメカニズムを介したメッセージの異なる部分を輸送するアイデアが含まれているメッセージの識別を必要とします。しかし、全体のパッケージを特定するメッセージの複製コピーは、2つの異なるメカニズムを使用して送信されるかもしれないような場合にも必要である：受信端は、既に一つのメカニズムを介してメッセージのコピーを受信したことを知ると他のことを特定する必要がありますメッセージのコピーは、単に重複しています。
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.
最後に、より多くの建築のトピックは、再始動のことでした。現在のほとんどのメッセージは、信頼性の問題とのリンクに直面して、輸送初めからのメッセージの転送をキャンセルして再起動します。いくつかのメカニズムは、再起動半ばセッションのために存在しますが、これらは広く実装されていない、と彼らは確かにめったにプロトコルの境界を越えて使用することはできません。再起動メカニズムに関するいくつかのアーキテクチャガイダンスは有用な付加だろう。
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.
電子メールでのメッセージングのためのセキュリティフレームワークを定義するには、それがモデルとメッセージング比喩を信頼することに関して明確に、より多様なメッセージングテクノロジの間の類似点と相違点を指定するために有用であろう（例えば、スタンドアローンのメッセージ、電話での個別の会話、インスタントにおけるメッセージングセッションメッセージング）。通信セキュリティのためにこれらの信頼モデルとメッセージング比喩の意味は広く検討されていません。
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を議論しています。
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.
編集者はワークショップ参加者のすべてに感謝したいと思います。エリック・オールマン、テッドハーディー、およびカレンジェニングスは、この文書を作成する作業を緩和役立つノートを取りました。
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
エリック・オールマンナサニエル・ボレンスタインベン・キャンベルデイブ・クロッカーレスリーDaigle氏マーク・デイマーク・クリスピンスティーブ・ドルナーリサDusseaultケビン秋ネッドフリードランディGellensラリー・グリーンフィールドテッドハーディージョー・ヒルデブラント、ポール・ホフマンスティーブホールスコットホレンベックラスHousleyカレン・ジェニングスヒシャムKhartabilジョン・クレンシンジョン・レヴァインロハンマーイアレクセイ・メルニコフジョン・ピーターソンブレイクRamsdellピートレズニックジョナサン・ローゼンバーグピーターサンタンドレグレッグボードルイ
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)
カレンダーの統合（ナサニエル・ボレンスタイン）チャネルセキュリティ（ラスHousley）共同オーサリング（リサDusseault）同意ベースのメッセージング（ジョン・クレンシン）コンテンツセキュリティ（ブレイクRamsdell）イベント通知（ジョー・ヒルデブラント）拡張メッセージング・サービス（デイブ・クロッカー）グループメッセージング（ピーターサン-Andre）アイデンティティおよびメッセージング（ベン・キャンベル）大型電子メール環境（エリック・オールマン）メール/ニュース/ブログコンバージェンス（ラリー・グリーンフィールド）メッセージングとスパム（カレン・ジェニングス）メッセージングメタファー（テッド・ハーディーの評判（ジョン・レヴィン）インスタントメッセージングとプレゼンスの問題モバイルデバイスのための同意ベースのメッセージング（ジョン・ピーターソン）リッチペイロード（スティーブホール）セッション指向メッセージング（ロハンマーイ）スパムの期待のために）MUA / MDA、MUA / MSA、およびMUA /メッセージストアの相互作用（マーク・クリスピン）プレゼンス（ストアアンドフォワードは、IM（ヒシャムKhartabil）シンジケーション（ポール・ホフマン）交通安全（アレクセイ・メルニコフ）のVoIPピアリングとMesのためにニーズ難リーチ・ネットワーク（ケビン・秋）でグレッグボードルイ）通信saging（ジョナサン・ローゼンバーグ）Webメール、MMS、モバイルメール（ランディGellens）
Authors' Addresses
著者のアドレス
Peter W. Resnick (Editor) Internet Architecture Board QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 US
ピーター・W.レズニック（編集）インターネットアーキテクチャ委員会QUALCOMM Incorporatedの5775モアハウスドライブサンディエゴ、CA 92121から1714米
Phone: +1 858 651 4478 EMail: presnick@qualcomm.com URI: http://www.qualcomm.com/~presnick/
電話：+1 858 651 4478 Eメール：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
ピーター・サン・アンドレ（編集）Jabberのソフトウェア財団私書箱ボックス1641デンバー、CO 80201から1641米
Phone: +1 303 308 3282 EMail: stpeter@jabber.org URI: http://www.jabber.org/people/stpeter.shtml
電話：+1 303 308 3282 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。