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. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
