[Standards-JIG] JEP-0163 (PEP) retrieve items
Ian Paterson
ian.paterson at clientside.co.uk
Sat Jul 8 12:20:53 CDT 2006
JEP-0163 currently specifies that PEP services should not allow item
retrieval (see the list of "smart defaults" in Section 6). [The
functionality may be emulated by sending a pair of subscribe/unsubscribe
requests, but that is not simple, efficient or elegant.]
Item retrieval functionality is trivial to implement, and it would allow PEP
to act as a very simple generic protocol building-block for
personal-publishing - where the transmition and reception of notifications
upon every login are not desired.
For example, Peter's User Fingerprint proto-JEP
(http://www.jabber.org/jeps/inbox/fingerprint.html) is an efficient way to
enable subscribers to understand if they already have a local copy of
another user's public key. In this case notification subscriptions will be
unnecessary, so there is no need to push the whole public key to subscribing
contacts every time they become available.
Item retrieval would also facilitate other use cases, especially when the
"open" access model is used - and node subscribers do not send presence to
the publisher. For examples:
1. If a node subscriber prefers not to (or is unable to) persist it's own
copy of the last published item payload between sessions, then item
retrieval would be the only solution.
2. If the user subscribed to the node is using a different client (not the
one that subscribed to the node/namespace) at the time when an item is
republished, then the notification message will be delivered to the wrong
client (that client may not even support the subscribed namespace). So the
client that subscribed will never receive the notification, and, without
item retrieval, it has no nice way of obtaining the republished item. (It
seems likely that I'm missing something here?)
- Ian
More information about the Standards-JIG
mailing list