Hi Steve, thanks for the clarifications. I'm still not quite sure about the implications of some of the things though, maybe you can clarify...
* Steve Kille <[email protected]> [2016-08-17 17:33]: > MIX permits three modes with MUC: > > 1. No MUC. There is no requirement to support MUC. This may make sense > for specialised implementations now, and more generally in the future. I anticipate that day. We are only some decades away from it ;) > 2. MIX and MUC on separate domains. This can work well for many > environments, particularly where a limited set of clients are used, and where > clients have good support for MIX/MUC co-existence. A MIX domain may > reference an associated MUC domain, which will help clients supporting this > setup. I'd assume that this feature should be implemented by having the MUC reference the MIX domain, and not the other way around. That would allow interop between MIX and MUC users, as the MIX-capable clients can look up the MIX JID when invited to an "upgradable" MUC. It doesn't make much sense to implement a MUC reference on the MIX JID, because a MIX client will obviously use the MIX, and MUC clients won't be able to obtain the MUC reference from a MIX JID. This would boil down to people communicating the MUC JID and smart clients automatically upgrading to MIX, which has the same UX as #3 below, with a higher technical complexity on the client side. > 3. MIX and MUC on the same domain. This will be trickier server side, and > I do not think it makes sense to force servers to implement this. You are > right that this will improve migration and co-existence. So for some > servers, this may well be the right way to go. I think it makes sense to force servers that will support both MUC and MIX to implement #3 as the default interop mode, as it will immediately upgrade all MUCs on MIX-enabled servers to MUC+MIX, increasing the MIX propagation significantly. Also, I'm not convinced that it will be really challenging on the server-side, besides of the disco#list clash I outlined in my first email. Could you (or server implementors) please provide the reasons why this is going to be complicated? > Co-existence is important, but I think that the priority is to get MIX right. Indeed, but if we can provide seamless MUC+MIX interop at the cost of some small technical tweaks to MIX, we should at least discuss the trade-off and make a well-founded decision on this. So far I don't see how this interop prevents us from making MIX right. > > 2. Use of client's bare JID > [Steve Kille] > > 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 understand the design decision to make MIX membership a long-term thing bound to the user account. However, by sending messages to the bare JID you are introducing technical interop problems with RFC6121 message routing. The MIX XEP is currently not very clear in regard to this. If I am a member of the MIX and subscribed my account to both presence and messages, but haven't announced any presence, will the MIX service send messages to my bare JID? Will it send presence packets? If yes, and my clients are currently offline, messages will land in my account's MAM / offline storage, and presences will trigger error responses to the MIX. If a non-MIX client is/comes online, that client is going to receive (and fail to properly display) MIX messages sent to the bare JID. If no, a MIX-enabled client needs to send some kind of trigger (e.g. presence) to the MIX to start receiving MIX messages and presences, so we could as well direct these stanzas to the client's full JID. > Using the roster to hold MIX JIDs is elegant and has some significant > benefit. Could you please outline the benefits as compared to e.g. bookmarks? This needs special handling in the client anyway (i.e. the client needs to remember / disco#info / caps-check) all roster JIDs anyway to see which are users and which are MIXes. > To use MIX, clients have to support MIX and the servers they use have > to support MIX (e.g.., PAM - XEP-0376). So legacy clients are not > going to see MIX stuff. Except for MIX messages that are sent to the bare JID and inadvertently received by non-MIX clients. The only way to prevent this is by sending messages to the full JID of MIX clients, which have to announce their MIX-ability to the MIX. > > 3. Message tracking > [Steve Kille] > I'd welcome a detailed proposal on how to address this There is XEP-0359 "Unique and Stable Stanza IDs" with 'client-id', which is probably the most progressed proposal for this idea. My only gripe with it is that it introduces another extension element with a namespace and an ID distinct from the initial packet ID, so it's adding some 50 bytes to each message. But I think I'm optimizing the wrong thing here... Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: Digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
