[Standards] Presence Handling

Steve Kille steve.kille at isode.com
Fri May 25 06:59:53 UTC 2018



This is an interesting idea.




1.	For  a large channel, this could lead to LOTS of extra presence traffic (n*n)
2.	It does not give a framework to solve channel presence distribution for  JID Hidden







From: Manuel Rubio <manuel at altenwald.com> 
Sent: 25 May 2018 00:08
To: XMPP Standards <standards at xmpp.org>
Cc: Steve Kille <steve.kille at isode.com>
Subject: Re: [Standards] Presence Handling



I think presence isn't important to have the real JID. If you know the real JID for a participant you can subscribe to its real JID to receive the presence directly from the user instead of both MIX and User.

The point is the tag "<mix/>" inside of the message. The way to add or use real JIDs in presence makes no sense IMHO.

Kind regards.
Manuel Rubio.

El 2018-05-24 17:54, Steve Kille escribió:




That would also be problematic, since entities would then need to process presence rather differently, even more so than they do for MUC now.


I was thinking simply:


<presence from='{{proxyjid}}' id='{{tracking id}}'>

  <!-- ... -->

  <mix xmlns='...'>







[Steve Kille]

So what value is the proxy JID giving, given that the data which the client might have derived from the proxy JID is now encoded in the message??


I was suggesting message came from coven at mix.example <mailto:coven at mix.example>    you are suggesting it comes from  5q3509q759348#coven at mix.example <mailto:5q3509q759348#coven at mix.example> 


What benefit is the proxy JID giving to the client?





Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: Standards-unsubscribe at xmpp.org <mailto:Standards-unsubscribe at xmpp.org> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180525/5ae3577a/attachment-0001.html>

More information about the Standards mailing list