stpeter at jabber.org
Wed May 2 16:09:59 UTC 2007
A bit of a brain dump....
It seems to me that one of the problems / challenges with the idea of
"POP" (i.e., iq:private-over-[pubsub|PEP]) is that the data models are
unclear. In pubsub and PEP, we're interested in events generated by the
publisher or user. But that's not true for iq:private -- it's primarily
a storage mechanism. The typical use cases for private so far are things
like storage of client preferences, in which case it's the entire set of
preferences that matters. If you store things like bookmarks (XEP-0048),
you may instead be interested in one bookmark rather than the whole set
(but even then you'd want to get the entire list first and receive a
push for every change).
Think of the difference between rosters and privacy lists. Yes, you are
interested in the complete roster when you log in, but after that you
want the server to push you changes because each contact is an item unto
itself. But in privacy lists, you can't really push a change because
each item in a privacy list makes sense only in the context of the
entire list (given ordering changes etc.). Life is different in simple
communications blocking because an item is either on the blocklist or
not on the blocklist, thus a push makes sense.
So we have different data models in force. Sometimes you can reasonably
receive a push for one item in the set, other times the set itself is
If we're thinking about improvements to iq:private, it would make sense
to add a notification mechanism ("the set has changed") but I don't
think it would make sense for each item in the set to be a separate
pubsub item because it all depends on the data model of the sets we're
storing -- and those are completely free-form. Some people would like
the ability to add one item to the set stored in iq:private (rather than
updating the complete XML), but here again it all depends on the data
model of the payload. And I think we really want to avoid the
composition problem if at all possible (cf. XCAP).
We might be interested in notifications more generally. For example:
1. It might be nice to receive notifications of new items that are made
available via disco#items -- e.g., a new chat room has been created at a
MUC service. Items here are atomic.
2. The same might be true of disco#info -- though if we use entity
capabilities (XEP-0115) and share presence, we have a way of pushing out
changes to disco#info data.
3. We already have notifications for rosters via "roster push".
4. We have privacy list pushes (XEP-0016) but only to notify interested
resources that the list has changed (the list is atomic so we can't push
out only one item from the list).
5. We have block list pushes (XEP-0191) as described above.
Not all of the foregoing protocols are amenable to something like the
publish side of pubsub. For disco#items, typically those items just
magically appear (new chat room created, etc.). For disco#info, features
are added via enabled plugins or whatever. We have a fine way to manage
rosters. Privacy lists are atomic at the list level (not the item level)
so something pubsubbish doesn't make sense. Block lists could probably
be done via "POP" or iq:private but then the server would need to
monitor this special PEP node or iq:private store, which doesn't make
(Not that I'm suggested that we'd replace any of those protocols with
PEP or pubsub, I'm just providing some examples to think about.)
We have explored many domains that map just fine onto PEP as-is,
especially all the extended presence stuff like mood, tune, and geoloc.
These map well because they are fundamentally about events (changed
mood, new tune, modified geolocation) and each item that is published
has meaning by itself.
We have explored some domains that don't map so well onto PEP because
what you want to do is publish a set of information but enable
interested parties to be notified when one item in the set changes.
Public keys (XEP-0189) are one example -- you want to publish one or
more keys and have them be available for retrieval by any interested
party at will, but your contacts might what to know when one of your
keys has changed. An even better example is user profiles (XEP-0154) --
you want to publish your full profile and enable people to retrieve the
whole thing (vCard+), but your contacts might also want to know when
your mobile number changes or whatever.
I don't think we've yet done a good job of figuring out how things like
user profiles and public keys map to pubsub if at all. Maybe the data
models are such here that you really want to maintain the complete set
of data (your full user profile) but enable people to receive
notifications when the set has changed. In both of these cases (but
perhaps not others), the notification could consist of the new or
modified item. In fact, in both of these cases it also would be possible
to update the set on a per-item basis (updated key, updated mobile
number, etc.). But I think we need to take these things on a
case-by-case basis because whether an item in the set is atomic (or the
set itself is atomic) depends on the data model in play.
It's tempting to seek generic solutions to all problems, but
unfortunately reality is not always generic. :)
So IMHO it might be more productive to think in a more particular
fashion about the kinds of data we store in iq:private. Some of those
might be amenable to PEP or pubsub. Some might not. Some might be
solvable in other ways (such as my proposal to store MUC "bookmarks" in
At the same time, I also think it would be good to explore some generic
features that could be added to various protocols:
1. We might want a way to receive notifications for disco#items (and
perhaps other protocols). This could potentially use pubsub semantics
for the notifications. The entity sending you notifications would need
to know about your presence, but that's not insurmountable (e.g., you
could share presence with a MUC service so that it could send you
notifications of newly-created chat rooms for the length of your current
2. I think we also also want a way to retrieve a data set only if it has
changed since you last retrieved it. This could be useful for
disco#items, rosters, privacy lists, iq:private, and perhaps disco#info.
We've defined something like this in XEP-0150 by re-using the semantics
of HTTP Entity Tags, but I don't like the syntax of that spec as it
stands right now -- I don't think it should use SHIM headers -- but it
would be easy enough to modify the spec.
These features would best be written as simple extensions that could be
re-used in various existing protocols.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards