http://www.xmpp.org/extensions/xep-0060.html の和訳

This specification defines an XMPP protocol extension for generic publish-subscribe functionality. The protocol enables XMPP entities to create nodes (topics) at a pubsub service and publish information at those nodes; an event notification (with or without payload) is then broadcasted to all entities that have subscribed to the node. Pubsub therefore adheres to the classic Observer design pattern and can serve as the foundation for a wide variety of applications, including news feeds, content syndication, rich presence, geolocation, workflow systems, network management systems, and any other application that requires event notifications.

この文書は一般 publish-subscribe 機能の為のXMPP拡張プロトコルを定義しま す。

注意: このプロトコルは XMPP Standards Foundation のドラフトスタンダード として定義されています。プロダクションシステムへの配置はこのプロトコル に適合した実装が推奨されます。しかし、最終スタンダードになる前であれば 多少の変更を行うことが可能です。

Document Information

シリーズ
XEP
番号
0060
公開元
XMPP Standards Foundation
状態
ドラフト
種類
Standards Track
バージョン
1.10
最終更新日
2007-09-26
Approving Body
XMPP Council
依存
XMPP Core, XEP-0004, XEP-0030, XEP-0068, XEP-0082, XEP-0131
Supersedes
None
Superseded By
None
短縮名
pubsub
XML Schema for pubsub namespace
<http://www.xmpp.org/schemas/pubsub.xsd>
XML Schema for pubsub#errors namespace
<http://www.xmpp.org/schemas/pubsub-errors.xsd>
XML Schema for pubsub#event namespace
<http://www.xmpp.org/schemas/pubsub-event.xsd>
XML Schema for pubsub#owner namespace
<http://www.xmpp.org/schemas/pubsub-owner.xsd>
Wikiページ
<http://wiki.jabber.org/index.php/Publish-Subscribe (XEP-0060)>

Author Information

Peter Millard
See Author Note
Peter Saint-Andre
JabberID: [xmpp:stpeter@jabber.org stpeter@jabber.org]
URI: https://stpeter.im/
Ralph Meijer
Email: ralphm@ik.nu
JabberID: ralphm@ik.nu

Legal Notices

Copyright
This XMPP Extension Protocol is copyright (c) 1999 - 2008 by the XMPP Standards Foundation (XSF).
Permissions
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
Disclaimer of Warranty
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##
Limitation of Liability
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
IPR Conformance
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).

Discussion Venue

Relation to XMPP

Conformance Terms

Contents


イントロダクション

概要

Jabber/XMPPテクノロジーが成熟した時、一般 publish-subscribe ("pubsub") メカニズムの必要性は複数のドメインから発生しました。これらは以下のもの を含みます(しかし制限はされません): ニュースフィードやコンテンツの独立 配信、拡張プレゼンス、アバター管理、共有ブックマーク、オークションやト レードシステム、オンラインカタログ、ワークフローシステム、ネットワーク 管理システム、NNTPゲートウェイ、プロフィール管理、イベント通知。

全てのドメインに置いて次のような古典的な「publish-subscribe」や 「observer」デザインパターン(人間かアプリケーションによる情報の配信)は データ通信として望ましく、そして許可された購読者へのブロードキャストイ ベント通知(ペイロードの有無にかかわらず)を行います。一般的に配信者と購 読者との関係は配信要求を受け取るサービスや購読者へのブロードキャストイ ベント通知やリストを管理する為の権限の有効な人間か権限のあるアプリケー ションによって仲介されます。

大抵の pubsub サービスでの配信と購読の焦点は「トピック」や「ノード」

In most pubsub services, the focal point for publication and subscription is a "topic" or "node" to which publishers send data and from which subscribers receive notifications.

さらに、幾つかのノードはイベントの履歴を管理したり純粋な pubsub モデル を補完した他のサービスを提供することも出来ます。

このドキュメントは単独で密で全ての pubsub のフォームで使用出来る一般プ ロトコルを定義します。

While compliant implementations are not required to implement all of the features defined herein, this document addresses most use cases that may be requested of a pubsub service. (For information about which features are required and which are recommended or optional, consult the Feature Summary.) Other specifications may define "subsets" or "profiles" of publish-subscribe for use in specialized contexts, but such profiles are out of scope for this document.

How It Works

この仕様は大きいです、しかし pubsub の背後にある基本的なアイディアはと てもシンプルです。(see Publish an Item to a Node)

  1. 公開情報の実体を publish-subscribe サービスのノードへ送ります
  2. pubsub サービスはその公開情報を知ることを許可されたエンティティへ送信します。

恐らく、最も pubsub に似たコンテンツ配信機能を持ったアプリケーションは ブログやニュースサイト、その他のインターネットで頻繁に更新される情報に 有効でよく知られるようになった RSS と Atom(RFC 4287) フィードです。 <hamlet@denmark.lit> さんがブログを配信する例を考えてみましょう。 Hamlet さんが新しいブログのエントリを書く時、ブログソフトウェアは <pubsub.shakespeare.lit> でホストする pubsub ノードへ配信を行います。

例1. Publisher Publishes a New Weblog Entry 

<iq type='set'
    from='hamlet@denmark.lit/blogbot'
    to='pubsub.shakespeare.lit'
    id='pub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='princely_musings'>
      <item>
        <entry xmlns='http://www.w3.org/2005/Atom'>
          <title>Soliloquy</title>
          <summary>
To be, or not to be: that is the question:
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?
          </summary>
          <link rel='alternate' type='text/html'
                href='http://denmark.lit/2003/12/13/atom03'/>
          <id>tag:denmark.lit,2003:entry-32397</id>
          <published>2003-12-13T18:30:02Z</published>
          <updated>2003-12-13T18:30:02Z</updated>
        </entry>
      </item>
    </publish>
  </pubsub>
</iq>

つまりこれが publish-subscribe の "pub" の部分です。

この時 pubsub サービスは全ての購読者に新しいブログエントリを通知します。

例2. Service Notifies Subscribers 

<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='princely_musings'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
        [ ... ENTRY ... ]
      </item>
    </items>
  </event>
</message>

<message from='pubsub.shakespeare.lit' to='bernardo@denmark.lit' id='bar'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='princely_musings'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
        [ ... ENTRY ... ]
      </item>
    </items>
  </event>
</message>

<message from='pubsub.shakespeare.lit' to='horatio@denmark.lit' id='baz'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='princely_musings'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
        [ ... ENTRY ... ]
      </item>
    </items>
  </event>
</message>

<message from='pubsub.shakespeare.lit' to='bard@shakespeare.lit' id='fez'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='princely_musings'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
        [ ... ENTRY ... ]
      </item>
    </items>
  </event>
</message>

これは一時的なノードが本文のない通知だけを行う簡単なサンプルです。

例3. A Transient Notification 

<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='elsinore/doorbell'/>
  </event>
</message>

もちろん、これに関連した実体で全ての pubsub 機能を有効する為にはその他 のユースケースを完全にする必要があるかもしれません。たとえば、配信者は ノードを作成するが必要になるかもしれません(see Create a Node)、そして購 読者は通知の為にサインアップする必要があるかもしれません(see Subscribe to a Node)。これらのユースケースはドキュメントの残りの部分で全て記載さ れています。(どの機能が必須で、どの機能が推奨か任意であるといった情報は Feature Summary を参考にして下さい。)

Glossary

以下の用語はこのドキュメントの中で使用される pubsub サービスのコンテキ ストに登場する要素、オブジェクト、動作を参照するために使用します。(ノー ト: これらの用語の幾つかはこのドキュメントの本文の中でより詳しく定義さ れています。)

テーブル 1: Publish-Subscribe 用語

権限アクセスモデル
購読要求がノードの所有者によって許可された場合にのみエンティティが購読することが出来るノードアクセスモデル(購読要求は一時的に受け入れられます)そして購読者のみがアイテムを取得することが出来るでしょう。
アドレス
(1) XMPP Core で定義された JID[2], or (2) JID の集まりとサービスディスカバリー [3] ノード.
コレクションノード
ノードや他のコレクションを含んでいますが公開アイテムは含んでいないノードの一種。コレクションは階層ノード構造を表現することが出来ます。
エンティティ
JIDアドレス化された Jabber エンティティ(クライアント、サービス、アプリケーション、など。)
イベント
ノードの状態の変化
インスタントノード
ノードID が pubsubサービスによって自動的に生成されたノード
アイテム
公開されたノードの XML断片、それによってイベントが生成されます。
アイテムID
固有ノードのコンテキストにあるアイテムのユーニークな識別子。
末端ノード
公開されたアイテムのみを含むノードタイプ。それは他のノードを含みません。
ノード
情報を公開することが出来、イベント通知やペイロードを受信することが出来る架空の場所(他の pubsubシステムにおいて、これは "トピック" と呼ばれるかもしれません)。
ノードID
pubsubサービスに関するノードのためのユニークな識別子。ノードIDはノード作成者によって与えられるか pubsub サービスによって生成されます(ノード生成者がインスタントノードをリクエストする場合)。ノードIDはセマンティックな意味を持つかもしれませんがそのような意味は任意です。
通知
イベントの加入者に知らせるためのメッセージの送信。
追放
購読やノードへの公開を禁止されたエンティティ。
オーナー
ノードの管理者、一つ以上あるかもしれません。ノード生成者であるとは限りません。
ペイロード
イベント通知自身、というよりもイベントに関連した全てのデータ。
オープンアクセスモデル
どのエンティティでも承認なしで購読したりアイテムを読み出すことの出来るノードアクセスモデル。
Personal Eventing
インスタントメッセージングとプレゼンスアプリケーションに関する Publish-Subscribe の単純なサブセット、それによって各 IMユーザーの JID は仮想の pubsubサービスです。詳細は Personal Eventing via Pubsub [4]を見て下さい。
プレゼンスアクセスモデル
所有者のプレゼンスを購読タイプ "from" か "both" (see RFC 3921 [5])で購読しているエンティティがノードを購読したりノードからアイテムを取得することが出来るノードアクセスモデルです。このアクセスモデルは主にインスタントメッセージングシステムに適用されます。
公開者
アイテムをノードへ公開することを許可されたエンティティ。
Pubsubサービス
XMPP サーバー、あるいはここに定義されるプロトコル付随するコンポーネント。
ロースターアクセスモデル
所有者のプレゼンスとロスターグループに定義されたエンティティがノードを購読したりノードからアイテムを取得することが出来るノードアクセスモデルです。このアクセスモデルは主にインスタントメッセージングシステムに適用されます。
購読者
ノードを購読しているエンティティ。
ホワイトリストアクセスモデル
ノードの所有者によって明示的に許可されているエンティティのみ購読やアイテムを取得することが出来るアクセスモデル(許可されていないエンティティからの購読申請は拒否されます)。

Requirements

pubsub サービスの要件は他のコンポーネントや使用出来るサービスの要求だけ でなくエンドユーザーの要求などによって決定されます。 まず最初に、Jabber を使用して実装された pubsub サービスが提供しなければ ならない基本的な機能は

幾つかの使用可能な Jabberベースのpubsubサービスは他の機能を必要とするで しょう、しかしこれらの機能は任意の為、仕様に準拠する為の義務ではありま せん。しかしながらもしこれらの機能が実装されている場合、ここに記載する プロトコルの詳細に忠実に従うべきです。その機能は以下の通り:

Preliminaries

Entity Use Cases

このセクションでは publish-subscribe との連携を望む任意のエンティティが使用するユースケースとプロトコルを定義します、主にサービスディスカバリーのユースケースが焦点です。

ディスカバー機能

Subscriber Use Cases

Retrieved from "http://www.cuspy.org/wiki/XEP-0060"