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

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


Assuming that something like the proposed changes that I described in
yesterday's mail are accepted, we need to flesh out disco support for the
pubsub service itself as well as for the two kinds of nodes that are
supported. (I.e. topic and subscription) Your comments on the following
would be very welcome. 

First, we should support a disco#info request that returns information about
our server. (Support for this request is mentioned, but not shown, in the
current draft of JEP-0060...)

Example 1: Client Requests Info on the service

<iq type='get'
    from='bobwyman_at_pubsub_dot_com at pubsub.com'
    to='xmpp.pubsub.com'
    id='info1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
    
Example 2: Server returns requested info

<iq type='result'
    from='xmpp.pubsub.com'
    to='bobwyman_at_pubsub_dot_com at pubsub.com'
    id='info1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='pubsub'
        type='generic'
        name='PubSub Concepts PubSub Server'/>
    <feature var='http://jabber.org/protocol/disco#info'/>
    <feature var='http://jabber.org/protocol/disco#items'/>
    <feature var='http://jabber.org/protocol/pubsub/'>
  </query>
</iq>
* Is the feature list correct for a server that *only* supports JEP-0060?
* Do we need to list the SHIM namespace?
* Should we create a feature to say that we support subscription ids and
thus content-based subscriptions? (something like:
 http://jabber.org/protocol/pubsub#content-based)

Clients will discover topic and subscription nodes in various ways. These
include:
	* Walking through node hierarchies using disco
	* Getting subIDs in response to <subscribe> operations
	* Getting references to topic nodes and subIDs in messages
	* In responses to requests for current affliations

Example 3: Client requests info on a topic node

<iq type='get'
    from='bobwyman_at_pubsub_dot_com at pubsub.com'
    to='xmpp.pubsub.com'
    id='info3'>
  <query xmlns='http://jabber.org/protocol/disco#info' 
         node='pubsub/topics/101'/>
</iq>
    
Example 4: Server responds with topic info

<iq type='result'
    from='xmpp.pubsub.com'
    to='bobwyman_at_pubsub_dot_com at pubsub.com'
    id='info3'>
  <query xmlns='http://jabber.org/protocol/disco#info' 
         node='pubsub/topics/101'/>
    <identity
        category='pubsub'
        type='topic'
        name='The title of the topic'/>
        <x xmlns="jabber:x:data" type="result">
          <field var="FORM_TYPE" type="hidden">
            <value>http://jabber.org/protocol/pubsub#node_meta_info
            </value>
          </field>
          <field var="creator">
            <value>pubsub at pubsub.com</value>
          </field>
          <field var="description">
            <value>This topic carries items extracted from RSS and Atom
                   Feeds</value>
          </field>
        </x>
  </query>
</iq>
* Note: More fields may be returned. I'm just showing a minimal set here.
Additional fields might include:
  a) The URI of the schema for data in this topic.
  b) The URI of a default XSLT that can be used to format
     messages from this topic.
  c) Dates of creation, publishers, email addresses for DMCA 
     complaints, etc.
  d) PICS data describing the content of the topic (PICS = Platform
     for Internet Content Selection)
* Notice in the identity that category=pubsub and "type=topic" I believe
that this identity should be registered in
 http://www.jabber.org/registrar/disco-categories.html . A "topic" is a node
that can be subscribed to.

Example 5: If the topic doesn't exist

<iq type='error'
    from='xmpp.pubsub.com'
    to='bobwyman_at_pubsub_dot_com at pubsub.com'
    id='info3'>
  <query xmlns='http://jabber.org/protocol/disco#info' 
         node='pubsub/topics/101'/>
  <error type='modify'>
    <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

Clients will also need to be able to get information about nodes which are
subIDs and identify subscriptions:

Example 6: Client requests info on a subscription node

<iq type='get'
    from='bobwyman_at_pubsub_dot_com at pubsub.com'
    to='xmpp.pubsub.com'
    id='info3'>
  <query xmlns='http://jabber.org/protocol/disco#info' 
         node='pubsub/sub/111111111'/>
</iq>
    
Example 7: Server responds with subscription info

<iq type='result'
    from='xmpp.pubsub.com'
    to='bobwyman_at_pubsub_dot_com at pubsub.com'
    id='info3'>
  <query xmlns='http://jabber.org/protocol/disco#info' 
         node='pubsub/sub/111111111'/>
    <identity
        category='pubsub'
        type='subscription'
        name='Mentions of Jabber or XMPP'/>
        <x xmlns="jabber:x:data" type="result">
          <field var="FORM_TYPE" type="hidden">
            <value> http://jabber.org/protocol/pubsub#sub_meta_info
            </value>
          </field>
          <field var="topic">
            <value>pubsub/topics/101</value>
          </field>
          <field var="query-string">
            <value>Jabber OR XMPP</value>
          </field>
         <field var="xmlLink" type="fixed">
<value>http://rss.pubsub.com/22/b7/d1e9845b330137935cf3384bd7.xml</value>
          </field>
        </x>
  </query>
</iq>
* As before, only a minimal set of fields are illustrated. Additional fields
might include:
  a) Date subscription was created.
  b) Date subscription will expire (if a lease style is being used)
  c) Info concerning any "rate throttling" controls (i.e. don't send more
than X messages per hour)
* Note: I am using http://jabber.org/protocol/pubsub#sub_meta_info for this
information. This is an addition to JEP-0060. The old version didn't need it
since subscriptions didn't have any meta_info in the old version. Now they
do.
* Note the use of identity "category=pubsub" and "type=subscription" I
believe this needs to be registered in 
 http://www.jabber.org/registrar/disco-categories.html. A subscription is a
node that is returned as the result of a <subscribe> operation on a topic
node.

	As always, your comments are encouraged and welcomed.

		bob wyman





More information about the Standards mailing list