Thanks Georg. On 26 Jan 2016, at 12:07, Georg Lukas <[email protected]> wrote: > 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.
I think this would be excessively hard for relatively little benefit (I could be wrong). > 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. Fair point. > 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. Fair point. > 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. This is supported under MUC already with iq:register stuffs, so it’s not entirely new. You might be right that it doesn’t need to be in MIX. > 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. You can always fetch the current state from the pubsub node, which would contain all the current presences, which I think is what you need? > 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). Yes, I think this should be presence-based. There isn’t universal agreement, but I think we need it. > 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?). Good point. > 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. We should be using JIDs as identifiers everywhere. > 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, Or it could be on the MIX domain itself, I think? /K _______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
