[要約] RFC 4417は、2004年のIABメッセージングワークショップの報告書であり、メッセージングに関する課題と解決策についての議論をまとめています。目的は、メッセージングの技術とプロトコルの進歩を促進し、インターネットメッセージングの品質と信頼性を向上させることです。
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).
Copyright（c）The Internet Society（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
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 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メッセージ組織（例：会話やスレッド）
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、「SPAM」として知られている）のトピックと、インスタントメッセージング（「SPIM」）やインターネットテレフォニー（」などの他のメッセージング環境での類似の通信（「スピット "）。このトピックは、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には、ワークショップの参加者がワークショップディスカッションの背景として提出したワークショップ前のトピックペーパーをリストしています。
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つの「ブレイクアウト」セッションのいずれかに関与するために自己選択しました。毎日の終わりに向かって、完全なグループは再会って、ブレイクアウトディスカッションリーダーからの報告を収集し、学んだ教訓とさらなる研究のための推奨事項に関するコンセンサスに来ようとしました。したがって、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).
送信者がメッセージを送信することと、意図した受信者がそれを受け入れることは1つです。受信者がメッセージを受け入れるように導く要因には、送信者のアイデンティティ、送信者との以前の経験、パーティー間の継続的な会話の存在、メッセージに関するメタデータ（例えば、その主題またはサイズ）、メッセージが含まれます。媒体（たとえば、電子メール対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).
従来、送信者認証は、受信者定義のブロックと許可リスト（「ブラックリスト」と「ホワイトリスト」とも呼ばれます）によって処理されてきました。ブロックリストの価値は限られています。これは、新しいメッセージングIDの獲得や作成の容易さ（たとえば、メールアドレスや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）メッセージ履歴に基づいて1人以上の受信者によって作成された送信者の反応的評価と（2）信頼できる第三者によって提供される積極的な評価としての認定としての評判を区別することも価値があるかもしれません。）評判は基づいているかもしれません。ネットワーク上の受信者が提供する個人の「スコア」を合計すると。（当然のことながら、より重要な評判は、より悪い俳優が特定の評判システムを妨害しようとする可能性があるため、集中システムとは対照的に分散されることが望ましい場合があります。）必ずしも単純な許可/拒否決定に限定されるとは限りません。より微妙なアクションには、評判スコアが低い個人からのメッセージを個別の受信トレイに配置したり、他のメディアにリダイレクトしたりすることが含まれます（たとえば、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、ポケットベルなどの複数の形式のメッセージングチャネルを使用しているのは、人生の事実です。残念ながら、これにより、送信者またはイニシエーターがいつでも受信者に連絡する最良の方法を知ることが難しくなります。1つのモデルは、イニシエーターが最初に電子メールメッセージを送信し、次に必要に応じてポケットベルまたは電話にエスカレートすることで推測することです。これにより、受信者に冗長なメッセージが配信される可能性があります。2番目のモデルは、受信者が定期的に更新された連絡先情報を公開することです。おそらく、彼または彼女の存在の1つの側面としてです。これにより、イニシエーターは、どの接触媒体が最も適切であるかを事前に決定できるようになる場合があります。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 受信者定義の配信ルールのフレームワークまたはプロトコルを定義する価値があるかもしれません。現在、ルーティングの決定は、メッセージングチャネルの選択を通じて送信者によって主に行われる傾向がありますが、将来、受信者はそのような決定においてより大きな役割を果たす可能性があります。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.
調査のためのもう1つの領域は、受信者能力の領域です。送信者が能力情報を持っていない場合、最も一般的な結果は、システム全体の機能を深刻に十分に活用しているコミュニケーションの最も一般的な分母に格下げすることです。以前の標準の取り組み（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:
交渉の分野では、ワークショップの参加者は、主に一連の参加者がメディアと通信するパラメーターに同意するプロセスに焦点を当てました。（このような「ランデブー」交渉の最終結果の一例は、音声会議を開催することに同意する同僚のグループであり、テキストの「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 1つ以上のセカンダリ会場（チャットルームアドレスなど）。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:
調査の1つはメッセージフィルタリングです。送信者および/または受信者の身元、送信者の評判、メッセージスレッドまたは会話のコンテキスト、メッセージヘッダー、メッセージコンテンツ（添付ファイルの存在など）、および時間などの環境要因に基づいて、特定の情報に基づいています。日または個人的な気分 - ユーザーまたはエージェントは、メッセージに関して幅広いアクションの1つを取得することを決定する場合があります（バウンス、無視、ファイル、複製、アーカイブ、受け入れ、通知など）。このプロセスでは、正式化がどれだけ必要か、さらには役立つかさえ、公開されていますが、ワークグループの参加者は、可能な調査のいくつかの領域を特定しました。
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.
異なるメッセージングメディアは、さまざまな基礎となるトランスポートを使用します。たとえば、一部のメッセージングシステムは、遅いリンクや損失のあるリンクに対してより耐性がありますが、他のメッセージは、損失耐性の少ない輸送メカニズムに依存する可能性があります。輸送プロファイルが異なるメディアを統合することは困難です。1つは、同じアドレス指定エンドポイントが時間の経過に伴う同じエンティティを表すと仮定することで保証されない可能性があると仮定すると（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.
クロスメディアとクロス輸送統合で発生する別の問題は、参照の同期です。これは特定のメッセージに適用されますが、メッセージフラグメントにも適用される場合があります。大規模な補助データなど、一部のメッセージフラグメントは、たとえば小さな必須テキストデータなど、他のものとは別に輸送されることが望ましい場合があります。メッセージのフラグメントは、メッセージの他の部分とは別に転送、複製、アーカイブなどもあります。トランスポートの同期に関連する1つの要因は、一部のメッセージングメディアがプッシュ指向（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.
メッセージフラグメントを異なるメディアで輸送できる場合、おそらく別々の時間や別々のパスを介して到着する可能性がある場合、パッケージセキュリティの問題は深刻なものになります。伝統的に、メッセージは、ヘッドエンドのパッケージ全体を暗号化し、受信側でそれを復号化することにより保護されています。ただし、メディアタイプの部品に基づいてトランスポートがメッセージをフラグメントすることを許可したい場合、そのアプローチは実行可能ではありません。
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).
広範囲にわたるメッセージ暗号化をより実現可能にする可能性のある要因の1つは、電子メール、インスタントメッセージング、およびインターネットテレフォニーに非常に類似した信頼モデルがあることです。しかし、コミュニケーションの定義は、これらのテクノロジー間でかなり異なります。電子メール「メッセージは物」であり、それ自体が離散オブジェクトです。電話では、個別のメッセージではなく、会話やセッションのリアルタイムの流れに焦点を当てています。そして、私はテキストメッセージの迅速で前後の交換に集中しているため、調停位置を保持しているようです（これはメッセージングセッションと見なすことができます）。
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.
コミュニケーションテクノロジーのコンテキストでは、アイデンティティのヒント - 共有された知識、会話スタイル、音声トーン、メッセージングパターン、語彙など - は、主要な指紋、デジタル署名、その他の電子アーティファクトよりも有用な情報を提供できます。ほとんどのエンドユーザーの経験から離れています。これまで、このようなアイデンティティのヒントのチェックは、プログラムではなく直感的です。
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.
承認の議論から生まれた明らかに望ましいエンジニアリングプロジェクトは、分配された評判サービスでした。メッセージの承認に関して他のことをする必要があることは、メッセージの受信者がメッセージの送信者の評判を確認できるようにすることを望んでいることに同意しました。これは、受信者が事前の経験を持たない送信者の場合に特に役立ちます。つまり、「見知らぬ人への紹介」を得る方法として評判サービスを使用します。この評判サービスが分散化される必要性が明らかにありました。単一の集中評判サービスは一部のコンテキストでは役立ちますが、インターネット全体のサービスには拡大しません。
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.
許可における2つの潜在的な研究トピックが議論されました。第一に、認可決定におけるホワイトリストとブラックリストの使用を中心としたかなりの議論がありましたが、それぞれのアプローチの相対的な有用性を完全に調べるには研究が必要であると考えられていました。参加者にとっては、ブラックリストが既知の非認可の送信者を除外できることは明らかでしたが、単に新しいアイデンティティを取得するのが容易であるため、「攻撃的な」不要な送信者を止めないでください。ホワイトリストは、受信者に既知のもののみにメッセージを制限するのに役立ちますが、不明なパーティーからのメッセージを許可するために、何らかの紹介サービスを使用する必要があります。参加者はまた、この分野で行われる有用な建築作業があるかもしれないと考えました。
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つのことを行う必要があります。まず、明らかに受信者は、それを配信するか拒否するために、何らかの方法でメッセージを派遣する必要があります。しかし、その決定には、受信者が下す可能性のある次の認可決定のセットにも副作用があります。この決定は、メッセージの送信者を「賞賛」または「非難」する評判システムにフィードバックする場合があります。
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を参照）、これはさらなる研究のための適切なトピックかもしれません。
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つの異なるメカニズムを使用して、メッセージの複製コピーが送信される場合がある場合にもパッケージ全体を識別する必要があります。受信側は、1つのメカニズムを介してメッセージのコピーを既に受け取り、別のメカニズムを介してメッセージのコピーを既に受信していることを確認する必要があります。メッセージのコピーは単に複製です。
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.
インターネット全体のサービスを開発して、キーイング素材を公開および取得することは役立ちます。考えられる解決策の1つは、おそらく既存のワーキンググループのエンジニアリングアイテムとして、そのようなサービスを安全な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は、会議室と軽食のスポンサーシップについて、Qualcomm Incorporatedに感謝したいと思います。
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 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
エリック・オールマン・ナサニエル・ボレンシュタイン・ベン・キャンベル・デイブ・クロッカー・レスリー・マーク・マーク・デイ・マーク・クリスピン・スティーブ・ドーナー・リサ・デュッセー・ケビン・フォール・ネッド・フリード・ランディ・ゲレンズ・ラリー・グリーンフィールドニコフジョン・ピーターソン・ブレイク・ラムズデル・ピート・レストニック・ジョナサン・ローゼンバーグピーター・アンドレ・グレッグ・ヴォードルイユ
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）Collaborative Authorling（Lisa Dusseault）同意ベースのメッセージ（John Klensin）コンテンツセキュリティ（Blake Ramsdell）イベント通知（Joe Hildebrand）拡張メッセージ（Dave Crocker）Group Messagin - アンドレ）アイデンティティと評判（ジョン・レヴァイン）メッセージングのインスタントメッセージと存在の問題（ベン・キャンベル）大規模な電子メール環境（エリック・オールマン）メール/ニュース/ブログの収束（ラリー・グリーンフィールド）メッセージングとスパム（カレン・ジェニングス）メッセージ）MUA/MDA、MUA/MSA、およびMUA/メッセージストアインタラクション（Mark Crispin）同意ベースのメッセージ（Jon Peterson）リッチペイロード（Steve Hole）セッション指向のメッセージング（Rohan Mahy）スパムモバイルデバイスの予想（Rohan Mahy）の存在GREG VAUDREUIL）到達が困難なネットワーク（Kevin Fall）のコミュニケーション（Kevin Fall）IM（Hisham Khartabil）Syndication（Paul Hoffman）Transport Security（Alexey Melnikov）Voip Peering andメッセージング（Jonathan Rosenberg）Webmail、MMS、およびモバイルメール（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（編集者）インターネットアーキテクチャボードQualcomm Incorporated 5775 Morehouse Drive San Diego、CA 92121-1714 US
Phone: +1 858 651 4478
EMail: presnick@qualcomm.com
URI: http://www.qualcomm.com/~presnick/
Peter Saint-Andre (Editor) Jabber Software Foundation P.O. Box 1641 Denver, CO 80201-1641 US
Peter Saint-Andre（編集者）Jabber Software Foundation P.O.Box 1641 Denver、Co 80201-1641 US
Phone: +1 303 308 3282
EMail: stpeter@jabber.org
URI: http://www.jabber.org/people/stpeter.shtml
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。