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

[Peter Saint-Andre]

Ian Paterson wrote:
> 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.

Yes, you're right. Both "open" and "whitelist" will be very useful --
"open" for things like profile data and public keys, "whitelist" for
private data storage. I'll fix that in 0.14.

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

See above.

> 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?

Never mind, just delete. That was just a thought.

> 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?

Er, probably -- but isn't that handled by including the delayed delivery
data as described in JEP-0060? Maybe we just need a reference to that.

> 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..."

I cleaned that up.

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

There are many typos, as I discovered when I read over it just now while
flying from Denver to Chicago.

Peter
-------------- 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/20060802/0a79a966/smime.bin