[Standards] XEP-0033 Extended Stanza addressing: Directed presence use case

Mickaël Rémond mremond at process-one.net
Tue Aug 4 17:35:21 UTC 2015


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



More information about the Standards mailing list