[Standards-JIG] MUC/pubsub multicasting using JEP-0033. Was: MUCtraffic issues

Bob Wyman bob at wyman.us
Mon Feb 20 21:10:31 UTC 2006


Ralph Meijer wrote: 
> For Bob. I see that JEP-0033 has a provision for providing extra
> data inside the <address/> node. This could be used to store
> subscription ID information, that'd have to be supported on the
> receiving end, of course.
	Yes, I've seen that. However, unless we change things a bit, use of
JEP-0033 for PubSub would mean that we wouldn't be able to use "multicast"
routing for any PubSub events that contained more than one item. (That may
not be a real problem.)
	JEP-0033 permits one to put SHIM headers in the individual
<address/> nodes in order to identify the target subids. However, there is a
scope problem... The order of nodes in a PubSub message stanza is:
<message....>
 <event ....>
   <items ...>
     <item...>
      <headers ...> <-- SHIM headers are item specific
        <header....>
      <item body...>
     ...
	JEP-0033 <addresses/> elements "modify" the <message/> element while
PubSub (JEP-0060) uses SHIM headers to identify subids for each <item/>
element. If we use JEP-0033 as defined and move the SHIM headers up the
hierarchy so that they are children of the <address/> element, that means
that all <item/>'s in the <event/> would have to be destined for the same
recipients (as defined by JEP-0033 headers) and all items within the event
would have to be destined for the same recipient/subid combinations. 
	What this means is that it would rarely be possible to send more
than a single <item/> in a single "multicast" event.
	I present below two example uses of JEP-0033 with PubSub messages.
The first uses JEP-0033 as defined with SHIM headers in each <address/>
element. The second shows JEP-0033 <addresses/> being added as children of
the <item/> element. The second is more flexible. However, I'm not sure how
frequently one would actually use the flexibility.
	In any case, we would have to define a "feature" for
pubsub#addresses since we wouldn't want to risk sending multicast pubsub
messages to a system that only understood JEP-0033 addresses but didn't
handle SHIM headers.

1. JEP-0033 as defined but with SHIM headers in the <address/> elements:

<message to='multicast.xmpp.pubsub.com' 
  from='pubsub-delivery at xmpp.pubsub.com' >
  <addresses xmlns='http://jabber.org/protocol/pubsub#addresses '>
     <address type='to' jid='addr1 at pubsub.com'
       <headers xmlns='http://jabber.org/protocol/shim'>
         <header name="subid">pubsub/subs/b11ea</header>
         <header name="subid">pubsub/subs/f001a</header>
       </headers>
     />
     <address type='to' jid='addr2 at pubsub.com'
       <headers xmlns='http://jabber.org/protocol/shim'>
         <header name="subid">pubsub/subs/dead01</header>
       </headers>
     />
  </addresses>
  <event xmlns='http://www.jabber.org/protocol/pubsub#event'>
    <items node='pubsub/topics/101'>
       <item id='6802'>
         <pubsub-message xmlns="http://pubsub.com/xmlns">
         ...
         </pubsub-message>
      </item>
    </items>
  </event>
</message>

2. JEP-0033 at the item level:

<message to='multicast.xmpp.pubsub.com' 
  from='pubsub-delivery at xmpp.pubsub.com' >
  <event xmlns='http://www.jabber.org/protocol/pubsub#event'>
    <items node='pubsub/topics/101'>
       <item id='6802'>
         <addresses xmlns='http://jabber.org/protocol/pubsub#addresses'>
           <address type='to' jid='addr1 at pubsub.com'
             <headers xmlns='http://jabber.org/protocol/shim'>
               <header name="subid">pubsub/subs/b11ea</header>
               <header name="subid">pubsub/subs/f001a</header>
             </headers>
           />
           <address type='to' jid='addr2 at pubsub.com'
             <headers xmlns='http://jabber.org/protocol/shim'>
               <header name="subid">pubsub/subs/dead001</header>
             </headers>           
           />
         </addresses>
         <pubsub-message xmlns="http://pubsub.com/xmlns">
         ...
         </pubsub-message>
      </item>
    </items>
  </event>
</message>

bob wyman






More information about the Standards mailing list