[Standards] PEP, POP, PIP

Peter Saint-Andre stpeter at jabber.org
Wed Jul 18 18:50:40 UTC 2007

XMPP Extensions Editor wrote:

> Title: Private Data via PEP
> Abstract: This document specifies XMPP semantics for using the
> personal eventing subset of XMPP publish-subscribe to persistently
> store private data such as bookmarks and client configuration
> options.
> URL: http://www.xmpp.org/extensions/inbox/pdp.html

(Maybe I should have called that Private Information via PEP = PIP? :)


> Title: Persisting Objects via PEP
> Abstract: This document specifies XMPP semantics for using the
> personal eventing subset of XMPP publish-subscribe to persistently
> store semi-public data objects such as public keys and personal
> profiles.
> URL: http://www.xmpp.org/extensions/inbox/pop.html

I wrote these proposals to see how we could do private data storage (a
la XEP-0049) and "public" data storage via PEP. It can be done with the
publish-options feature described here:


I'm not yet convinced that this is the best way to do things, but it is

Thought experiment follows. Don't get too worried that I'm seriously
considering the following approach. :)


So you may wonder why I didn't define a pubsub/pop service identity and
a pubsub/pip service identity. Well, I don't think we can do that
because the virtual pubsub service hosted at your bare JID can't be pep,
pop, and pip at the same time since they have different default access
models and other node configuration options (last_published_item etc.).

A slightly different approach would be to narrow the definition of PEP
so that it's limited to basic pubsub + support for the "auto-subscribe"
and "filtered-notifications" features described here:


At that point, PEP (or whatever we call it, I like "virtual pubsub
service" or VPS :) consists of two things:

1. Your bare JID is a VPS.

2. Subscribers can easily receive data from your VPS.

Then we could define "node types" for pep, pop, and pip along with a way
to signal (when publishing) that you want the data to be published
according to the definition of the pep, pop, or pip node type. Even
something as simple as this:

<iq from='juliet at capulet.lit/balcony' type='set' id='pdp1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='storage:bookmarks' type='pip'>
        <storage xmlns='storage:bookmarks'>
          <conference name='The Play' the Thing'
                      jid='theplay at conference.shakespeare.lit'>

That kind of approach would mean that "pubsub/vps" is a service identity
whereas pep, pop, and pip are node types.

Pro: easier.

Con: limited.

By "limited" I mean that there may be node types (i.e., combinations of
node configuration options) other than personal eventing, object
persistence, and private information.

This is similar to MUC. We defined roles like owner and admin and
moderator, but people have always said those are limiting because it
would be more flexible to define a granular set of permissions and
assign those more dynamically rather than making these "hardcoded"
buckets like "admin" and "owner".

Personally I think life is easier if you give people something to hang
their hats on ("oh, he's an admin" vs. "oh, he has perms 3, 5, and 8")
and that excessive flexibility is overrated.

Just as we do with MUC, here we could define some basic node types. Like so:

PEP -- "oh, that's a pep node, which means it doesn't persist items and
sends out the last published item on subscribe or login"

POP -- "oh that's a pop node, which means it persists items and never
sends out the last published item"

PIP -- "oh, that's a pip node, which means the data gets sent only to
the account owner"

If we define publish-options people could still override those node
types, but providing a small set of node types would give people some
options they could understand more easily.


I'm not necessarily saying we want to go down that road. Maybe it's fine
to do publish-options forever. And going down that road would result in
simplification only on the publish side, which I see as less important
than the fundamental simplification we've achieved on the subscriber
side with "auto-subscribe" and "filtered-notifications". But it's at
least worth having a discussion so can dismiss the idea. :)


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

More information about the Standards mailing list