[PubSub] Brussels report

Peter Saint-Andre stpeter at stpeter.im
Tue Feb 10 21:22:53 CST 2009

At the XMPP Summit yesterday, we talked a bit about PubSub and PEP. I
didn't participate in this small group discussion the whole time because
I was moving from group to group, so hopefully people can correct me
where my information is wrong or incomplete. However, I think we came to
the following conclusions:

1. The "one node per namespace" rule in PEP is overly restrictive. The
canonical example of why we need to remove this restriction is Atom (it
can be used for blog posts, GeoRSS, and a dozen other things). To relax
this restriction, we would define well-known NodeIDs and specify that
the node's payload type is Atom or whatever. Existing PEP payload specs
(tunes, mood, etc.) might be updated to specify that there might be
compatibility problems if you attempt to publish that payload to a
NodeID that does not match the namespace (however, I don't think even
this is necessary because nothing will break if new NodeIDs are mapped
to existing payload types).

2. Nathan Fritz explained that Seesmic sets the pubsub#expire field to
"presence" in order to indicate that a subscription will run out when
the service receives unavailable presence from the subscriber (in their
system, I think this is typically a full JID). We had consensus that
this is fine and that we don't need a new subscription option for such
temporary subscriptions.

3. We discussed presence-based delivery. I think the conclusion was that
the service could generate one notification for each resource in this
case, rather than sending one notification to the bare JID of the
subscriber and depending on the receiving server to send it to one or
more resource.

4. The subscription depth stuff for collection nodes is madness and
needs to be removed from the spec.

5. Ralph Meijer and Blaine Cook argued that we may not need collections
at all, but I missed that part of the discussion.

6. In general the spec needs a cleanup and perhaps another round of
simplification or pruning. This is on my priority list, but I think it
might be slightly lower than the Jingle modifications (see discussion on
the Jingle list).

Anything else?


[ written en route from Brussels, delivery times may vary :) ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/pubsub/attachments/20090211/7343f686/attachment.bin 

More information about the PubSub mailing list