[Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))
flo at geekplace.eu
Tue Aug 23 08:56:38 UTC 2016
On 17.08.2016 17:30, Steve Kille wrote:
>> 2. Use of client's bare JID
>> Sending of presence and message packets to the user's bare JID is going to break things. First, message routing is server-defined, and
>> will cause different behavior on different servers. Second, a client with a negative presence priority will not be able to receive data
>> from MIX.
>> Third, messages and presence stanzas will end up routed to clients that do not support MIX or do not know which channels the user
>> is on, causing weird UX issues. Fourth, client authors will have to implement and enable carbons, and handle carbonated MIX
>> messages like regular MIX messages (whereas carbonated private messages might have slightly different semantics). Fifth, these
>> messages will end up in the user's offline storage, probably confusing a later resync.
>> As not all clients are going to implement MIX overnight, the protocol should not force new types of messages onto legacy clients.
>> Therefore I propose to make MIX participation more explicit:
>> a) always use the client's full JID to send MIX related stanzas
>> b) require a MIX capable client to explicitly send directed presence to all MIX rooms it is interested in (§5.1.6 is okay in this regard,
>> though I'd like to see an explicit extension element akin to MUC-join; a dumb client could just put both MUC and MIX extensions into
>> a presence packet and see what comes back ;-)).
>> c) As a consequence, MIX JIDs should not be part of the user's roster. I don't particularly like the alternative (bookmarks), but it still
>> sounds better to me than breaking legacy clients.
>> d) As another consequence, the MIX service would send copies of a MIX message/presence to each client of each user, instead of only
>> once per user. However, this will avoid the mess that RFC6120 message routing + Carbons is.
> A key design decision of MIX was to separate Presence and Messages. Users can register presence for multiple clients or none at all. Another decision was to make membership long term, so that messages get sent irrespective of presence. A consequence of this is that messages HAVE to go to the bare JID.
I suggest that this very rationale and the related fundamental design
decision of MIX should be put into the XEP.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 603 bytes
Desc: OpenPGP digital signature
More information about the Standards