[Standards] XEP-0033 Extended Stanza addressing: Directed presence use case
mremond at process-one.net
Tue Aug 4 17:35:21 UTC 2015
On 4 Aug 2015, at 18:39, Florian Schmaus wrote:
> On 03.08.2015 22:21, Mickaël Rémond wrote:
>> What happens next is unspecified, but I think it should be as follow:
> Maybe I'm missing something, but why is that underspecified? The
> of the user sending the presences with xep33 should simply behave like
> the user had send multiple single presence stanzas.
The Multicast service is not necessarily on the same server that the
user using the multicast service. It means that the user server may not
support multicast and the user may be using a remote multicast service.
In that case the server does not know (and doesn't need to know) about
the extended stanza addressing behaviour. It just broadcast directed
presence to the multicast service.
Moreover, it avoid special case in the server router as that multicased
directed presence is correctly offloaded to the service. We thus have a
better separation of concerns.
>> * When you send an extended addressing presence stanza through a
>> multicast service, the multicast service MUST keep track of the
>> entities that have received the the individual directed presence
> I don't think it's the responsibility of the xep33 (extended stanza
> addressing, multicast) service to keep track of the directed
> That should be taken care of whatever component of the server
> implementation does take care of non-xep33 directed presences.
I think it that case, it is the responsibility of the XEP-0033 service
for the reason explained above. The user server may simply not know
about the multicast protocol and it should not have to handle a special
case to understand the extended stanza addressing behaviour. I think
adding that simple rule makes everything much cleaner from a server
>> * When the multicast service receive an unavailable presence stanza
>> without extended addresses, it MUST broadcast the updated presence
>> to all the JID that have received a directed presence previously (if
>> the multicast service has not yet sent unavailable presence to that
>> entity, through a previous extended stanza presence).pres
> Like above: I would not consider the multicast service responsible.
> need already a server mechanism which keeps track of presence sessions
> caused by directed presences. Why not make that mechanism xep33 aware,
> instead of offloading the work to the xep33 service?
Because it spread the XEP 0033 logic across different part of the server
without a real need to do so and it will only work well if the server of
the user is aware of the XEP33. Nothing prevent a user to use a
multicast service on another server. In that case, multicast presence
will not work.
> But anyway, I never considered xep33 with regard to presences. That
> opens interesting possibilities. Thanks for pointing out that xep33
> be used to join multiple MUCs with a single presence stanza. :)
Yes, I understand as I never considered it as well, until I was asked
how to join multiple chatroom in a single packet. I considered that
impossible until I realized that XEP33 was also about presence.
I hope it makes sense to you :)
Thanks for your feedback !
More information about the Standards