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

Ralph Meijer jabber.org at ralphm.ik.nu
Wed Jun 16 19:55:40 UTC 2004

On Tue, Jun 15, 2004 at 11:01:01PM -0400, Bob Wyman wrote:
> [...]
> *                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.

Wouldn't supplying an 'acceptable' <options/> element initially, and altering
the options after approval not kind of defeat this 'advantage'?

> [...]
> <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>

I am a bit sceptic about the approach of adding additional elements inside
an item. I was under the impression that an item's payload must be at
most one element. Can't seem to find that in the JEP though. In any case,
the idea of ignoring stuff you don't know doesn't work for persistence (think

What can you store, and what is meta data? Especially for forward compatibility
this is interesting. This proposal makes it so that every implementation should
have knowledge of the possible existence of a SHIM header. Maybe we get tired
of this at some point, and think of a new kind of meta data, but older
implementations would think it would be data.

The rest looks nice to me. Looking forward to the next revision of JEP 0060.



More information about the Standards mailing list