Hi, * XMPP Extensions Editor <[email protected]> [2016-01-06 11:14]: > The XMPP Extensions Editor has received a proposal for a new XEP.
It's really awesome to see MIX going forward. As I haven't participated in the last summit and won't be able to come to Brussels, I'd like to write down my questions and feedback in yet another long email, in the hope that the points can be discussed/addressed this week. Maybe some of them were addressed already, but didn't find their way into the XEP yet. MUC Interop ----------- 1. Use same service JID for MIX and MUC: Parallel MIX/MUC operation is a designated goal, however the intro states that MIX and MUC SHOULD be hosted on different domains. I would like to ask the committee to revise this decision, altering the underlying protocol if required. XEP-0030 allows returning multiple 'identity' elements in a disco#info response, so I can not see a reason not to return both MUC and MIX identities on the same domain. On the other hand, I would consider interop (especially handling of invitations between MIX and MUC clients) to be much easier if the access protocol for the chatroom is not encoded in its JID. 2. Invitations: this isn't ready, obviously, but it needs to be able to handle all combinations of MUC and MIX transport between the inviter and invitee. 3. If #1 can not be addressed: the intro states "The MIX service SHOULD include a reference to the MUC mirror". This should be extended to recommend references in both directions, so a MIX client receiving a MUC invitation can upgrade to the MIX. Registration and Presence ------------------------- 4. §5.1.2 "Registering with a MIX Service" defines a new use case that was not available in MUC, without a clear rationale / use case. IMHO registering a nickname on a server has only little value, as for most IM users the chatrooms are distributed over many different services, and non-anonymous rooms will probably be in use where stronger authenticity of users is needed (i.e. corporate environments). If a user wants to register a nickname with a chatroom OTOH, this is already accomplished by <join/> in a more transparent way. I would suggest completely removing §5.1.2. 5. §5.1.3 "Coming Online" and Presence Reflection / MAM: from the example it looks like each client's presence update is published as a separate event by the MIX service. When a new client is coming online and wants to obtain the current list of present users, does it need to load the whole history of presence events, starting with day 0 and mostly containing stale presence changes that were overridden by later updates, or is there some aggregation / shortcut, like only keeping the latest presence event per full-user-JID? If instead there is a "current" event that contains the set of all currently online presences, we still need to have differential updates after that, so that a client is not flooded with redundant traffic in a large MIX. The same problem exists to a smaller degree for joins/leaves in the participants list. 6. §5.1.4 "Going Offline" needs to work in the case when the user's session is terminated unexpectedly. By normal presence processing rules this is only the case if the MIX JID is on the user's roster or if the user sent a directed presence to the MIX during that session. Therefore §5.1.3 "Coming Online" should be switched to using directed presence as well (maybe in a way comparable to / compatible with MUC, i.e. by adding 'x' elements for both XEP-0045 and MIX, and checking the response for MUC/MIX flags to see which protocol the server uses). 7. §5.1.5 "Sending a Message". My biggest pain point with MUC is its inability to associate a sent message with its reflected copy, to track success of delivery. If an 'iq' is used in MIX, the 'iq' result needs to contain the item ID or some other reference to the reflected item (BTW, the 'iq' response example should also be added to the XEP). Still, it would be nice to have a mechanism that does not rely on the 'iq' response in case the client connection is terminated before the 'iq' response arrives. If messages are used OTOH, we still need some way to associate outgoing messages to their reflections, and that method should be a mandatory part of the XEP (the message-ID XEP maybe?). 8. Publisher element: The 'publisher' element on message items is not quite clear. According to XEP-0060 this must be a JID, but I could see a nickname here as well, though that would mean a higher overhead when performing message attribution, as nickname changes need to be tracked over time. 9. Stable User JIDs: In non-anon MIXes, the user's full JID can be used for presence. For pseudonymous/anonymous MIXes, a mapping scheme is needed that allows to group multi-client-users and for a user's client to locate their other clients (i.e. for exchanging read-until-X markers). That probably means that a dedicated domain is needed per-MIX or per-MIX-service, where the user part is 1:1 mapped to the user's real bare JID and MIX room, and the resource part is either the according user's resource, or some 1:1 mapping of it (keyed hashing / encryption, so no real resource is leaked). For example: a) [email protected]/intibo24 joins [email protected], and is mapped to [email protected]/res0 b) [email protected]/yaxim joins [email protected], and is mapped to [email protected]/res1 c) [email protected]/intibo24 joins [email protected], and is mapped to [email protected]/res0 (deadbeef, foobarbaz, res0 and res1 are arbitrary markers that should probably be replaced by UUIDs) Have a fun time discussing and bringing forward the XEP, 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: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
