-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/3/13 11:29 AM, XMPP Extensions Editor wrote: > Version 0.1 of XEP-0316 (MUC Eventing Protocol) has been released. > > Abstract: This specification defines semantics for using the XMPP > publish-subscribe protocol to broadcast state change events > associated with a Multi-User Chat (MUC) room. This profile of > pubsub therefore enables a chatroom to function as a virtual pubsub > service, easing the discovery of syndicated data and event > notifications associated with such a room. > > Changelog: Initial published version approved for publication by > the XMPP Council. (psa)
In the Council discussion [1], Kev pointed out that this text is wrong: Note: It is strongly NOT RECOMMENDED to use directed presence with Entity Capabilities data that differs from the data included in broadcast presence for the purpose of establishing implicit PEP subscriptions to another entity, because the directed presence information will be overwritten by any subsequent presence broadcast. I agree, and will remove that from the next version. Kev also said: "And when you publish to your PEP node, that should be autopushed to your MEP nodes, presumably." Matt Miller asked me about that IRL later in the day yesterday, but didn't mention Kev's note (which Kev sent before I joined the chatroom, and I neglected to read the log). I disagree quite strongly with Kev's note, because I think that a MUC room is a completely separate publishing context from your bare JID. Just as you send directed presence to a chatroom (separate from your presence broadcasts), so I think you need to send a directed publish to the chatroom in order to share information there (separate from your PEP broadcasts). In fact I had added a note about that to XEP-0316 before publishing the spec earlier today: Note: Publishing to an occupant's MEP node happens by sending an explicit publish request to the Occupant JID. Publishing to a user's PEP node MUST NOT trigger a MEP publish request, because PEP and MEP are separate pubsub contexts. Naturally, this is something we'll want to clear up on the list or via discussion at the upcoming XMPP Summit in Brussels. [2] In any case, I didn't want anyone to think that I was ignoring Kev's comment or that I didn't intend to leave the issue unaddressed in XEP-0316. [3] /psa [1] http://logs.xmpp.org/council/130102/ [2] http://wiki.xmpp.org/web/Summit_13 [3] I think it's kind of cool that PEP is 163 and MEP is 316. Sometimes things just work out. ;-) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDl+BkACgkQNL8k5A2w/vy07QCg+twc8UYohSAcG2hD7QkJ3aTp 4DoAoLClSH9Xx+VeFNtUUsViK6WXR+Sh =SFo+ -----END PGP SIGNATURE-----
