[Standards] POP/PEP/pubsub

Wed May 2 11:09:59 CDT 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 
"atomic".

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 
sense either.

(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 
the roster).

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 
presence session).

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.

Thoughts?

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/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/20070502/70249734/smime.bin