Hello Florian,
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
server
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
packet.
I don't think it's the responsibility of the xep33 (extended stanza
addressing, multicast) service to keep track of the directed
presences.
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
developer perspective.
* 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.
You
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
can
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 !
--
Mickaël Rémond
http://www.process-one.net
