[Standards-JIG] JEP-0060: Adjustments for content-based subscriptions

Bob Wyman bob at wyman.us
Sun Jun 13 17:22:41 UTC 2004

Ralph Meijer wrote:
> see http://ralphm.net/blog/2004/06/13/pubsub.com_xmpp
	Thanks for taking the time to read and evaluate my comments of
yesterday! Some comments follow:
	You propose that a method not defined in JEP-0060 be used to create
content-based subscriptions. While the method you propose, which relies on
the general mechanism of retrieving and submitting Data Forms, might work, I
have a number of concerns:
	1) If JEP-0060 is to describe the common publish and subscribe
protocol for Jabber, I think it is reasonable to expect it to handle at
least the two most common forms of pubsub (i.e. both topic-based and
content-based.) Your proposal would have us treat content-based pubsub as a
special case not handled by JEP-0060. If this is really necessary, then I
would propose that JEP-0060 be renamed to "topic-based pubsub" since it
clearly wouldn't be providing support for the broad-field of pubsub. 
	But, if the Jabber community and architects think that a specific
<subscribe> protocol is the correct way to create topic-based subscriptions,
I can't see why something similar wouldn't be correct for content-based
	2) You propose that the subscription form be retrieved by sending an
IQ query in the "jabber:iq:search" namespace to the JID of the pubsub
service. This is much less powerful and flexible than what JEP-0060
provides. For instance:
	* Since JEP-0060's mechanism (shown in Example 48) is specific to
pubsub and to option retrieval, it is much more expressive of the client's
intent. In your proposal, it simply isn't clear what the client is
attempting to search for.
	* The JEP-0060 mechanism provides that both JID and Node be
specified when requesting subscription options. This allows for
node-specific option forms to be generated. This capability to create node
or topic specific subscription forms is very important to us at PubSub.com
since the data required for subscriptions varies on a node-by-node basis.
For instance, topics have associated with them the schema that will be used
to publish data through the topic as well as distinct schemas for
subscribing. Also, there is sometimes a requirement to provide payment or
other proofs that are required for gaining access to a topic. While all
topics will share a common set of base subscription options, there will be a
great deal of variety in the options that each topic supports.
	To have this capability, we would have to extend your proposal. But,
why not just use what JEP-0060 provides?
	3) JEP-0060 provides a framework for subscriptions that includes
things like support for deferred approval of subscriptions, creating topic
specific outcasts, denying subscriptions, retrieval of pending
subscriptions, etc. We would have to recreate all these mechanisms if we did
something other than JEP-0060. That doesn't seem reasonable.
	4) As most protocols do, it is likely that JEP-0060 will be modified
in the future to address needs discovered as experience with it is gained.
If we implement a non-JEP-0060 approach for content-based subscriptions,
we'll find that support for such subscriptions may "fall-behind" that
provided for topic-based subscriptions and that new designs need to be
created to "catch-up" or otherwise benefit from the learning done by the
topic-based users. Synchronization between the two styles of use will be
made more difficult as we have multiple documents with different review
cycles. This approach introduces a great risk of divergence in the
	5) If content-based subscriptions require a different subscription
mechanism than topic-based subscriptions, we'll find that it is more complex
for clients and servers to support *both* styles of subscriptions in a
single implementation or application.
	6) We will insist that for most of our topics, users *must* define
an option "query-string" that restricts what they will receive. Thus, we
will not support topic-based subscriptions on some topics. If the mechanisms
are different between the two styles of subscription, this would imply that
we should probably not allow many of our topics to be visible as nodes using
the normal JEP-0060 node discover mechanisms. Thus, we would have to define
and provide non-JEP-0060 mechanisms for discovering the topics which support
content-based subscriptions.
	7) I believe that the proposal I have made calls for relatively
minor changes to the existing JEP-0060. Basically, all my proposal calls for
is support for a subscription-id... While the proposal touches a large part
of the spec, the incremental work to support subscription-id seems
reasonably minor in any one area. 

	Additional comments will come in later messages.

		bob wyman

More information about the Standards mailing list