RFC4417 日本語訳
4417 Report of the 2004 IAB Messaging Workshop. P. Resnick, Ed., P.Saint-Andre, Ed.. February 2006. (Format: TXT=47201 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Resnick, Ed.
Request for Comments: 4417 IAB
Category: Informational P. Saint-Andre, Ed.
JSF
February 2006
ワーキンググループのP.レズニック、エドをネットワークでつないでください。コメントのために以下を要求してください。 4417年のIABカテゴリ: エド情報のP.サンアンドレ、JSF2006年2月
Report of the 2004 IAB Messaging Workshop
2004IABメッセージングワークショップのレポート
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)インターネット協会(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)を固守したと報告します。 ワークショップは6と2004年10月7日にバーリンゲーム(カリフォルニア)(米国)で開かれました。 ワークショップの目標は、インターネット(包含、他、電子メール、インスタントメッセージング、および声のメッセージング)で異なったメッセージング技術の現状を調べて、それらの共通点と違いを見て、今後の活動をできた工学、研究、および建築話題を見つけることでした。 このレポートはワークショップとIABの議論と結論をまとめます。
Resnick & Saint-Andre Informational [Page 1] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[1ページ]のRFC4417IAB
Table of Contents
目次
1. Introduction ....................................................3
2. Methodology .....................................................4
3. Issues ..........................................................5
3.1. Authorization ..............................................5
3.2. Multiple Communication Channels ............................6
3.3. Negotiation ................................................8
3.4. User Control ...............................................9
3.5. Message Transport ..........................................9
3.6. Identity Hints and Key Distribution .......................10
4. Recommendations ................................................11
4.1. Authorization .............................................11
4.2. Multiple Communication Channels ...........................12
4.3. Negotiation ...............................................13
4.4. User Control ..............................................13
4.5. Message Transport .........................................14
4.6. Identity Hints and Key Distribution .......................16
5. Security Considerations ........................................16
6. Acknowledgements ...............................................16
Appendix A. Participants .........................................17
Appendix B. Pre-Workshop Papers ..................................18
1. 序論…3 2. 方法論…4 3. 問題…5 3.1. 認可…5 3.2. 複数の通信チャネル…6 3.3. 交渉…8 3.4. ユーザコントロール…9 3.5. メッセージ輸送…9 3.6. アイデンティティヒントと主要な分配…10 4. 推薦…11 4.1. 認可…11 4.2. 複数の通信チャネル…12 4.3. 交渉…13 4.4. ユーザコントロール…13 4.5. メッセージ輸送…14 4.6. アイデンティティヒントと主要な分配…16 5. セキュリティ問題…16 6. 承認…16 付録A.関係者…17 付録B.プレワークショップ書類…18
Resnick & Saint-Andre Informational [Page 2] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[2ページ]のRFC4417IAB
1. Introduction
1. 序論
Current email infrastructure is a mixture of facilities to accomplish its task of end-to-end communications through a relay mesh. That mixture has come about as requirements have changed over the years. Discussions recur over the years, often including complaints that some desired features of email (such as internationalization, efficient encoding of structured data, trusted communication) are ill-served by the current infrastructure, or that some of the current infrastructure seems to be adversely affected by current problems on the Internet (most recently including problems such as spam, viruses, and lack of security infrastructure). For many years, the daunting task of revamping email infrastructure has been considered, with justifiably little enthusiasm for taking on such a task. However, there has been some recent informal discussion on the kinds of things that would be desirable in a "next generation" email.
現在のメールインフラストラクチャはリレーメッシュを通してエンド・ツー・エンド通信に関するタスクを達成する施設の混合物です。 要件が数年間変化するのに応じて、その混合物は生じました。 しばしば、議論が数年間再発するか、メール(国際化、構造化されたデータ、信じられたコミュニケーションの効率的なコード化などの)のいくつかの必要な特徴がある苦情を含んでいるのは現在のインフラストラクチャでほとんど役立たなかったか、または現在のインフラストラクチャのいくつかがインターネットの現在の問題で悪影響を受けるように思えます(ごく最近セキュリティインフラストラクチャのスパムや、ウイルスや、不足などの問題を含んでいて)。 何年間も、メールインフラストラクチャを改造する困難な仕事は考えられています、そのようなタスクを引き受けることに対する正当に少ない熱意をもって。 しかしながら、「次世代」メールで望ましいものの種類の何らかの最近の四角ばらない意見の交換がありました。
At the same time, other messaging infrastructures (including those associated with "instant messaging" and "web logging") are currently being deployed that appear to address many of the above desired features and outstanding problems, while adding many features not currently considered part of traditional email (like prior-consent- based acceptance of messages). However, each of these technologies (at least in their current deployment) seem to lack some of the features commonly associated with email (such as selective and partial message delivery, queued multi-hop relaying, offline message management, and efficient non-textual content delivery).
同時に、現在伝統的なメール(メッセージの先の同意によるベースの承認のような)の一部であることは考えられていない多くの特徴を加えている間に上記の必要な特徴と未解決問題の多くを記述するように見える他のメッセージングインフラストラクチャ(「インスタントメッセージング」と「ウェブ伐採」に関連づけられたものを含んでいる)は現在、配備される予定です。 しかしながら、それぞれのこれらの技術(少なくとも彼らの現在の展開における)は一般的にメール(選択していて部分的なメッセージ配送や、列に並ばせられたマルチホップリレーや、オフラインメッセージ管理や、効率的な非原文の内容物配送などの)に関連している特徴のいくつかを欠いているように思えます。
The Internet Architecture Board (IAB) believed that the time was ripe to examine the current state of messaging technologies on the Internet and to see if there are areas of work that can be taken on to advance these technologies. Therefore, the IAB held a workshop on Internet messaging, taking some of the above issues as input, in order to formulate some direction for future study of the area of messaging.
インターネット・アーキテクチャ委員会(IAB)は、時間がインターネットでメッセージング技術の現状を調べて、これらの技術を進めるために引き受けることができる仕事の領域があるかどうか確認するために熟していると信じていました。 したがって、IABはインターネットメッセージングでワークショップを開きました、入力されるように上記の問題のいくつか取って、メッセージングの領域の今後の研究のための何らかの指示を定式化するために。
The topic of messaging is broad, and the boundaries of what counts as messaging are not always well-defined. Rather than limit themselves to a philosophical discussion of the nature of messages, the workshop participants adopted the attitude of "we know it when we see it" and used as their primary examples such well-established types of messaging as email and instant messaging (IM), while also discussing more "peripheral" types of messaging such as voice messaging and event notifications. (Message queuing systems with guaranteed delivery and transactional integrity, such as those used in enterprise workflow engines and some "web services" architectures, were operationally if not intentionally out of scope.) The participants worked to discover common themes that apply to all the
メッセージングの話題は広いです、そして、メッセージングにみなすことに関する境界はいつも明確であるというわけではありません。 むしろ、講習会参加者は、また、メッセージングの声のメッセージングやイベント通知などの「周囲より」のタイプについて議論している間、自分たちをメッセージの本質の哲学的な議論に制限するより「それを見るとき、私たちはそれを知る」態度を採用して、彼らの第一の例としてメールとインスタントメッセージング(IM)のような安定しているタイプに関するメッセージングを使用しました。 (故意にないなら、保証された配送と取引の保全がある企業作業フローエンジンといくつかの「ウェブサービス」構造に使用されるものなどのメッセージ待ち行列システムは操作上範囲からのそうでした。) 関係者は、すべてに適用される一般的なテーマを発見するために働いていました。
Resnick & Saint-Andre Informational [Page 3] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[3ページ]のRFC4417IAB
types of messaging under consideration. Among the themes identified were the following:
考慮で通信するタイプ。 テーマの中で特定されているのは、以下でした:
o Authorization of senders and recipients o Negotiation of messaging parameters o Consent models and privacy o Identity hints, reputation, and key distribution o Cross-protocol unification of messaging models o Enabling greater user control over messaging o Transport issues (unreliable links, push/pull, etc.) o Message organization (e.g., conversations and threading)
o パラメタo Consentを通信させるNegotiationがモデル化して、プライバシーo Identityが暗示する送付者と受取人oの認可、評判、およびメッセージングの主要な分配o Cross-プロトコル統一はTransportがo Message組織を発行する(頼り無いリンク、プッシュ/牽引力など)メッセージングoの上のo Enablingの、より大きいユーザコントロールをモデル化します。(例えば、会話と縫うように通ること)
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.
以上のリストからわざわざ消えるのは、インスタントメッセージングなどの他のメッセージング環境("spim")とインターネット電話(「痰唾を吐いた」)のお節介なコマーシャルメールか求められていない大量のメール(「スパム」として口語的に知られている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.
このドキュメントは、ワークショップの提案された推薦と同様に議論流動の概観を提供するために構造化されます。 セクション3は様々な話題かテーマに関するワークショップの間に起こった議論をまとめます、セクション4はワークショップから生じたお勧めの研究話題とプロトコル定義の努力の概観を提供しますが。 セクション5はワークショップの間に議論した話題のセキュリティ関連の局面で何らかの見解を提供します。 付録Bはワークショップ議論のためのバックグラウンドとして講習会参加者によって提出されたプレワークショップ話題論文を記載します。
2. Methodology
2. 方法論
Prior to the workshop, brief topic papers were submitted to set the context for the discussions to follow; a list of the papers and their authors is provided in Appendix B of this document.
ワークショップの前に、続く議論のための文脈を設定するために簡潔な話題論文を提出しました。 書類と彼らの作者のリストをこのドキュメントのAppendix 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
ワークショップ自体の間、議論は以下のセクションでまとめられるようにいくつかの話題かテーマに集中しました。 当然、これらの話題を徹底的に扱うのは2日間のワークショップで可能ではありませんでした。 しかしながら、荒いコンセンサスにこれらの話題の重要性の上、または、いつも問題を記述するかもしれない潜在的研究計画とプロトコル標準化の努力の詳細の上で達しました。
Resnick & Saint-Andre Informational [Page 4] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[4ページ]のRFC4417IAB
raised. It is hoped that these summaries will inspire work by additional investigators.
高くする。 これらの概要が追加捜査官による仕事を奮い立たせることが望まれています。
The in-workshop discussions quite naturally fell into three kinds of "tracks": (1) possible engineering tasks to recommend to the IESG and other standardization groups, (2) "blue sky" research topics to recommend to the IRTF and other researchers, and (3) general architectural or "framework" issues for consideration by both engineers and researchers alike. After a full-group discussion each morning to identify possible topics for more in-depth investigation, participants self-selected for involvement in one of three "break- out" sessions. Toward the end of each day, the full groups reconvened, gathered reports from the break-out discussion leaders, and attempted to come to consensus regarding lessons learned and recommendations for further research. The results of the two-day workshop therefore consist of discussion issues and research/ engineering recommendations related to the six topics described in this report.
ワークショップにおける議論は全く自然に3種類の「道」になりました: (1) 考慮のために技術者と研究者の両方で同じく建築するか「枠組み」一般的な問題をIRTF、他の研究者、および(3)に推薦することをIESGと他の標準化グループ、(2)「青空」研究話題に勧める可能な工学タスク。 毎朝の深さの、より多くの調査のために可能な話題を特定するためには完全な集団討議後a、関係者はかかわり合いのために自己に3つの「中断アウト」セッションのコネ1を選択しました。 毎日の終わりに向かって、完全なグループは、再召集して、脱走議論リーダーからレポートを推測して、さらなる調査のためのレッスンが学んだコンセンサス関係と推薦に来るのを試みました。 したがって、2日間のワークショップの結果はこのレポートで説明された6つの話題に関連する議論問題と研究/工学推薦から成ります。
3. Issues
3. 問題
3.1. Authorization
3.1. 認可
It is one thing for a sender to send a message, and another thing for the intended recipient to accept it. The factors that lead a recipient to accept a message include the identity of the sender, previous experience with the sender, the existence of an ongoing conversation between the parties, meta-data about the message (e.g., its subject or size), the message medium (e.g., email vs. IM), and temporal or psychological factors. Authorization or acceptance applies most commonly at the level of the message or the level of the sender, and occasionally also at other levels (conversation thread, medium, sender domain).
それは、送付者がメッセージを送る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).
伝統的に認可が受取人ブロックして定義された扱われて、リスト(また、「ブラックリストとwhitelists」と呼ばれる)を許容するのをさせる送付者。 ブロックリストには限られた価値があります、新しいメッセージングのアイデンティティ(例えば、EメールアドレスかIMアドレス)を獲得するか、または作成する容易さを考えて。 リストを許容してください。はるかに多くが有効ですが(あなたが好きでありたい、またはコミュニケートしたい人々のリストがあなたがそうしない人々の大きい宇宙より小さいので)、彼らで、送付者が新しいか以前に未知の受取人とのコミュニケーションを開始するのが難しくなります。 講習会参加者はこの問題の周りでいくつかの道について議論しました、評判システムと1人の人が第三者(例えば、サインされた招待状による)に別の人を紹介するより良い方法を含んでいて。
Resnick & Saint-Andre Informational [Page 5] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[5ページ]のRFC4417IAB
Reputation systems may be especially worthy of future research, since they emulate a pattern that is familiar from real life. (It may also be valuable to distinguish between (1) reputation as the reactive assessment of a sender created by one or more recipients based on message history and (2) accreditation as a proactive assessment provided by trusted third parties.) Reputation might be based on summing an individual's "scores" provided by recipients on the network. (Naturally, the more important reputation becomes, the more bad actors might attempt to sabotage any given reputation system, so that a distributed as opposed to centralized system might be more desirable.) The actions taken by any given recipient based on the sender's reputation would not necessarily be limited to a simple allow/deny decision; more subtle actions might include placing messages from individuals with lower reputation scores into separate inboxes or redirecting them to other media (e.g., from IM to email).
現実のために身近なパターンを見習うので、評判システムは今後の研究に特にふさわしいかもしれません。 (また、1人以上の受取人によって創造された送付者の反応評価が信頼できる第三者機関によって提供された先を見越す査定として認可をメッセージ歴史と(2)に基礎づけたので、(1) 評判を見分けるのも貴重であるかもしれません。) 評判はネットワークの受取人によって提供された個人の「スコア」をまとめるのに基づくかもしれません。 (より多くの演技下手な俳優が、どんな当然のことの評判システムも故意に妨害するのを試みるかもしれません、当然、評判が重要であれば重要であるほど集権制と対照的に分配されたaが、より望ましいことができなるように。) 送付者の評判に基づく受取人が必ずaに簡単な状態で制限されるというわけではないだろうというどんな当然のことによっても取られた行動は、決定を許容するか、または否定します。 より微妙な動きは、別々の受信トレイかそれらを向け直すことへの下側の評判スコアをもっている個人から他のメディア(例えば、IMからメールまでの)までメッセージを置くのを含むかもしれません。
3.2. Multiple Communication Channels
3.2. 複数の通信チャネル
It is a fact of life that many people use multiple forms of messaging channels: phone, email, IM, pager, and so on. Unfortunately, this can make it difficult for a sender or initiator to know the best way to contact a recipient at any given time. One model is for the initiator to guess, for example, by first sending an email message and then escalating to pager or telephone if necessary; this may result in delivery of redundant messages to the recipient. A second model is for the recipient to publish updated contact information on a regular basis, perhaps as one aspect of his or her presence; this might enable the initiator to determine beforehand which contact medium is most appropriate. A third model is for the recipient to use some kind of "unifier" service that enables intelligent routing of messages or notifications to the recipient based on a set of delivery rules (e.g., "notify me via pager if I receive a voicemail message from my boss after 17:00").
それは多くの人々が複数の形式のメッセージングチャンネルを使用するという現実です: 電話、メール、IM、ポケットベルなど。 残念ながら、これで、送付者か創始者がその時々で受取人に連絡する最も良い方法を知るのが難しくなる場合があります。 1つのモデルが例えば推測する創始者に賛成します、最初に、メールメッセージを送って、次に、必要なら、ポケットベルか電話に徐々に拡大することによって。 これは受取人への余分なメッセージの配送をもたらすかもしれません。 2番目のモデルは定期的にアップデートされた問い合わせ先を発表する受取人に賛成します、恐らくその人の存在の1つの局面として。 これは、創始者が、あらかじめどの連絡媒体が最も適切であるかを決心しているのを可能にするかもしれません。 3番目のモデルがメッセージの知的なルーティングを可能にするある種の「統一者」サービスを利用する受取人に賛成したか、または受取人への通知が規則を配送のセットに基礎づけた、(例えば、「私が17時以降私のボス: 0インチからボイスメールメッセージを受け取るならポケットベルを通して私に通知してください、)、」
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 A受取人は明らかに創始者に許可を与えることによって、その人の最も良い連絡メカニズムを創始者に伝えることができるでしょう、恐らく一種の「認可象徴」による。
Resnick & Saint-Andre Informational [Page 6] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[6ページ]のRFC4417IAB
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つの媒体のための連絡先を最もよく得るか否かに関係なく、探検される必要があります(「私にメールして、私の携帯の番号を得てください」)。
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.
また、流通チャネルの多様性で、送付者が受取人との「信頼できる」関係を確立するのが、より複雑になります。 送付者の観点から、1個のチャンネルの上の受取人が別のチャンネルの上の同じ受取人であることは明白ではありません。 これらの受取人「アイデンティティ」がどう結びつけられるかは、未決問題です。
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 Whitelistingは受取人の観点からの関係の明白な定義です、受取人が会話に従事していても構わないと思っている送付者のリストから成って。 aが実行し得る解決法であったかもしれないならリストを許容してください、そして、それらは比較的静的な認可計画です。
Resnick & Saint-Andre Informational [Page 7] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[7ページ]のRFC4417IAB
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 Ruleベースの認可は広いセットの評価基準に基づく関係の生存力のアルゴリズムの評価にかかわります。 これによる盛込まれることができるより一般的な認可計画がメッセージ特殊化と発行人特殊化としてともにリスト、象徴、および追加評価基準にそのようなものを許容するということです。
3.3. Negotiation
3.3. 交渉
In the area of negotiation, the workshop participants focused mainly on the process by which a set of participants agree on the media and parameters by which they will communicate. (One example of the end result of such a "rendezvous" negotiation is a group of colleagues who agree to hold a voice conference, with a textual "groupchat" as a secondary communications channel.) In order to enable cross-media negotiation, it may be necessary to establish a bridge between various identities. For example, the negotiation may occur via email, but the communication may occur via phone, and in order to authorize participants the conference software needs to know their phone numbers, not their email addresses. Furthermore, the parameters to be negotiated may include a wide variety of aspects, including:
交渉の領域では、講習会参加者が主に1セットの関係者がメディアに同意する過程とそれらが交信するパラメタに焦点を合わせました。 (そのような「ランデブー」交渉の結末に関する1つの例が声の会議を開催するのに同意する同僚のグループです、二次コミュニケーションチャンネルとしての原文の"groupchat"で。) 交差しているメディア交渉を可能にするために、様々なアイデンティティの間の橋を設立するのが必要であるかもしれません。 コミュニケーションは電話を通して現れるかもしれません、そして、例えば、交渉はメールで起こるかもしれませんが、会議ソフトウェアは関係者に権限を与えるのに彼らの電話番号を知る必要があります、それらのEメールアドレスでない。 その上、交渉されるべきパラメタはさまざまな局面、包含を含むかもしれません:
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 コミュニケーション(例えば、"backgrounder"ドキュメントの分配). o Whoのための前提条件はコミュニケーションを開始するでしょう。o Whoは○ 第一の「開催地」(例えばすべての関係者が電話をする電話番号). o Oneの、または、より二次のコミュニケーションに参加するでしょう。開催地(例えば、chatroomアドレス); 第一の、または、二次の開催地が利用可能でないなら、o Backupは計画しています。○ . ○ 議論ではなく、管理者か議長o Whetherのアイデンティティがそうする議論のための話題か話題が、登録されたか、または出来事の. o Schedulingを記録しました、再発を含んでいて、ことです(例えば、異なった例には、異なった開催地か他の詳細があるかもしれません)。
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.
本当に、いくつかの文脈では、コミュニケーションが既に始まった(例えば、新しい関係者を招待するか、または伐採などの主要なパラメタを変える)後にパラメタを交渉するか、または再交渉するのが望ましくさえあるかもしれません。 講習会参加者が、パラメタのフルセットの徹底的な交渉が多くのクラスに関するコミュニケーションで不要である傾向があると認めていた間、「マルチ-パーティー」コミュニケーションの交渉のための一般化された枠組みかプロトコルの部分はさまざまなアプリケーションと文脈で有用であることが分かるかもしれません。
Resnick & Saint-Andre Informational [Page 8] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[8ページ]のRFC4417IAB
3.4. User Control
3.4. ユーザコントロール
A common perception among "power users" (and, increasingly, average users) on the Internet is that messaging is not sufficiently under their control. This is not merely a matter of unsolicited communications, but also of managing multiple messaging media and handling the sheer volume of messages received from familiar and unfamiliar senders alike. Currently, individuals attempt to cope using various personal techniques and ad hoc software tools, but there may be an opportunity to provide more programmatic support within Internet protocols and technologies.
インターネットの「パワーユーザー」(ますます平均ユーザ)の中の一般的な知覚はメッセージングが十分、そうでないということです。彼らのコントロールの下で。 これは単に求められていないコミュニケーションの問題であるのではなく複数のメッセージングメディアとメッセージの莫大な量がなじみ深くてなじみのない送付者から同じく受け取った取り扱いを経営する問題でもあります。 現在、個人は、様々な個人的なテクニックと臨時のソフトウェアツールを使用することで対処するのを試みますが、インターネットプロトコルと技術の中で、よりプログラムに従ったサポートを提供する機会があるかもしれません。
One area of investigation is message filtering. Based on certain information -- the identity of the sender and/or recipient(s), the sender's reputation, the message thread or conversational context, message headers, message content (e.g., the presence of attachments), and environmental factors such as time of day or personal mood -- a user or agent may decide to take one of a wide variety actions with regard to a message (bounce, ignore, forward, file, replicate, archive, accept, notify, etc.). While it is an open question how much formalization would be necessary or even helpful in this process, the workgroup participants identified several areas of possible investigation:
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 交差しているメディア糸と会話--交換処理階層構造かo Communication階層構造の後にメディア(例えば、メールかIMにわたるフォーラム議論)の向こう側に特定の糸か会話に属すとしてメッセージにタグ付けをする方法を決定するのは役立っているかもしれません; 焦点の大部分がメッセージにありますが、メッセージは、しばしば、単独で立ちませんが、活動(1セットの会話とドキュメントなどの関連するリソース)糸(すなわち、媒体の中の一貫性を持っているか命令されたセットのメッセージ)、会話(すなわち、メディアに交差するかもしれない1セットの糸)、またはo Controlプロトコルなどの、よりハイレベルの構造物の文脈に存在しています; メッセージングメディアの向こう側にコミュニケーションを管理することにおける使用のための交差しているサービス制御プロトコルの必要があるかもしれないか否かに関係なく、ワークグループの関係者は未決問題としていなくなりました。
3.5. Message Transport
3.5. メッセージ転送
Different messaging media use different underlying transports. For instance, some messaging systems are more tolerant of slow links or lossy links, while others may depend on less loss-tolerant transport mechanisms. Integrating media that have different transport profiles can be difficult. For one, assuming that the same addressing
異なったメッセージングメディアは異なった基本的な輸送を使用します。 例えば、遅いリンクか損失性リンクではいくつかのメッセージシステムが、より許容性があります、他のものは、より少ない損失許容性がある移送機構によるかもしれませんが。異なった輸送プロフィールを持っているメディアを統合するのは難しい場合があります。 そんなに同じアドレシングを仮定する1つのために
Resnick & Saint-Andre Informational [Page 9] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[9ページ]のRFC4417IAB
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.
交差しているメディアと交差している輸送統合で起こる別の問題は参照の同期です。 これは、特定のメッセージに適用しますが、また、メッセージ断片に適用されるかもしれません。 大きい補助データなどのいくつかのメッセージ断片に、それは別々に他のものから輸送されるために望ましいかもしれません、例えば、小さい不可欠のテキストデータ。 また、メッセージ断片は、別々にメッセージの他の部分から進められて、模写されて、格納されるかもしれませんなど。 輸送の向こう側に同期に関連している1つの要素はいくつかのメッセージングメディアがプッシュ指向であるという(例えば、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.
ことによると別々の時勢において、または、別々の経路を通して到着して、異なったメディアの上でメッセージ断片を輸送できるなら、パッケージセキュリティの問題は重大なものになります。 伝統的に、ギヤエンドに全体のパッケージをコード化して、次に、受ける側になってそれを解読することによって、メッセージを保証します。 しかしながら、輸送が部品のメディアタイプに基づくメッセージを断片化するのを許したいと思うなら、そのアプローチは可能にならないでしょう。
3.6. Identity Hints and Key Distribution
3.6. アイデンティティヒントと主要な分配
While it is widely recognized that both message encryption and authentication of conversation partners are highly desirable, the consensus of the workshop participants was that current business and implementation models in part discourage deployment of existing solutions. For example, it is often hard to get new root certificates installed in clients, certificates are (or are perceived to be) difficult or expensive to obtain, one-click or zero-click service enrollment is a worthy but seemingly unreachable goal, and
メッセージ暗号化と会話のパートナーの認証の両方が非常に望ましいと広く認められますが、講習会参加者のコンセンサスはその現在のビジネスでした、そして、実現モデルは一部既存の解決策の展開に水をさしています。 そして例えば、新しいルート証明書をクライアントにしばしばインストールさせにくい、証明書が(または、知覚されます)難しいか、得るために高価であるか、1クリックの、または、無クリックのサービス登録がふさわしい、しかし、外観上手の届かない目標であるということである。
Resnick & Saint-Andre Informational [Page 10] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[10ページ]のRFC4417IAB
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).
広範囲のメッセージ暗号化をより可能にするかもしれない1つの要素はメール、インスタントメッセージング、およびインターネット電話には全く同様の信用モデルがあるということです。 しかし、コミュニケーションの定義はこれらの技術の間でたいへん異なります: メールでは、「メッセージはものであり」、それはそれ自体で離散的な物です。 電話に、焦点が離散的なメッセージよりむしろ会話かセッションのリアルタイムの流れにあります。 そして、それが急速(テキスト・メッセージ(メッセージングセッションと考えることができる)の前後方向の交換)の中心に置かれるので、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.
別の複雑にする要素はメッセージング技術が使用されている広範囲の文脈です: 公共のchatroomsの砕けた会話とビジネスと顧客とのコミュニケーションを通したソーシャルネットワーキングアプリケーションからミッションクリティカルなサプライ・チェーン・マネジメントなどの企業間電子商取引アプリケーションまでのすべて。 異なった聴衆はメッセージングセキュリティとアイデンティティ検証に関して異なるニーズを持っているかもしれません、信用の信頼できる第三者機関やウェブなどのサービスの異なった要求をもたらして。
In the context of communication technologies, identity hints -- shared knowledge, conversational styles, voice tone, messaging patterns, vocabulary, and the like -- can often provide more useful information than key fingerprints, digital signatures, and other electronic artifacts, which are distant from the experience of most end users. To date, the checking of such identity hints is intuitive rather than programmatic.
通信技術の文脈に、アイデンティティヒント(共有知識、会話体、声のトーン、メッセージングパターン、ボキャブラリー、および同様のもの)はしばしばほとんどのエンドユーザの経験によってよそよそしい主要な指紋、デジタル署名、および他の電子人工物より役に立つ情報を提供できます。 これまで、プログラムに従うというよりむしろそのようなアイデンティティヒントの照合は直感的です。
4. Recommendations
4. 推薦
4.1. Authorization
4.1. 認可
The one clearly desired engineering project that came out of the authorization discussion was a distributed reputation service. It was agreed that whatever else needed to be done in regard to authorization of messages, at some point the recipient of the message would want to be able to check the reputation of the sender of the message. This is especially useful in the case of senders with whom the recipient has no prior experience; i.e., using a reputation service as a way to get an "introduction to a stranger". There was clearly a need for this reputation service to be decentralized; though a single centralized reputation service can be useful in some contexts, it does not scale to an Internet-wide service.
認可議論から出て来た1つの明確に望ましい土木計画は分配された評判サービスでした。 他のことなら何でも、メッセージ送信者の評判をチェックできるようにメッセージの受取人が欲しい何らかのポイントでメッセージの認可に関してする必要だったのに同意されました。 これは受取人がどんな先の経験も持っていない送付者の場合で特に役に立ちます。 すなわち、「見知らぬ人への紹介」を得る方法として評判サービスを利用すること。 明確に、この評判サービスが分散される必要がありました。 ただ一つの集結された評判サービスはいくつかの文脈で役に立つ場合がありますが、それはインターネット全体のサービスに比例しません。
Resnick & Saint-Andre Informational [Page 11] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[11ページ]のRFC4417IAB
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つの潜在的研究話題について議論しました。 まず最初に、多くの議論が認可決定におけるwhitelistsとブラックリストの使用を中心に置きましたが、研究がそれぞれのアプローチの相対的な有用性を完全に調べるのに必要であると思われました。 関係者にとって、ブラックリストが知られている非認可された送付者を取り外すことができますが、単に新しいアイデンティティを得る容易さのために求められていない「攻撃的な」送付者を止めないのは、明確でした。 Whitelistsは、メッセージを受取人にとって知られているものだけに制限することの役に立つ場合がありますが、未知のパーティーからメッセージを考慮するためにある種の序論サービスの使用を必要とするでしょう。 また、関係者は、この領域で行われた役に立つ建築仕事があるかもしれないと考えました。
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つのことをしなければなりません: まず最初に、明らかに、受取人は、それを届けるか、またはそれを否定するために何らかの方法でメッセージを派遣しなければなりません。 しかし、また、その決定は受取人がするかもしれない認可決定の次のセットに副作用を返してもらうでしょう。 メッセージ送信者を「賛美する」か、または「非難し」て、決定は評判システムにフィードバックされるかもしれません。
4.2. Multiple Communication Channels
4.2. 複数の通信チャネル
Several interesting and potentially useful ideas were discussed during the session, which the participants worked to transform into research or engineering tasks, as appropriate.
セッションの間、いくつかのおもしろくて潜在的に役に立つ考えについて議論しました、適宜。(関係者は、研究か工学タスクに変形するためにセッションを扱いました)。
In the area of contact information management, the workshop participants identified a possible engineering task to define a service that publishes contact information such as availability, capabilities, channel addresses (routing information), preferences, and policies. While aspects of this work have been attempted previously within the IETF (with varying degrees of success), there remain many potential benefits with regard to managing business-to- business and business-to-customer relationships.
問い合わせ先の領域では、講習会参加者が有用性などの問い合わせ先、能力を発行するサービスを定義する可能な工学タスク、チャンネル・アドレス(ルーティング情報)、好み、および方針を特定しました。 以前にIETF(異なった度の成功がある)の中でこの仕事の局面を試みている間、ビジネスからビジネスとビジネスから顧客への関係を管理することに関する多くの潜在的利益が残っています。
The problem of suppressing redundant messages is becoming more important as the use of multiple messaging channels becomes the rule for most Internet users, and as users become accustomed to receiving notifications in one channel of communications received in another channel. Unfortunately, there are essentially no standards for cross-referencing and linking of messages across channels; standards work in this area may be appropriate.
複数のメッセージングチャンネルの使用がほとんどのインターネットユーザのための規則になるのに従って、余分なメッセージを削除するという問題は、より重要になっていました、そして、ユーザが受信に慣れるようになるので、コミュニケーションの1個のチャンネルによる通知は別のチャンネルで受信されました。 残念ながら、メッセージが十字で参照をつけて、リンクされる規格が全くチャンネルのむこうに本質的にはありません。 この領域での標準化作業は適切であるかもしれません。
Resnick & Saint-Andre Informational [Page 12] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[12ページ]のRFC4417IAB
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を見る)への洞察に結合されると、これはさらなる調査のための適切な話題であるかもしれません。
4.3. Negotiation
4.3. 交渉
Discussion in the area of negotiation resulted mostly in research- oriented output. The session felt that participants in a conversation would require some sort of rendezvous mechanism during which the parameters of the conversation would be negotiated. To facilitate this, a "conversation identifier" would be needed so that participants could identify the conversation that they wished to participate in. In addition, there are at least five dimensions along which a conversation negotiation may occur:
交渉の領域での議論はほとんど研究の指向の出力をもたらしました。 セッションは、会話している関係者が会話のパラメタが交渉されるある種のランデブーメカニズムを必要とすると感じました。 これを容易にするのに、「会話識別子」が必要でしょう、したがって、その関係者は彼らが参加したがっていた会話を特定できました。 さらに、会話交渉が起こるかもしれない少なくとも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の能力を使用しました。
Research into how to communicate these different parameters may prove useful, as may research into the relationship between the concepts of negotiation, rendezvous, and conversation.
どうこれらの異なったパラメタを伝えるか研究は交渉、ランデブー、および会話の概念の間の関係の研究であるかもしれないののように有用であることが分かるかもしれません。
4.4. User Control
4.4. ユーザコントロール
A clear architectural topic to come out of the user control discussion was work on activities, conversations, and threads. In the course of the discussion, the user's ability to organize messages into threads became a focus. The participants got some start on defining threads as a semi-ordered set of messages, a conversation as
ユーザコントロール議論から来る明確な建築話題は活動、会話、および糸への作業でした。 議論の間に、糸にメッセージを組織化するユーザの能力は焦点になりました。 関係者は定義における始めが1つの準順序集合に関するメッセージ、会話として縫うように通るいくつかを得ました。
Resnick & Saint-Andre Informational [Page 13] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[13ページ]のRFC4417IAB
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.
1セットの糸、および会話と関連するリソースの収集としての活動。 議論はメッセージの順序の付いた木として糸の伝統的な概念を広くしました。 会話は、糸を一緒に集めて、それらが交差しているメディアであることを持つことができます。 メッセージは潜在的に1個以上の糸に属すことができます。 糸自体には、「副-糸」があるかもしれません。 これらの話題のすべてが、建築概観が焦点にもたらされるのを必要とします。
There is also engineering work that is already at a sufficient level of maturity to be undertaken on threads. Though there is certainly some simple threading work being done now with messaging, it is pretty much useful only for a unidirectional tree of messages in a single context. Engineering work needs to be done on identifiers that could used in threads that cross media. Additionally, there is likely work to be done for messages that may not be strictly ordered in a thread.
すなわち、既に十分なレベルの円熟のときに、糸の上に引き受けられるために、技術系もあります。 現在メッセージングで行われる仕事は確かにいくつか縫うように通ることですが、簡単なそれはほとんどただ一つの文脈のメッセージの単方向の木だけの役に立ちます。 仕事がそうすることができた識別子でするために必要とする工学はそんなに交差している糸でメディアを使用しました。 さらに、糸で厳密に注文されないかもしれないメッセージのためのありそうなやるべき仕事があります。
The topics of "control panels" and automated introductions were deemed appropriate for further research.
「コントロールパネル」と自動化された序論の話題はさらなる調査に適切であると考えられました。
4.5. Message Transport
4.5. メッセージ転送
A central research topic that came out of the transport session was that of multiple transports. It was felt that much research could be done on the idea of transporting pieces of messages over separate transport media in order to get the message to its final destination. Especially in some high-latency, low-bandwidth environments, the ability to run parallel transports with different parts of messages could be extremely advantageous. The hard work in this area is re-associating all of the pieces in a timely manner, and identifying the single destination of the message when addressing will involve multiple media.
輸送セッションから出て来た主要な研究話題は複数の輸送のものでした。 最終的な目的地に意味を了解するために別々の輸送メディアの上でメッセージの断片を輸送するという考えでそれだけの研究ができたと感じられました。 何らかの高い潜在、特に低バンド幅環境で、メッセージの異なった部分で平行な輸送を走らせる能力は非常に有利であるかもしれません。 この領域でのきつい仕事は、直ちに片のすべてを再関連づけて、アドレシングがマルチメディアにかかわると、メッセージの単一の目的地を特定することです。
A common theme that arose in several of the discussions (including user control and message unification), but that figured prominently in the transport discussion, was a need for some sort of identifier. In the transport case, identifiers are necessary on two levels. Identifiers are needed to mark the endpoints in message transport. As described in the discussion, there are many cases where a message could reasonably be delivered to different entities that might all correspond to a single person. Some sort of identifier to indicate the target person of the message, as well as identifiers for the different endpoints, are all required in order to get any traction in this area. In addition, identifiers are also required for the messages being transported, as well as their component parts. Certainly, the idea of transporting different parts of a message over different mechanisms requires the identification of the containing message so that re-assembly can occur at the receiving end. However,
いくつかの議論(ユーザコントロールとメッセージ統一を含んでいる)で起こりましたが、輸送議論を顕著に含んだ一般的なテーマはある種の識別子の必要性でした。 輸送場合では、識別子が2つのレベルで必要です。 識別子が、メッセージ転送における終点を示すのに必要です。 議論で説明されるように、多くのケースが合理的に1人の人にすべて文通されるかもしれない異なった実体にメッセージを送ることができたところにあります。 メッセージの目標人、および異なった終点のための識別子がすべてであることを示すある種の識別子が、この領域のどんな牽引も得るのに必要です。 また、さらに、識別子が彼らのコンポーネントの部品と同様に輸送されるメッセージに必要です。 確かに、異なったメカニズムの上でメッセージの異なった部分を輸送するという考えは、再アセンブリが犠牲者に現れることができるように、含んでいるメッセージの識別を必要とします。 しかしながら
Resnick & Saint-Andre Informational [Page 14] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[14ページ]のRFC4417IAB
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つの異なったメカニズムを使用させられるかもしれないそれらのケースに必要です: 犠牲者は、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.
最終的に、より建築している話題はrestartabilityのものでした。 信頼性の問題とのリンクに直面して、ほとんどの現在のメッセージ転送が、始めからのメッセージの輸送を中止して、再開するでしょう。 いくつかのメカニズムが再開のために中間のセッションであることで存在していますが、広くそれらを実行しません、そして、確かに、プロトコル限界の向こう側にめったにそれらを使用できません。 再開メカニズムにおける何らかの建築指導は役に立つ添加でしょう。
Resnick & Saint-Andre Informational [Page 15] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[15ページ]のRFC4417IAB
4.6. Identity Hints and Key Distribution
4.6. アイデンティティヒントと主要な分配
It would be helpful to develop Internet-wide services to publish and retrieve keying material. One possible solution is to build such a service into Secure DNS, perhaps as an engineering item in an existing working group. However, care is needed since that would significantly increase the size and scope of DNS. A more research- oriented approach would be to investigate the feasibility of building Internet-wide key distribution services outside of DNS. In doing so, it is important to keep in mind that the problem of distribution is separate from the problem of enrollment, and that name subordination (control over what entities are allowed to create sub-domains) remains necessary.
材料を合わせる発行して、検索するインターネット全体のサービスを開発するのは役立っているでしょう。 1つの可能な解決策はそのようなサービスをSecure DNSに組み込むことです、恐らく既存のワーキンググループにおける工学項目として。 それはDNSのサイズと範囲をかなり増加させるでしょう、しかしながら、したがって、注意が必要です。 適応するより多くの研究アプローチはDNSの外でインターネット全体の主要な配布サービスを組み込むことに関する実現の可能性を調査するだろうことです。 そうするのにおいて、分配の問題が登録の問題から別々であり、名前従属(どんな実体がサブドメインを作成できるかのコントロール)が必要なままで残っているのを覚えておくのは重要です。
Research may be needed to define the different audiences for message security. For example, users of consumer-oriented messaging services on the open Internet may not generally be willing or able to install new trusted roots in messaging client software, which may hamper the use of security technologies between businesses and customers. By contrast, within a single organization it may be possible to deploy new trusted roots more widely, since (theoretically) all of the organization's computing infrastructure is under the centralized control.
研究が、メッセージセキュリティのために異なった聴衆を定義するのに必要であるかもしれません。 一般に、例えば、開いているインターネットの消費者指向のメッセージングサービスのユーザは、望んでいるか、または新しい信じられたルーツをメッセージングクライアントソフトウェアにインストールできないかもしれません。(それは、ビジネスと顧客の間のセキュリティー技術の使用を妨げるかもしれません)。 対照的に、単純組織の中では、より広く新しい信じられたルーツを配備するのは可能であるかもしれません、組織のコンピューティングインフラストラクチャの(理論的に)すべては集中制御中であるので。
In defining security frameworks for messaging, it would be helpful to specify more clearly the similarities and differences among various messaging technologies with regard to trust models and messaging metaphors (e.g., stand-alone messages in email, discrete conversations in telephony, messaging sessions in instant messaging). The implications of these trust models and messaging metaphors for communications security have not been widely explored.
メッセージングのためにセキュリティフレームワークを定義する際に、様々なメッセージング技術の中で信用モデルとメッセージング比喩(例えば、メールによるスタンドアロンのメッセージ、電話での離散的な会話、インスタントメッセージングにおけるメッセージングセッション)に関して、より明確に類似性と違いを指定するのは役立っているでしょう。 通信秘密保全のためのこれらの信用モデルとメッセージング比喩の含意は広く探られていません。
5. Security Considerations
5. セキュリティ問題
Security is discussed in several sections of this document, especially Sections 3.5, 3.6, 4.5, and 4.6.
このドキュメント、特に数人のセクションのセクション3.5、3.6、4.5、および4.6でセキュリティについて議論します。
6. Acknowledgements
6. 承認
The IAB would like to thank QUALCOMM Incorporated for their sponsorship of the meeting rooms and refreshments.
IABは彼らのミーティング部屋と軽い飲食物のスポンサーシップについてクアルコム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.
エディタは講習会参加者のすべてに感謝したがっています。 エリック・オールマン、テッド・ハーディー、およびCullenジョニングスは有用なノートを取りました。(ノートはこのドキュメントを書くタスクを緩和しました)。
Resnick & Saint-Andre Informational [Page 16] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[16ページ]のRFC4417IAB
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
マーククリスピン・スティーブ・デルナー・リサ・Dusseaultケビン・Fallネッドがランディ・Gellensラリー・グリーンフィールドテッド・ハーディー・ジョー・ヒルデブラント・ポール・ホフマン・スティーブ・Holeスコット・Hollenbeckラス・Housley Cullenジョニングス・Hisham Khartabilジョン・Klensinジョン・レヴィン・Rohanマーイ・Alexeyメリニコフ・ジョン・ピーターソン・ブレーク・Ramsdellピートレズニック・ジョナサン・ローゼンバーグ・ピーター・サンアンドレグレッグ・ボードルイを解放したエリックオールマンナザニエルBorensteinベンキャンベルデーヴ医者レスリーDaigleマーク日
Resnick & Saint-Andre Informational [Page 17] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[17ページ]のRFC4417IAB
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)
統合(ナザニエルBorenstein)チャンネルセキュリティ(ラスHousley)の協力的なオーサリング(リサDusseault)の同意ベースのメッセージング(ジョンKlensin)の満足しているセキュリティ(ブレークRamsdell)イベント通知(ジョー・ヒルデブラント)の拡張メッセージサービス(デーヴ・クロッカー)グループメッセージングをCalendaringします; (ピーターサンアンドレ) アイデンティティと評判(ジョン・レヴィン)インスタントメッセージングと存在は、比喩(テッド・ハーディー)のMUA/MDAを通信させながら、メッセージング(ベン・キャンベル)大きいメール環境(エリック・オールマン)メール/ニュース/ブロッグ集合(ラリー・グリーンフィールド)でメッセージングとスパム(Cullenジョニングス)を発行します; MUA/MSA、および中の達するのが難しいネットワーク(ケビンFall)が不-(Hisham Khartabil)シンジケート組織化(ポール・ホフマン)輸送セキュリティ(Alexeyメリニコフ)VoIPのじっと見ることの必要性を格納して、送るモバイル機器(グレッグ・ボードルイ)コミュニケーションとメッセージングへの同意ベースのメッセージング(ジョン・ピーターソン)の豊かな有効搭載量(スティーブHole)のセッション指向のメッセージング(Rohanマーイ)スパム期待のためのメッセージMUA/ストア相互作用(マーククリスピン)存在、(ジョナサン・ローゼン氷山) ウエブメール、MMS、およびモバイルメール(ランディGellens)
Resnick & Saint-Andre Informational [Page 18] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[18ページ]のRFC4417IAB
Authors' Addresses
作者のアドレス
Peter W. Resnick (Editor) Internet Architecture Board QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 US
ピーターW.レズニック(エディタ)インターネット・アーキテクチャ委員会クアルコム法人組織の5775モアハウス・Driveカリフォルニア92121-1714サンディエゴ(米国)
Phone: +1 858 651 4478 EMail: presnick@qualcomm.com URI: http://www.qualcomm.com/~presnick/
以下に電話をしてください。 +1 4478年の858 651メール: presnick@qualcomm.com ユリ: http://www.qualcomm.com/~presnick/
Peter Saint-Andre (Editor) Jabber Software Foundation P.O. Box 1641 Denver, CO 80201-1641 US
ピーターサンアンドレ(エディタ)おしゃべりソフトウェア財団P.O. Box1641CO80201-1641デンバー(米国)
Phone: +1 303 308 3282 EMail: stpeter@jabber.org URI: http://www.jabber.org/people/stpeter.shtml
以下に電話をしてください。 +1 3282年の303 308メール: stpeter@jabber.org ユリ: http://www.jabber.org/people/stpeter.shtml
Resnick & Saint-Andre Informational [Page 19] RFC 4417 IAB Messaging Workshop February 2006
ワークショップ2006年2月に通信するレズニックとサンアンドレの情報[19ページ]のRFC4417IAB
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Resnick & Saint-Andre Informational [Page 20]
レズニックとサンアンドレ情報です。[20ページ]
一覧
スポンサーリンク
