[Standards-JIG] Re: UPDATED: JEP-0163 (Personal Eventing via Pubsub)

Ian Paterson ian.paterson at clientside.co.uk
Wed Aug 2 11:11:33 CDT 2006


This is great work. :-) It is wonderful to see how the latest changes to PEP 
simplify the protocol for those clients that are only interested in the 
"Presence" access model.

However, the utility of PEP extends well beyond just extending presence 
info. PEP is important for publishing all types of personal data, both to 
and beyond the contact list. I think we should be careful not to dilute the 
utility of PEP as an essential building block for future protocols. We 
should *require* PEP services to implement the most important features.

For example, the "Open" access model will be an essential building block for 
countless protocols. It is already necessary for many existing protocols, 
including publishing public keys (JEP-0189) and, for many users, avatars 
(JEP-0084). Therefore, IMHO, PEP clients MAY use the "Open" model, but PEP 
services MUST support it.

This will require a little more server-side protocol support - since node 
creation/subscribe/unsubscribe would also need to be moved to the "A PEP 
service MUST" list.

Magnus Henoch wrote:
> Maybe the "whitelist" access model should be a MUST?  That would make
> replacing Private XML Storage possible.

+1

That means the node creation and item retrieval use cases would also be MUST 
for PEP *services*. These cases are necessary for existing JEPs based on PEP 
anyway.

Perhaps support for the subscription configuration options 
'deliver_notifications' and 'send_last_published_item' should also be 
required for PEP services - since they are used by (existing) PEP-based 
JEPs.


Peter wrote:
> node deletion -- just don't publish to the node anymore, cleanup can
> be performed as an automated process if desired

- How would the PEP service know which nodes it is allowed to clean up? What 
protocol (if any) should the service send to the subscribers/owner when it 
cleans up?
- It is conceivable that for some protocols built on top of PEP, publishing 
an empty item could have a different meaning to not publishing one at all.
- Maintaining empty items just creates extra noise on the network when 
subscribers come online (in addition to extra the server resources).

Perhaps it is more simple just to provide a delete protocol?


One question: If the node owner goes offline without publishing empty data, 
does the tune/mood/activity etc continue to be published? If so, shouldn't 
the time the data was published be included in the notifications for any 
subscribers that come online (and for item retrieval responses)? If so, 
should timestamping be part of every PEP-based JEP, or part of PEP/JEP-0060?


At the start of the "Contact Notification Filtering" section "A contact with 
a presence subscription to the account owner" should be "A contact with a 
presence subscription *from* the account owner". It might even be a little 
clearer to say something like: "If the account owner is subscribing to the 
presence of a contact, and if the contact does not want to receive 
notifications..."

There's a small typo in the first sentence of the "Concepts and Approach" 
section. "five" could now be "the following".

Cheers,

- Ian




More information about the Standards-JIG mailing list