How will MEP / XEP-0316 handle unstable fullJIDs?
Greatsword via Standards <[email protected]> Fri, 19 Jun 2026 20:35:37 +0000
| Newsgroups | gmane.network.jabber.standards-jig |
|---|---|
| Message-ID | <[email protected]> |
--b1=_qPu9Tnmz3vfGwYq6I30i8SNwq49VCqYJ2BpTJxfI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just had a read of XEP-0316: MUC Eventing Protocol, and it seems=20 interesting and useful, but I'm wondering what happens to the MEP nodes=20 owned by a particular occupant. The XEP states... > An occupant does so by sending a publish-subscribe publish request to the= occupant's Occupant JID <room@service/nick> (similar to the way in which p= ublishing via PEP happens by sending a request to the user's bare JID <user= @host>). For instance, the following example shows how a room occupant woul= d inform the other occupants about an event of interest. which would mean that interested parties would be subscribing to=20 room@service/nick for their MEP nodes, but this could change from the=20 user leaving or changing their nick. Is it just meant to be a sort of=20 temporary live thing where you can ad-hoc send these events and then=20 they just go away when you leave? or could this be attached to something=20 more stable, like Occupant-ID. Thanks all! --=20 - greatsword --b1=_qPu9Tnmz3vfGwYq6I30i8SNwq49VCqYJ2BpTJxfI Content-Type: application/pgp-keys; name=OpenPGP_0xB99ABF87C86F067B.asc Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=OpenPGP_0xB99ABF87C86F067B.asc LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQoNCnhqTUVhWk4vYlJZSkt3WUJC QUhhUnc4QkFRZEE3L2Rob2ErWlp6TlV0TzVjVExZM3d2VG5LV1hqcGpxRitOZDUNCnk1OHM2cmZO SGtkeVpXRjBjM2R2Y21RZ1BHZHpRR2R5WldGMGMzZHZjbVF1ZUhsNlBzS1dCQk1XQ2dBK0ZpRUUN CjcyK3lXS0VFc2NOVXpCdUV1WnEvaDhodkJuc0ZBbW1UZjIwQ0d3TUZDUVdreDdNRkN3a0lCd0lH RlFvSkNBc0MNCkJCWUNBd0VDSGdFQ0Y0QUFDZ2tRdVpxL2g4aHZCbnRuR3dFQWd6Mll3VUhITFNM NFF0YVltYldlcUtOS2Z4dGkNClVDb0hrZUYvSGtjQ0wwZ0EvampuWmk0WDVvVlRGZjFxaTFIeXJQ OHR1cXR4NVl2ZW5HVEN4RWdYdnVzRHpqZ0UNCmFaTi9iUklLS3dZQkJBR1hWUUVGQVFFSFFFMERj MmV5a05KdnpsR3JuSjR5V0hPOElwdUZnNzlCMUdJSEZmb2ENClNsODBBd0VJQjhKK0JCZ1dDZ0Ft RmlFRTcyK3lXS0VFc2NOVXpCdUV1WnEvaDhodkJuc0ZBbW1UZjIwQ0d3d0YNCkNRV2t4N01BQ2dr UXVacS9oOGh2Qm52djlnRUE2QVRvM1ErYmZqLy9KUTVIemxtWUZOUFR1ME0ybmJIeG1Ja1QNCnFF eXFSRzBBL0FtTEdVTEdCZXI2OXpER3FqeGthVC9neXg1akpNcksvZWxMSkp4czBhNFANCj1LRElX DQotLS0tLUVORCBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQo= --b1=_qPu9Tnmz3vfGwYq6I30i8SNwq49VCqYJ2BpTJxfI Content-Type: application/pgp-signature; name=OpenPGP_signature.asc Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=OpenPGP_signature.asc LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCg0Kd25zRUFCWUlBQ01XSVFUdmI3SllvUVN4 dzFUTUc0UzVtcitIeUc4R2V3VUNhaldvRlFVREFBQUFBQUFLQ1JDNW1yK0h5RzhHZTNaYQ0KQVA5 bk0zTnFVc2ExN1E3YUxWcjh4aC9CeUhFb3hNdDNuU0tJZ0o4ZWkxeUFyUUVBMjFDK2RwVVRiL3g5 NTJXOTVBc1dZRmhhaXpoaw0KUFM1LzBDY3dhdjEwU1FrPQ0KPVZPbDYNCi0tLS0tRU5EIFBHUCBT SUdOQVRVUkUtLS0tLQ0K --b1=_qPu9Tnmz3vfGwYq6I30i8SNwq49VCqYJ2BpTJxfI Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected] --b1=_qPu9Tnmz3vfGwYq6I30i8SNwq49VCqYJ2BpTJxfI--