[Standards-JIG] JEP-0060: Current discussions re subID, Subscription Options, and SHIM use in PubSub Messages

Bob Wyman bob at wyman.us
Wed Jun 16 03:01:01 UTC 2004


            In the last few days, there have been quite a number of
discussions off-list concerning the need for a subscription identifier to
enable the use of JEP-0060 in content-based publish/subscribe applications
as well as to address a number of issues with topic-based applications. As I
understand it, the current consensus is that subid's are a good thing and
Peter Millard says that he is currently drafting the appropriate extensions
to JEP-0060 in order to provide the required support. At Peter's request,
I'm summarizing here what I think we've discussed so far. Your comments are,
of course, very welcome.

            In addition to the discussion of subId's we've also discussed
the need to extend the current subscription support to provide support for
options and for the use of SHIM (JEP-0131) to add subids to JEP-0060
messages.

            In the examples below, I'm taking the basic examples from
JEP-0060 and modifying them to show what I think the new draft may show as
well as to show how we at PubSub.com think we'll be using the new support.

 

            It is assumed that support for subscription id's is optional.
Servers that support subscription ids should report support for this feature
in the normal ways.


8.1.4 Subscribe to a node 


Example 25. Entity subscribes to a node

<iq type="set"
    from="sub1 at foo.com/home"
    to="pubsub.jabber.org"
    id="sub1">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <subscribe
        node="pubsub/topics/weblogs"
        jid="sub1 at foo.com">

      <options>

        <x xmlns="jabber:x:data" type="submit">

          <field var="FORM_TYPE" type="hidden">

 
<value>http://jabber.org/protocol/pubsub#subscribe_options</value>

          </field>

          <field var="title">

            <value>Mentions of RSS at PubSub.</value>

          </field>

          <field var="query-string">

            <value>(SOURCE:pubsub.com AND "RSS")</value>

          </field>

        </x>

      </options>

    </subscribe>
  </pubsub>
</iq>
*                It is assumed in this example that the subscription request
may generate a new and unique subscription even if the subscribing jid
already has a subscription to the same node. This is a change the policy
stated in section 8.1.4 of the current JEP-0060 which states that "If a
pubsub server receives a subscription request and the requestor already has
a subscription to that node, the server SHOULD return the current
subscription state (as if the subscription was just approved)." The existing
constraint would, however, remain in place for servers that do not support
subscription ids.
*                The subscriber can now specify <options> as part of the
original subscription rather than having to wait until after receiving the
subscription in order to set the options. This is particularly useful in the
case of content-based subscriptions where the specification of the query or
content-filter is *always* a requirement of establishing a subscription.
Allowing the provision of options in this way permits client code to be
simplified and saves a few network round-trips.
*                Supporting <options> in the initial subscription implies a
modification to the subscription approval process (if approvals are
required) since it now becomes possible for the approver to take into
consideration the elements specified in the options form when making an
approval decision. In some cases, these options will be critical to the
approval process. One might imagine, for instance, that approvals would be
dependent on the provision of some billing information as part of the
subscription request. Or, in a content-based system, the approver might
disapprove subscriptions whose content-filters are poorly formed and are
certain to generate an excessive number of messages.

Example 26. Server replies with success

<iq type="result"
    from="pubsub.jabber.org"
    to="sub1 at foo.com/home"
    id="sub1">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <entity node="pubsub/topics/weblogs"
            subid="pubsub/subs/12121212"
            jid="sub1 at foo.com"
            affiliation="none"
            subscription="subscribed">

      <options>

        <x xmlns="jabber:x:data" type="result">

          <field var="FORM_TYPE" type="hidden">

 
<value>http://jabber.org/protocol/pubsub#subscribe_options</value>

          </field>

          <field var="title">

            <value>Mentions of RSS at PubSub.</value>

          </field>

          <field var="query-string">

            <value>(SOURCE:pubsub.com AND "RSS")</value>

          </field>

          <field var="xmlLink" type="fixed">

 
<value>http://rss.pubsub.com/22/b7/d1e9845b330137935cf3384bd7.xml</value>

          </field>

        </x>

      </options>

    </entity>
  </pubsub>
</iq>
*                The server now returns a subid as part of the entity
element in the response.
*                Note that the PubSub server has returned a form field,
"xmlLink", that was not specified in the submitted form. This field is
"fixed" (i.e. cannot be modified by the user). We will be using this field
to provide the client/user with the URI of an RSS or Atom file that will
contain persisted entries that satisfy the subscription. We don't anticipate
providing support for item persistence in our JEP-0060 server initially.

Example 27. Entity is not authorized to create a subscription

<iq type="error"
    from="pubsub.jabber.org"
    to="sub1 at foo.com/home"
    id="sub1">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <subscribe
        node="pubsub/topics/101"
        jid="sub1 at foo.com"/>
  </pubsub>
  <error code="401" type="auth">
    <not-authorized xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
  </error>
</iq>
*                The handling of subscription errors is not changed from
what's in the current JEP.

8.1.7 Unsubscribe from a node 


Example 42. Entity unsubscribes from a node

<iq type="set"
    from="sub1 at foo.com"
    to="pubsub.jabber.org"
    id="unsub1">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
     <unsubscribe
         node="pubsub/topics/101"
         subid="pubsub/subs/1111111"
         jid="sub1 at foo.com"/>
  </pubsub>
</iq>
*                The only change to the "unsubscribe" syntax is the
requirement that a subid be included to specify which of potentially many
subscriptions is to be cancelled by this action.
*                We discussed the possibility that "unsubscribing" from a
node without specifying a subid might be taken to mean that all current
subscriptions should be cancelled, however, this is still subject to
discussion. (Note: supporting such a "wildcard" unsubscribe could be very
dangerous.)

Example 43. Server replies with success

<iq type="result"
    from="pubsub.jabber.org"
    to="sub1 at foo.com"
    id="unsub1"/>
*                The unsubscribe "success" message is unchanged.
*                NOTE: JEP-0060 currently provides for sending messages to
announce when nodes have been deleted, however, it does not provide for
notification of a successful "unsubscribe" operation. I believe that we
should, in fact, support such a notification since there are times when it
will be important for multiple resources to be kept in synch concerning each
other's subscriptions.

8.1.6 Request current affiliations 


Example 40. Entity requests all current affiliations

<iq type="get"
    from="sub1 at foo.com"
    to="pubsub.jabber.org"
    id="allsubs">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <affiliations/>
  </pubsub>
</iq>
*                The process of requesting current affiliations is not
modified - however, the response to the request *is* modified. (see below)

Example 41. Service replies with all current affiliations

<iq type="result"
    from="pubsub.jabber.org"
    to="sub1 at foo.com"
    id="allsubs">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <affiliations>
      <entity node="pubsub/topics/101"
              subid="pubsub/subs/1111111"
              jid="sub1 at foo.com"
              affiliation="none"
              subscription="subscribed"/>
      <entity node="pubsub/topics/101"
              subid="pubsub/subs/22222"
              jid="sub1 at foo.com"
              affiliation="none"
              subscription="subscribed"/>
      <entity node="node3"
              subid="pubsub/subs/33333"
              jid="sub1 at foo.com/pda"
              affiliation="none"
              subscription="subscribed"/>
    </affiliations>
  </pubsub>
</iq>
*                The example shows that the jid "sub1 at foo.com" has three
subscriptions to the node "pubsub/topics/101". An entity is returned for
each subscription.

8.1.2 Publish an item to a node 

               The process of creating nodes, publishing, etc. is unchanged
from what's in the current JEP. The reason is that you can only publish to a
node; you can't publish to a subscription. Similarly, node creation is
something that typically happens before subscriptions can be created. Thus,
adding support for subscriptions only impacts subscribers, not publishers.
Implementations may, of course, choose to provide support for a number of
options at node creation time that might impact subscription or the
subscription approval process (if used).
               While the process of publishing is not changed, the results
of publishing (i.e. the messages delivered to subscribers) are changed:

Example 15. Subscribers receive event notifications with payloads

<message to="subscriber1" from="pubsub.jabber.org">
  <event xmlns="http://jabber.org/protocol/pubsub#event">
    <items node="pubsub/topics/101">
      <item id="current">

        <headers xmlns='http://jabber.org/protocol/shim'>

          <header name='subid'>pubsub/subs/1111111111</header>

          <header name='subid'>pubsub/subs/2222222222</header>

        </headers>

        <pubsub-message xmlns="http://www.pubsub.com/xmlns">

          . Message content goes here. . .

        </pubsub-message>

      </item>
    </items>
  </event>
</message>
*                SHIM (JEP-0131) headers are used to identify the
subscriptions that each published item satisfies. If more than one
subscription is satisfied, then more than one subid header will be provided
in each item. Any limitation on the maximum number of subids that might be
specified for a single message are implementation specific.

8.1.9 Get items for a node 

For those implementations that support persistence, it will now be important
to permit the retrieval of items for a "subscription" rather than just for a
node. Thus, the following need be supported:

Example 54. Subscriber requests all active items

<iq type="get"
    from="pgm at jabber.org"
    to="pubsub.jabber.org"
    id="items1">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <items node="pubsub/topics/101"
           subid="pubsub/subs/1111111"/>
  </pubsub>
</iq>
*                The key change is the inclusion of the subid.
*                Implementations that support subid should be permitted to
deny support for retrieving items from nodes without the specification of a
subid.

Example 55. Server sends items back

<iq type="result"
    from="pubsub.jabber.org"
    id="items1">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <items node="generic/pgm-mp3-player">
      <item id="item1">

        <headers xmlns='http://jabber.org/protocol/shim'>

          <header name='subid'>pubsub/subs/1111111</header>

        </headers>

        <pubsub-message xmlns="http://www.pubsub.com/xmlns">

          . Message content goes here. . .

        </pubsub-message>

      </item>
      <item id="item2">

        <headers xmlns='http://jabber.org/protocol/shim'>

          <header name='subid'>pubsub/subs/1111111</header>

        </headers>

        <pubsub-message xmlns="http://www.pubsub.com/xmlns">

          . Message content goes here. . .

        </pubsub-message>

      </item>
    </items>
  </pubsub>
</iq>
*                As with published messages, the individual items that are
returned would include SHIM subid headers to identify their association with
the subscription.

Example 56. Service does not support persistent items

<iq type="error"
    from="pubsub.jabber.org"
    id="items1">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <items node="pubsub/topics/101"/>
  </pubsub>
  <error code="501" type="cancel">
    <feature-not-implemented xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
    <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas">
      Persistent items not implemented
    </text>
  </error>
</iq>
 
*                This does not change.
 
Well, that should give you a reasonable overview of what we're talking
about. Please take a moment to review this proposal and please comment if
you have suggestions on how to improve it.
 
               bob wyman
 



More information about the Standards mailing list