[Standards] XEP-0369 (MIX): When to deliver messages to a client

Jonas Wielicki jonas at wielicki.name
Wed Jun 14 07:34:19 UTC 2017


On Mittwoch, 14. Juni 2017 08:23:49 CEST Steve Kille wrote:
> Jonas,
> 
> > From <https://github.com/xsf/xeps/compare/
> > 
> > master...stevekille:MIX#diff-46551996fe454185b68cb3f084c2e18fR2426>:
> > > The server receiving the message will then deliver the messages to all
> > > online clients with status available and a non-negative resource
> > > priority.
> > 
> > I think the new wording here excludes any client with e.g. away, na, dnd
> > or
> > xa status from receiving MIX messages. That sounds like overkill (I’m not
> > even sold on not receiving MIX messages with negative presence priority
> > actually).
> 
> [Steve Kille]
> 
> You asked me to fix an ambiguity, which I did!
> 
> I guess that we now need to work out the situations when to not deliver MIX
> messages to  a client.
> 
> I can see merit in having the client being able to signal it, which this
> wording allows.
> 
> I can also see a case for delivering the message whenever the TCP connection
> is there.   This keeps things simple.
> 
> I'm not sure what is best here.   Thoughts from client developers welcome.

As a client developer, I would certainly not want my user to have to stay 
"available" (with empty/absent <status/>) all the time and not receive 
messages while having a non-empty <status/> set. That is a huge side effect 
which is added to the <status/> of the <presence/>.


I have no strong opinion on negative-presence; I feel that is a rare use-case 
in human-to-human interactinos anyways.


To save bandwidth (if that is your goal), Client State Indication and a 
suggestion to servers how to act on <inactive/> in the context on MIX is more 
sensible.


kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170614/7a3642b8/attachment.sig>


More information about the Standards mailing list