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

Peter Saint-Andre stpeter at jabber.org
Tue Jul 25 22:31:08 UTC 2006


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

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060725/1e1ca27a/attachment.bin>


More information about the Standards mailing list