[Standards-JIG] RE: JEP-0060 PubSub support for disco#info (service, topic, and subscription)

Bob Wyman bob at wyman.us
Thu Jun 17 17:15:03 UTC 2004

My previous mail on this subject was incomplete. When a server responds to a
disco#info request on a node, it should report back the <feature/>s that are
supported by the node. For a pubsub topic node, these features would
include, at least, the ability to subscribe/unsubscribe as well as the
disco#items feature if the node supported drill-down. Thus, my "Example 4"
from last night's mail should be modified to read:

Example 4: Server responds with topic info

<iq type='result'
    to='bobwyman_at_pubsub_dot_com at pubsub.com'
  <query xmlns='http://jabber.org/protocol/disco#info' 
        name='The title of the topic'/>
        <feature var='http://jabber.org/protocol/pubsub#subscribe'/>
        <feature var='http://jabber.org/protocol/disco#items'/>
        <x xmlns="jabber:x:data" type="result">
          <field var="FORM_TYPE" type="hidden">
          <field var="creator">
            <value>pubsub at pubsub.com</value>
          <field var="description">
            <value>This topic carries items extracted from RSS and Atom
*NOTE: The disco#items feature would only be advertised if the node did, in
fact, support the feature. Also, as noted in JEP-0030, the response to a
disco#items request should *not* return a "large" number of items (where
large is defined as more than 20.) Implementations that support a "large"
number of items for a node should provide support for Jabber Search
(JEP-0055) and thus would probably also advertise the 'jabber:iq:search'

	Also, please note that a subscription node would *not* advertise the
pubsub#subscribe feature since you can't subscribe to a subscription (at
least not in the PubSub.com implementation...). You can only subscribe to
nodes which are topics.
	Some may argue that you should be able to subscribe to
subscriptions. Those who make this argument are probably thinking of systems
in which you would have a source topic that was filtered first by one
subscription and then later by another subscription. The logical effect of
doing such "chaining" of subscriptions would be much the same as taking two
Boolean filters and combining them with an "AND" conjunction. The
difference, however, would be that by chaining subscriptions you would be
able to see the results returned by each filter -- in some applications,
this might be useful. However, it is a fairly "exotic" usage which has
potentially very significant implications for implementations, throughput,
system complexity, etc. and thus should not be considered a "normal" thing
to do. The best policy is to assume that you simply can't subscribe to a

		bob wyman

More information about the Standards mailing list