INTERNET-DRAFT
有効期限: February 7, 1999
G. Mohr, Activerse
S. Aggarwal, Microsoft
M. Day, Lotus
A. Houri, Ubique
Y. Kohda, Fujitsu
D. Marvit, Fujitsu
7 August 1998
このドキュメントは、インターネットドラフトである。インターネットドラフトはインターネット技術作業団体 (IETF)、その分野、作業グループの作業ドキュメントである。他のグループもまた、インターネットドラフトとして作業ドキュメントを配布しているかもしれないことに注意されたい。
インターネットドラフトは、最大 6 ヶ月有効なドラフトドキュメントであり、如何なる時でも更新、差し替え、他のドキュメントによる上書きが行われるかもしれない。インターネットドラフトを参照資料として使用したり、"作業中" として以外に引用することは不適切である。
現在のインターネットドラフト全体のリストを見るには、ftp.is.co.za (アフリカ)、ftp.nordu.net (ヨーロッパ)、munnari.oz.au (太平洋岸)、ftp.ietf.org (アメリカ東海岸)、ftp.isi.edu (アメリカ西海岸) 上にある、インターネットドラフトシャドウディレクトリ中の "1id-abstracts.txt" をチェックされたい。
このドキュメントの配布は制限されない。pip@iastate.edu の PIP 議論グループに、コメントを送られたい。そのグループの議論は、http://lists.fsck.com/cgi-bin/wilma/pip で遂行されている。
PIP/0.2 は率直で、協調可能な方法で 'プレゼンス情報プロトコル' 要件を適えることに関する、あるアイデアのためのテストベッドとして設計されたデモンストレーションプロトコルである。この分野における以前の提案から抜き出すと、PIP/0.2 は以下を狙いとする。
PIP/0.2 は、特に以下を試みてはいない。
1. このメモの状態
2. Abstract
3. 内容
4. 導入
5. 名前付け
6. メッセージ形式
7. トランスポート
8. 文字符号化
9. メソッド
9.1 SUBSCRIBE
9.2 UNSUBSCRIBE
9.3 CHANGE
9.4 NOTIFY
9.5 FETCH
10. 応答コード
11. ヘッダ
11.1 HTTP/1.1 からの変更無しで採用されたヘッダ
11.2 Duration
11.3 Renew-Duration
11.4 From
11.5 Origin
11.6 Sendback
11.7 Subscription-ID
11.8 Notify-class
11.9 Regarding
12. リース
13. 購読
14. リダイレクション
15. ドメイン規約
15.1 プレゼンス情報
15.2 メッセージ交換
15.3 リダイレクションの確立 (オプション)
16. プロクシ
17. セキュリティ
18. 例
18.1 有効性の確立
18.2 他者の購読
18.3 インスタントメッセージ交換
18.4 リダイレクションによる他者からの発行
19. 参照
20. 作者のアドレス
如何なる瞬間も、世界中の何百万人もの人々がインターネットと相互作用している。しかし、彼らはお互いに相互作用できるか。
大抵、それらはできない。なぜなら、インターネットは、人間がオンライン状態に関する動的な情報を宣伝したり、簡単なエンドポイントツーエンドポイントメッセージを交換するための標準や、広く導入されたメカニズムが欠如しているからである。
"バディリスト", "ピープルブラウザ", "ページャー", "同僚認識ツール" として知られているアプリケーションの急成長している分野は、これらの機能を提供することを目指している。しかしこれまでのところ、そうしたアプリケーションは専有のスキーム: ドキュメント化されていないプロトコル、閉じた名前空間、集中監視サービスセンターを使用している。
数多くの企業や個人は、"プレゼンス情報プロトコル", "PIP" という名前の、基本的なプレゼンスやメッセージング機能のための、オープンで相互作用可能な標準の採用に取り組み始めた。その取り組みは進行中であり、そのような標準が適合すべき要件を正式に列挙し、既存の技術や標準の適用性を調査し、この分野に焦点を絞った IETF 作業グループを開始した。
PIP/0.2 は率直で、協調可能な方法で "プレゼンス情報プロトコル" 要件を適えることに関する、あるアイデアのためのテストベッドとして設計されたデモンストレーションプロトコルである。この分野における以前の提案から抜き出すと、PIP/0.2 は以下を狙いとする。
PIP/0.2 は、特に以下を試みてはいない。
作者は、それぞれの企業によって独立して開発され、このプロトコルに基づいて相互動作するテストソフトウェアを実演することを意図しているが、PIP/0.2 ソフトウェアは実際の製品提供の示唆であると考えるべきではない。
PIP/0.2 は、クライアントとサーバ間の特定の責任分割を義務づけることなく、エンドユーザとエンドユーザの相互作用性を実演することを狙っている。特に、クライアントが外部のサーバに直接購読したり、内部のサーバを外部のサーバへのプロクシとして使用したり、その二つを混在させることを受け入れるべきである。外部サーバは、その購読が "実際に" クライアントからかのものか否かを気にすることはなく、いずれにせよ単に購読を管理し、通知を配送するだけなので、この融通性は可能である。
これを記述している時点では、このプロトコルの個々の実装が進行中であるが、完全な機能性と相互作用性はベンダー間試験ではまだ確認されていない。従って、更なる実装と試験から得られる教訓により、このプロトコルの規定がここで文書化されているものを超えて徐々に変わり続けるかもしれない。
人間やメッセージを送る手段を表現する資源は、URL によって識別される。これらの URL はプロトコル識別子 'pip' を持つ。例えば、"pip://pip.lotus.com/JR_Ewing" である。これらの URL はシステム主幹の識別と、メッセージが向けられるネットワーク所在地の記述の両方をまかなう。
アイデンティティ URL は、ある通信タスクが試みるデフォルト所在地の役割を持つ一方、しばしば代替の一時的 URL 所在地が代わりに使用される。例えば、人 "pip://pip.lotus.com/JR_Ewing" は実際には、彼が開始する如何なる購読も、それらの情報を "pip://dallas.xyz.lotus.com/" に配送することを要求し、彼に直ちにメッセージを送る試みは "pip://dallas.xyz.lotus.com/iibox" に向けることを要求する。
デモンストレーションプロトコルのこのバージョンでは、PIP URL は常に大文字小文字を区別しない。さもなくば、それらは RFC 1738 で記述されている URL "共通インターネットスキーム記法" に従う。
全てのメッセージは、HTTP/1.1 [HTTP/1.1] で確立された形式に従う。このデモプロトコルに従うメッセージのためのプロトコル識別子は、"PIP/0.2" を読まなければならない。
このデモプロトコルでは、全てのトランザクションはコネクションがクローズされる前に一つの要求と応答が完了する、短命の TCP ヒットを通じて可能だろう。
HTTP/1.1 スタイルのパイプライン化を実装してもよい。なぜなら、そのメカニズムはコネクションオープンを保持するために両側の同意を必要とするからである。パイプラインする幾つかのプログラムの追加された機能は、パイプラインできないプログラムに対して如何なる問題も引き起こすべきではない。
PIP/0.2 トランザクションのデフォルトポートは、321 [IANA] である。
要求行、応答行、ヘッダは、HTTP/1.1 に従って符号化しなければならない。PRESENCE 更新とインスタントメッセージの内容の文字符号化は、デフォルトで (セクション14 で定義されているように) UTF-8 (ユニコード) を想定している。他の符号化は、以下の例のように Content-type 中の "charset" 属性によって指定してもよい。
Content-Type: text/plain; charset="ISO-2022-JP"
SUBSCRIBE メソッドは、リモート資源に対する持続的な興味を表現するために使用され、その資源で発生する変更や、その資源で配送される通知を含む。もし SUBSCRIBE 要求が、'Subscription-ID' ヘッダを含むならば、既存の購読を更新するために使用され、'Renew-Duration' ヘッダも含むべきである。
SUBSCRIBE 要求は 'From' ヘッダを含むべきであり、それは購読を要求している主幹 (PIP URL によって) を識別する。'Sendback' ヘッダを含んでもよく、それはこの購読上で後続してもよい一連の NOTIFY を向けなければならない PIP 所在地を示す。SUBSCRIBE 要求は、'Duration' ヘッダを含んでもよく、それは通知や更新トラフィックが無い場合でも、購読者がその購読を持続したい時間の長さを示す。
SUBSCRIBE 要求が成功すると、201 Created 応答を生成する。それは、'Duration' ヘッダを含まなければならない。トラフィックが無い場合にどのくらい購読を持続するかを指示する。'Subscription-ID' ヘッダを含むかもしれない。。それは提供する資源においてユニークな名前を購読に付与する。応答内容はターゲット資源の現在可視の状態である。
UNSUBSCRIBE メソッドは、以前に確立した購読を終了する。それは、キャンセルする購読を識別するために 'Subscription-ID' を含まなければならない。それは、購読者によって送信されたものでも発行者によって送信されたものでも、どちらでもよい。
発行者からの UNSUBSCRIBE 要求は 'Location' ヘッダを含んでもよく、それは購読を試みる代わりの所在地を示す。そしてこの購読は終了する。(パート10 リダイレクション参照)
CHANGE メソッドは、与えられた資源に格納された内容を変更するために使用される。これは、その資源の購読者に NOTIFY を送信し、格納されたそのサーバの資源の内容に少なくとも一時的な変更をもたらす。
CHANGE 要求は 'Duration' ヘッダを含んでもよく、それは、現在の資源の持続値を置き換えずに、与えられた持続時間の間 'overlay' か 'lease' を代わりに提供することを示す。その時間が満了するまで、'lease value' が唯一の外部操作である。
資源に対して一回に一つの 'lease' のみ活性であってもよく、最も最近のものが常に優先される。同じ内容と置き換える CHANGE は、依然として NOTIFY を生成する。
NOTIFY メソッドは (1) 購読内の CHANGE を報告するために使用され、(2) 潜在的な受諾か遅延に対し、購読外で任意の内容を資源に配送するために使用され、(3) 購読内の CHANGE を中継するために使用される。
CHANGE を報告するために使用する時、NOTIFY は CHANGE される資源を示す 'From' ヘッダと 'Subscription-ID' ヘッダ、'value' の 'Notify-class' ヘッダ値が付いて、購読者の 'Sendback' 所在地に配送される。受信側は正しい購読上の NOTIFY の受信に対して、200 OK 応答で受信確認しなければならない。
任意の内容を資源に配送するために使用する時、NOTIFY 要求は、その通知を起動した主幹を示す 'From' ヘッダと 'transient' の値を持つ 'Notify-class' ヘッダを含むべきである。そのような NOTIFY は、'Subscription-ID' ヘッダを持ってはならない。もし NOTIFY が意味的に受諾されるか中継されるならば、200 OK 応答を生成しなければならない。もし今中継できないならば (例えば正しい資源の購読者が現在いない)、505 service unavailable 応答が適切である。
その資源に対する購読の中で、任意の内容の資源への配送を中継するために使用する時、NOTIFY 要求は 'Subscription-ID' と 'transient' の値を持つ 'Notify-class' ヘッダを含まなければならない。NOTIFY 指示の起動元によって提供される 'From' ヘッダは、'Origin' ヘッダで通知し、資源を中継者を示す新しい 'From' ヘッダを挿入しなければならない。受信側は (もしエラーが発生しなければ) その NOTIFY に、200 OK で肯定応答しなければならない。
購読内で発生した何かを通知する NOTIFY (つまり上記の (1) か (2) を意味) は、常に 'Subscription-ID' ヘッダを持ち、それを任意の内容を資源に配送する NOTIFY ((2) を意味) であるかのように扱ってはならない。従って、ある購読から来る NOTIFY や、特定の PIP 資源に行く NOTIFY は、中間資源の他の購読上に更なる NOTIFY を生成することはできない。
FETCH メソッドは、購読を開始せずに資源の現在の内容を取り込むために使用される。(それは本質的に HTTP の GET である。全ての GET ファシリティ、例えば 'If-Modified-Since' などをサポートしているという誤った印象を避けるために別の名前にしている)。
FETCH に対する正常応答は 200 OK 応答を使用し、その内容としてターゲットの資源の内容を含む。
PIP/0.2 は、適切である場合は常に HTTP/1.1の応答コードを再利用する。
404 Not Found 応答は、たとえリクエスト URI によって識別される資源を見つけられても、'Subscription-ID' を持つ要求が受信側で未知の購読を識別する時に適切である。
ソフトウェアは、エラーを生み出した要求をリトライしてもよいか否かを決定する時、HTTP/1.1 の取り決めに従うべきである。
412 Precondition Failed 応答は、ある未サポートな、あるいは現在不適切なヘッダが要求上に現れた時に使用される。これは、HTTP/1.1 での応答の意味と正確に同一ではない。
どんな HTTP/1.1 ヘッダも含めてよいが、ここにリスト化されているか説明されているものしか、PIP/0.2 相互動作プログラムに意味を持つことが保証されない。
Host
Location
User-Agent
Content-Type
Content-Length
整数の秒数。SUBSCRIBE 要求では購読期間を提案するために使用され、SUBSCRIBE 応答では購読期間を指示するために使用され、CHANGE 要求ではリース期間を提案するために使用され、CHANGE 応答ではリース期間を指示するために使用される。
整数の秒数で、既存のリースや購読を付与した時間に再更新することを要求するために、CHANGE 要求と SUBSCRIBE 要求で使用される。
要求か応答を起動した主幹/資源を識別する。ほぼどこにでも現われてよい。
元の 'From' が中継する資源の名前に置き換えられる時に、中継された NOTIFY の元の起動者を識別する。
購読中の通知に対して、購読者のデフォルトの識別所在地と異なる配送所在地を指定するために、SUBSCRIBE 要求で使用される。
発行資源において購読をユニークに識別するトークン。購読に後で参照する名前を与えるために、最初の SUBSCRIBE に対する応答で使用される。関心のある購読を識別するために、NOTIFY で使用される。再更新する購読を識別するために、再更新する SUBSCRIBE で使用される。
Subscription-ID は、HTTP/1.1 で定義された 'トークン' である。
CHANGE の通知を、中継する任意の内容の通知と区別するために、NOTIFY 要求で使用される。'value' か 'transient' の値を持ってもよい。
資源の主内容以外の何かに適用するメソッドを示すために使用してもよい。受諾できる値は "content" と "control" であり、もし省略されている場合は "content" の値 (デフォルト振る舞い) を意味する。もし "Regarding: control" を指定するヘッダが要求に現れ、その要求の受信側がリモート資源制御を供給しないならば、412 Precondition Failed 応答を返却するべきである。
"Regarding: control" が CHANGE に現れた時、それはその内容ではなく、資源の制御情報を変更する。(これは別箇所で説明されているように、後でその資源の振る舞いに影響する)。"Regarding: control" が FETCH に現れた時、返却される内容はその内容ではなく、与えられた資源の制御情報であるべきである。"Regarding: control" が SUBSCRIBE に現れた時、購読はその内容ではなく、制御情報の状態についての通知を承認すべきである。その購読上の NOTIFY もまた、"Regarding: control" ヘッダ行を持つべきである。
リースは、'Duration' ヘッダを持つ CHANGE 要求を資源に発行することによって確立される。要求に含まれる 'Duration' 値は、もしその応答が異なる 'Duration'を指示していなければ、リース期間を含む。唯一一つのリース (最も最近確立されたもの) のみが資源に 1 回存在する。
もしリースする値が設定されたら、それは資源の外部ビューアに唯一見える値である (例えば、SUBSCRIBE に対する正常応答の内容)。リース値が満了すると、たとえ復帰された持続値が満了したリース値と同じであっても、NOTIFY が生成される。
'Duration' ヘッダのない CHANGE は、資源の "永久の" バージョンを変更する。もし現在のリース実施されているならば、そのような永久の変更は、リースが満了するまで NOTIFY を生成しないかもしれない。
リースは、'Duration' 0 を持つ別のリースを発行することによってキャンセルしてもよい。リースの適切な使用法は、リースの保持者が、永久の値に戻ることが適切の場合はすぐに、'Duration' 0 を持つ CHANGE 要求で明示的にキャンセルすべきであることを指示する。リース保持者は、廃止した値を修正する意味としてリースの即座の満了に頼るべきではない。
リースは、'Renew-Duration' ヘッダを持つ CHANGE 要求を発行することによってリフレッシュしてもよい。その要求の内容は無視される。その要求に対する応答が異なる 'Duration' を指示していなければ、要求された生存期間は尊重される。更新が要求された時点で、もし何のリースも実施されていなければ、412 Precondition Failed 応答を返却すべきである。
購読は、SUBSCRIBE 要求で開始する。購読は、(1) 購読者からの 一致する UNSUBSCRIBE 要求、(2) 発行者によって購読者に配送された UNSUBSCRIBE 要求、(3) 購読上で正常な SUBSCRIBE か NOTIFY トラフィックが無く、最後の発行者指定の 'Duration' 値に相当する期間の経過、のいずれかにより明確に終了する。
その試み、あるいは 200 OK 応答を受信していない購読上で NOTIFY を配送する試みにより、発行者はその購読を破棄するかもしれないが、発行者は 'Duration' が別途満了するまで NOTIFY を配送する試みを継続すべきである。
リダイレクション (代替アドレスへの自動トランザクションの結果による 302 moved temporarily 応答) は、最初の SUBSCRIBE と FETCH でのみサポートされる。
もし最初の SUBSCRIBE に対する応答が 302 moved elsewhere 応答を含むならば、その SUBSCRIBE は、含まれている 'Location' ヘッダで提案された URL に試みなければならない。もし与えられた所在地で遂行され、代替所在地での購読が終了していないならば、元の所在地に再度試みる必要はない。
オンライン状態情報を共有するための共通形式は、よく形成された XML ドキュメントである。このドキュメントのルート要素は、'PRESENCE' という名前でなければならない。
もしこのデータによって表現されたユーザが、'オンライン' ならば、'PRESENCE' ルートは 'ONLINE' という名前の子要素を含まなければならない。もし表現されるユーザが 'オフライン' ならば、それは 'OFFLINE' という名前の要素を含んでもよい。('ONLINE' か 'OFFLINE' のいずれも表れない場合は、'OFFLINE' であると仮定される)。これらの要素は、如何なる内容も持つ必要はない。
以下の追加のプレゼンス情報の一部は、オプションである。クライアントは、判らない <PRESENCE> 内の情報は優しく無視すべきである。
'ONLINE' 要素は 'AWAY' か 'BUSY' のいずれかの名前の子要素を含んでもよい。それぞれ、'ONLINE' 端末の近くにいない (恐らくプログラムに基づいたアイドル感知から引き出される) か、邪魔されないことを望むと表明するかを示す。
'PRESENCE' ルートは 'NOTE' という名前の子要素を含んでもよい。内容は現在の状態に関するフリー形式のテキスト掲示である。
'PRESENT' ルートは 'NICKNAME' という名前の子要素を含んでもよい。内容はユーザインタフェースにおいてユーザが好む短い形式の象徴的な表現である。
例:
誰かがオフラインであることを示す最小限の正しいプレゼンスドキュメントは:
<PRESENCE />
誰かがオンラインであることを示す最小限の正しいプレゼンスドキュメントは:
<PRESENCE>
<ONLINE />
</PRESENCE>
全てのクライアントが理解する必要はないオプションのエンティティを使用した場合、以下は誰かがオンラインであるが、不在で "昼食中" であることを示す。
<PRESENCE>
<ONLINE>
<AWAY />
</ONLINE>
<NOTE>out to lunch</NOTE>
</PRESENCE>
アプリケーションは、URL 'X/iibox' ("インスタント受信箱" を表す) への NOTIFY を実行することによって、PIP URL 'X' で表現されるエンティティへのインスタント通信の送信を試みなければならない。すなわちメッセージを配送するための URL は、URL を購読するための取り決めを適用することによって確立される。もし非標準的な所在地にあるエンティティを購読するならば、そのメッセージ交換 URL は現在の購読所在地から取り込まなければならない。
NOTIFY は、'transient' の値を持つ 'Notify-class' ヘッダを含まなければならない。そのコンテントタイプは 'text/plain' か 'text/html' であってもよい。NOTIFY が送信されるその URL は、(1) 意図した受信者へのメッセージを直接表示できる所在地、(2) 意図した受信者が購読する所在地、のいずれかであることが期待される。それにより、NOTIFY は意図した受信側へのメッセージを直接表示できる最終宛先に効率的に中継される。
もしそのメッセージが、メッセージを "消費する" エンドポイントに適切に配送されたならば、その NOTIFY に対して 200 OK で応答しなければならない。もし NOTIFY を配送した所在地が、そのメッセージが適切に最終宛先に到達したと信じない、例えば主幹がその資源を購読していないサーバの '/iibox' 資源である、ならば、その NOTIFY に対して 505 Retry later などのエラーで応答しなければならない。
資源は CHANGE 要求を使用することによる全ての要求に対して、指定されたリモート資源に対してリダイレクション指示を確立するために、"Regarding: control" ヘッダを持つ 302 Moved Temporarily redirecting 応答を発行するよう設定してもよい。これらの指示は、ルートが 'REDIRECT' という名前で、その内容がリダイレクションによって提供される URL である、単一の要素を持つ XML ドキュメントによって提供すべきである。例えば、
<REDIRECT>pip://ws0013.activerse.com/</REDIRECT>
制御情報の変更は内容の変更同様、リースの適用を受けてもよい。資源に対する制御情報は、適切な 'Regarding' ヘッダを持つ FETCH か、適切な 'Regarding' ヘッダを持つ SUBSCRIBE による購読によって見えるかもしれない。
PIP アプリケーションは、メッセージの最終的な宛先についての情報を、Request-URI や 'Host' ヘッダに含めることによって、ローカルマシンを通じてメッセージを中継する、HTTP と同様のプロクシ戦略を採用してもよい。
しかし、プロクシされるメッセージを受信する最終宛先のプロセスは、特別にそれを扱う必要はなく、トラフィックがプロクシされているという注記を付けてもよい。そして、相互作用デモプログラムは自身の宛先でプロクシする実装を試みても試みなくてもよい。
プロクシの詳細例は、サンプルの写しに示されている。
セキュリティの問題は、このデモの目的とは明確に別に置かれている。最終的な標準は、ベンダ/セキュリティ領域 (HTTP 'Digest' パスワード認証との互換性への寄与に類似している) に渡って、認証する通信相手のために提案された低水準共通分母メカニズムだけでなく、互換ソフトウェア間の相互の同意によって上積みされた、より強い認証/暗号化メカニズムをも含む。
PIP URL "pip://pip.fujitsu.com/alice" を持つアリスについて考える。彼女は、自分のデスクトップマシン "aardvark.fujitsu.com" 上で PIP クライアントを起動する。そのマシンは、入力通信のためにローカルユーザポート 1321 を確保している。
何か行う前に、彼女は自分が世界でどのように見えるかを確認したいかもしれない。
[open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321]
out> FETCH /alice PIP/0.2
out> Host: pip.fujitsu.com
in< PIP/0.2 200 OK
in< Content-type: text/xml
in< Content-length: 12
in<
in< <PRESENCE />
[socket closes]
そして、彼女は世界にオンラインで表れたいと思う。しかし、ネットワークかクライアントにトラブルがある場合、彼女はこの状態をいつまでも持続したいと思わない。そこで、彼女は 20 秒のリースを要求する。
[open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321]
out> CHANGE /alice PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Duration: 20
out> Content-type: text/xml
out> Content-length: 34
out>
out> <PRESENCE>
out> <ONLINE />
out> </PRESENCE>
in< PIP/0.2 200 OK
in< Duration: 40
[socket closes]
サーバは、恐らく更新トラフィックの頻度を制限したいので、要求された 'Duration'値を上書きしていることに注意されたい。(もしサーバがアリスの資源向けの現在の購読を維持し続けていたら、彼女の CHANGE は沢山の NOTIFY を購読者に送る起因になる。例は後にある)。
アリスはさらにインスタントメッセージを受信したいと思う。PIP/0.2 の取り決めにより、彼女にメッセージを送りたい人は "pip://pip.fujitsu.com/alice/iibox" に NOTIFY を送信するだろう。そして、アリスはその所在地を購読し、中継されたメッセージを受信したいと思う。
[open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321]
out> SUBSCRIBE /alice/iibox PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Sendback: pip://aardvark.fujitsu.com:1321
out> Duration: 30
in< PIP/0.2 201 subscription created
in< Duration: 60
in< Subscription-ID: aaii
[socket closes]
アリスはその購読を認められ、代替の接続時間で再度購読する。多くの購読許可応答はターゲット資源の現在の内容を含んでもよいが、この購読応答は内容を持たない。
アリスはいつまでもオンラインにいる。そして、間もなく 40 秒の内容リースが満了し、彼女はリースの再更新を発行し、サーバはそれを承認する。
[open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321]
out> CHANGE /alice PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Renew-Duration: 40
in< PIP/0.2 200 renewed
in< Duration: 40
[socket closes]
60 秒間の 'iibox' 購読が間もなく満了すると、彼女はさらに再購読も発行する。
[open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321]
out> SUBSCRIBE /alice/iibox PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Subscription-ID: aaii
out> Renew-Duration: 60
in< PIP/0.2 200 renewed
in< Duration: 60
[socket closes]
これらの更新は、アリスがオンラインでメッセージ交換可能のままでいたいと望む限り継続される。その購読に対して配送され、購読者によって確認される NOTIFY は、最後に通知された 'Duration' に対して購読を再更新するのに役立つ。
アリスが最終的にオフラインになることを決定した時、彼女はリースした値と彼女のインスタント受信箱の購読の両方をキャンセルする。(これらの関係の最終的な満了に頼ることは推奨されない)。
[open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321]
out> CHANGE /alice PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Renew-Duration: 0
in< PIP/0.2 200 lease terminated
in< Duration: 0
[socket closes]
[open TCP from aardvark.fujitsu.com to pip.fujitsu.com:321]
out> UNSUBSCRIBE /alice/iibox PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Subscription-ID: aaii
in< PIP/0.2 200 cancelled
[socket closes]
アリスがオンラインであると仮定する。彼女は通常、彼女がそのオンライン状態に興味を抱く数多くの同僚を購読する。彼女は主にボブ (pip://pip.microsoft.com/bob) とカール (pip://pip.activerse.com/carl) に興味を持つと仮定しよう。彼女はボブを購読する。
[open TCP from aardvark.fujitsu.com to pip.microsoft.com:321]
out> SUBSCRIBE /bob PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Sendback: pip://aardvark.fujitsu.com:1321
out> Duration: 60
in< PIP/0.2 201 granted
in< Subscription-ID: a2b
in< Duration: 60
in< Content-type: text/xml
in< Content-length: 12
in<
in< <PRESENCE />
[socket closes]
そして、カールを購読する。
[open TCP from aardvark.fujitsu.com to pip.activerse.com:321]
out> SUBSCRIBE /carl PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Sendback: pip://aardvark.fujitsu.com:1321
out> Duration: 60
in< PIP/0.2 201 granted
in< Subscription-ID: a2c
in< Duration: 60
in< Content-type: text/xml
in< Content-length: 22
in<
in< <PRESENCE></PRESENCE>
[socket closes]
アリスは、自分のインスタント受信箱を購読したのと同様にこれらの購読を再更新する。
そして、ボブがオンラインに入った。彼はアリスが最初に変更したように CHANGE を発行する (例示はしない)。その結果、アリスは彼女が前に指定した 'Sendback' で以下の通知を受信する。
[open TCP from pip.microsoft.com to aardvark.fujitsu.com:1321]
out> NOTIFY / PIP/0.2
out> From: pip://pip.microsoft.com/bob
out> Subscription-ID: a2b
out> Notify-class: value
out> Content-type: text/xml
out> Content-length: 31
out>
out> <PRESENCE><ONLINE /></PRESENCE>
in< PIP/0.2 200 ok
[socket closes]
同様にもしオンラインのまましばらく経過した後、ボブが現在の活動が一見して分かる自由形式の注記を供給するオプションの <NOTE> 要素を追加したら、アリスは同様の通知を受信するだろう。
[open TCP from pip.microsoft.com to aardvark.fujitsu.com:1321]
out> NOTIFY / PIP/0.2
out> From: pip://pip.microsoft.com/bob
out> Subscription-ID: a2b
out> Notify-class: value
out> Content-type: text/xml
out> Content-length: 67
out>
out> <PRESENCE>
out> <ONLINE />
out> <NOTE>about to head home</NOTE>
out> </PRESENCE>
in< PIP/0.2 200 ok
[socket closes]
ボブが最終的にオフラインになる時、アリスは元の最小値に対して彼の状態を返却する通知を受信するだろう。もしアリスが最初にオフラインになるなら、彼女はもし可能ならば、以下のように明示的に自分の購読をキャンセルすべきである。
[open TCP from aardvark.fujitsu.com to pip.microsoft.com:321]
out> UNSUBSCRIBE /bob PIP/0.2
out> Host: pip.microsoft.com
out> From: pip://pip.fujitsu.com/alice
out> Subscription-ID: a2b
in< PIP/0.2 200 cancelled
[socket closes]
アリスとボブがオンラインにいてお互いに購読し、アリスはボブにメッセージを送信したいと思うと仮定する。彼女はボブのインスタンと受信箱向けの NOTIFY を生成することによってそれを行う。
[open TCP from aardvark.fujitsu.com to pip.microsoft.com:321]
out> NOTIFY /bob/iibox PIP/0.2
out> Host: pip.microsoft.com
out> From: pip://pip.fujitsu.com/alice
out> Notify-class: transient
out> Content-type: text/plain
out> Content-length: 42
out>
out> When do you arrive at the IETF conference?
ボブは、中継されたインスタントメッセージを受信するために、事前に "pip://pip.microsoft.com/bob/iibox" の資源を購読している (例示はしない)。(もし誰もこの資源を購読していなければ、アリスの上記のメッセージにより、例えば 505 Retry later 等のエラーが即座に生成されるだろう)。従って、アリスの NOTIFY は、ボブが直前の購読で指定した 'Sendback' 所在地に中継される。それは "pip://bear.microsoft.com:1321" であると仮定する。
[open TCP from pip.microsoft.com to bear.microsoft.com:1321]
out> NOTIFY / PIP/0.2
out> Origin: pip://pip.fujitsu.com/alice
out> From: pip://pip.microsoft.com/bob/iibox
out> Notify-class: transient
out> Subscription-ID: iibb
out> Content-type: text/plain
out> Content-length: 42
out>
out> When do you arrive at the IETF conference?
in< PIP/0.2 200 ok
[socket from pip.microsoft.com to bear.microsoft.com closes]
この正常購読配送により、アリスは最初の NOTIFY に対する応答として、彼女のメッセージの配送の確認を受信できる。
[on already-open socket from aardvark to pip.microsoft.com]
in< PIP/0.2 200 ok
[socket from aardvark.fujiotsu.com to pip.microsoft.com closes]
カールがオンラインになり、彼はいつオンラインなりいつオフラインになったかを、異なる所在地から発行するためにリダイレクションを使用できるクライアント/サーバを使用すると仮定する。彼は "pip://pip.activerse.com/carl" 資源の内容にリースせずに、その制御設定にリースを確立する。
[open TCP from cat.activerse.com to pip.activerse.com:321]
out> CHANGE /carl PIP/0.2
out> Host: pip.activerse.com
out> From: pip://pip.activerse.com/carl
out> Regarding: control
out> Duration: 30
out> Content-type: text/xml
out> Content-length: 49
out>
out> <REDIRECT>pip://cat.activerse.com:1321</REDIRECT>
in< PIP/0.2 200 OK
in< Duration: 30
[socket closes]
結果的に、この制御リースの間、カールの標準的な URL の将来の購読は "cat.activerse.com" にある彼の現在の所在地にリダイレクトされるだろう。アリスが "pip.activerse.com" をまだ購読していると仮定する。彼女の購読はサーバによってキャンセルされる。
それはアリスに購読をリトライさせるだろうが、その試みは承認されずリダイレクトされる。
[open TCP from aardvark.fujitsu.com to pip.activerse.com:321]
out> SUBSCRIBE /carl PIP/0.2
out> Host: pip.fujitsu.com
out> From: pip://pip.fujitsu.com/alice
out> Sendback: pip://aardvark.fujitsu.com:1321
out> Duration: 60
in< PIP/0.2 302 elsewhere
in< Location: pip://cat.activerse.com:1321
[socket closes]
そして、アリスはリダイレクトされた所在地でカールを購読する。
[open TCP from aardvark.fujitsu.com to cat.activerse.com:1321]
out> SUBSCRIBE / PIP/0.2
out> Host: cat.activerse.com
out> From: pip://pip.fujitsu.com/alice
out> Sendback: pip://aardvark.fujitsu.com:1321
out> Duration: 60
in< PIP/0.2 201 granted
in< Subscription-ID: a2cc
in< Duration: 60
in< Content-type: text/xml
in< Content-length: 32
in<
in< <PRESENCE><ONLINE /></PRESENCE>
[socket closes]
この購読上での将来の NOTIFY は、"cat.activerse.com" から "aardvark.fujitsu.com:1321" に直接向けられるだろう。もしアリスがインスタントメッセージをカールに送りたいと思うならば、彼女は現在のカール向けの購読に関係する NOTIFY を、"pip.activerse.com" にある URL を通じてではなく、"pip://cat.activerse.com:1321/iibox" に指示するだろう。
[HTTP/1.1]R. Fielding, J. Gettys, J. Mogul,
H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1":
http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-03.txt
[IANA]
IANA Protocol Numbers and Assignment Services, Port Numbers
http://www.isi.edu/in-notes/iana/assignments/port-numbers
Gordon Mohr Activerse, Inc. 1301 W. 25th St Suite 500 Austin, TX 78705 gojomo@activerse.com Sonu Aggarwal Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 sonuag@microsoft.com Mark Day Lotus Development Corporation 55 Cambridge Parkway Cambridge, MA 02142 Mark_Day@lotus.com Avshalom Houri Ubique Building 18/D, Science Park POB: 2523 Rehovot 76123, Israel avshalom@ubique.com Youji Kohda Fujitsu Laboratories Ltd. 64 Nishiwaki, Ohkubo-cho Akashi, 674-8555, Japan kohda@flab.fujitsu.co.jp Dave Marvit Fujitsu Labs America 595 Lawrence Expressway, Sunnyvale, CA 94086-3922 dave@marvit.org