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

[Peter Saint-Andre]

Peter Saint-Andre wrote:
> Peter Saint-Andre wrote:
>> Magnus Henoch wrote:
>>> Great work!  The client developer in me really likes this
>>> simplification.
>>>
>>> Some comments, shooting from hip:
>>>
>>> Section 12, "Recommended defaults": "delete-items", "get-affiliations"
>>> and "purge-items" should be "retract-items", "retrieve-affiliations"
>>> and "purge-nodes", to match features in section 10 of JEP-0060.
>> Yep.
> 
> Regarding "smart defaults", I think it may be better simply to say what
> features a PEP service should support (e.g., deliver payloads) and if we
> don't mention a feature, assume that a service may support that feature
> if it wants to but is under no compulsion to do so.

In my working copy, I tentatively have the following text:

******

12. Recommended Defaults

A PEP service MUST:

    * Support the node discovery, node creation, node deletion, publish
item, subscribe, unsubscribe, and items retrieval use cases specified in
JEP-0060.
    * Support the "owner" and "subscriber" affiliations.
    * Treat the owner-publisher's bare JID (<node at domain.tld>) as a
collection node (i.e., as the root collection node for the account's
virtual pubsub service).
    * Set its default access model to "presence".
    * Deliver payloads (if any) in all notifications.

A PEP service MAY support other use cases, affiliations, access models,
and features, but such support is OPTIONAL.

******

Questions: is it right to say that the default access model MUST be
presence? That's another simplifying assumption if you ask me, and it
seems to be appropriate. Right now the spec says it SHOULD be presence
for IM and SHOULD be open for non-IM servers but since this is
*personal* eventing I think our context is IM servers and in that
context I don't have a problem with saying that the default access model
MUST be presence.

Also I don't know that the following use cases are required:

1. node deletion -- just don't publish to the node anymore, cleanup can
be performed as an automated process if desired

2. unsubscribe -- if subscribe can be handled via presence, why not
unsubscribe?

Another point that came up at the interop event was creating a node on
first publish (similar to "create room on join if it doesn't already
exist" in multi-use chat). This is OK if we have an acceptable default
access model (I vote for "presence"), then if you want some other access
model then ask for it via node creation. So if there are no objections I
will work that into the next version of the spec.

Thoughts?

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/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/20060801/d1493f3e/smime.bin