[Standards-JIG] JEP-0163: further PEP simplification

James Bunton jamesbunton at fastmail.fm
Tue Jul 25 22:46:43 UTC 2006


On 26/07/2006, at 8:31 AM, Peter Saint-Andre wrote:

> Personal Eventing via Pubsub (JEP-0163) is a simplification of the  
> full
> publish-subscribe protocol (JEP-0060). At the XMPP interop test event
> today in Portland, Oregon, we discussed some further simplifications.
> The basic idea is two-fold:
>
> 1. Instead of requiring the subscriber to subscribe individually to  
> each
> personal eventing node (tunes, mood, geoloc, etc.), the subscriber  
> will
> subscribe to the publisher's root collection node ( = bare JID )  
> and the
> publishing server will send whatever data formats the subscriber wants
> to receive based on preference information contained in the  
> subscriber's
> entity capabilities (JEP-0115) data.
>
> 2. The subscriber will subscribe not with pubsub <subscribe/>  
> syntax but
> with <presence type='subscribe'/> to the bare JID ( = root collection
> node ). This makes it much simpler for existing clients to be PEP
> subscribers. All you have to do is subscribe to a contact's  
> presence and
> if you include the right bits in your entity capabilities, you'll
> receive PEP events (no need to send a second subscribe request for
> personal eventing data, which is good because we have a lot of  
> existing
> subscriptions out there on the network and we can simply leverage  
> those).
>
> Thus the flow would be something like this (Romeo is our subscriber,
> Juliet is our publisher).
>
> 1. Establish presence subscriptions
>
> <presence from='romeo' to='juliet' type='subscribe'/>
> <presence from='juliet' to='romeo' type='subscribed'/>
> <presence from='juliet' to='romeo' type='subscribe'/>
> <presence from='romeo' to='juliet' type='subscribed'/>
>
> Note: this simplification works only if the presence subscription is
> bidirectional, so we need that to be set up first.
>
> 2. Send presence with caps
>
> <presence from='romeo' to='juliet'>
>   <c xmlns='http://jabber.org/protocol/caps'
>      node='http://exodus.jabberstudio.org/caps'
>      ver='0.9'
>      ext='set of extension names'/>
> </presence>
>
> Note: here we assume that the set of extension names includes  
> signalling
> of interest in the following namespaces:
>
> http://jabber.org/protocol/tune
> http://jabber.org/protocol/mood
>
> Our current thinking is that we'll do that by appending a consistent
> string to the end of the namespace URI, such as:
>
> http://jabber.org/protocol/tune?subscribe
> http://jabber.org/protocol/mood?subscribe
>
> Service discovery results for the subscriber would include those  
> URIs in
> addition to the bare namespace URIs.
>
> Note: we don't want to send notifications unless the contact signals
> both that it supports the data format and that it is interested in
> receiving notifications related to that format; this makes it possible
> for clients with constrained bandwidth to limit which data formats  
> they
> receive (or, naturally, to receive no PEP events at all).
>
> 3. Send notifications
>
> The publishing server sees that the subscriber is interested in  
> tune and
> mood information for Juliet so it sends notifications to Romeo for  
> those
> formats.
>
> <message from='juliet at capulet.com'
>          to='romeo at montague.net/home'
>          type='headline'
>          id='foo'>
>   <event xmlns='http://jabber.org/protocol/pubsub#event'>
>     <items node='http://jabber.org/protocol/tune'>
>       <item>
>         <tune xmlns='http://jabber.org/protocol/tune'>
>           ... PAYLOAD ...
>         </tune>
>       </item>
>     </items>
>   </event>
>   <addresses xmlns='http://jabber.org/protocol/address'>
>     <address type='replyto' jid='juliet at capulet.com/balcony'/>
>   </addresses>
> </message>
>
> <message from='juliet at capulet.com'
>          to='romeo at montague.net/home'
>          type='headline'
>          id='foo'>
>   <event xmlns='http://jabber.org/protocol/pubsub#event'>
>     <items node='http://jabber.org/protocol/tune'>
>       <item>
>         <mood xmlns='http://jabber.org/protocol/mood'>
>           ... PAYLOAD ...
>         </mood>
>       </item>
>     </items>
>   </event>
>   <addresses xmlns='http://jabber.org/protocol/address'>
>     <address type='replyto' jid='juliet at capulet.com/balcony'/>
>   </addresses>
> </message>
>
> Note: there is an explicit tradeoff here between ease of  
> implementation
> and amount of information received. A subscriber can't tell  
> publisher 1
> that it wants mood and tune but publisher 2 that it wants geoloc and
> activity. Instead, the subscriber is going to receive everything it
> advertises for (receipt preferences are broadcasted in presence). The
> consensus of the group at the interop event was that this tradeoff is
> acceptable since it greatly simplifies the protocol as well as the  
> user
> interface -- no need for the subscriber to manage detailed preferences
> for data formats on a per-publisher. However, people with large  
> rosters
> may receive lots of PEP messages if they advertise interest in many  
> data
> formats. Forewarned is forearmed.
>
> I will soon update JEP-0163 to reflect this approach. We will then  
> push
> it back to Experimental and initiate a second Last Call.
>
> Your feedback is welcome.
>
> Peter


That sounds great.
I really like it a lot. Basically, as soon as a client advertises  
nick?subscribe, etc, it starts getting sent the messages with the data.
No keeping track of whether you've subscribed to somebody already.

I'll be implementing this for PyMSNt 0.12 or 0.13.

---

James




More information about the Standards mailing list