As of now MIX is bloated and got way out of hand. It is a prime example for a standard that grew enormously without implementations following. At some point in the past I hoped that the authors would split MIX into a mandatory to implement but slim core specification and an add-on XEP with the optional features. Unfortunately that never happened and ideally it would have been done from the very beginning.
I am sceptical if using messages with type 'groupchat' is a good decision. First, sending type 'groupchat' messages to bare JIDs usually causes a stanza error reply as per RFC 6121 § 8.5.2.1.1. "For a message stanza of type "groupchat", the server MUST NOT deliver the stanza to any of the available resources but instead MUST return a stanza error…". Given that MIX requires support of the participants server, this is an override of this rule which should at least be clearly stated in the XEP. But more importantly, traditional XEP-0045 groupchat messages are often not stored in the user's archive, while MIX messages need to be. And there is no technical reason for MIX to use type 'groupchat' messages. In fact, the type of MIX messages is irrelevant, as MIX requires the XMPP-RFC routing rules to be overwritten in every case. Hence I'd simply use 'normal' / "no type specified" messages. Two controversial points about MIX are "channels in roster" and "JID hidden channels". For the former I'd like to see some motivation in the XEP *why* we need channels in roster, which probably becomes an explanation why users should be subscribed to the channels presence and vice versa. If there is no good technical reason for doing so, then I'd suggest that we drop that. Clients still could display channels next to the roster, like some already do with MUCs. For the latter I feel like the jidmap and proxy JID does *not* add unjustifiably much complexity to the XEP while I believe that there may be situations where you want to hide your JID. On the other hand I could life without that future too (and it would make MIX way easier to implement). Ultimately it would be great if support for "JID hidden channels" could be an optional part of the spec, but I didn't came up with a good approach allowing this (yet). With MIX I now get a real presence flood after sending my available resource, including presence from JIDs not im my roster (thanks to MIX JID construct foo#[email protected]/resource). The situation is similar with MUC, but only after explicitly joining the channel. I'd like to see the XEP at least discussing the situation, to make the implementer aware of it. § 3.5 ----- "All MIX messages received by the MIX participant's server for a participant MUST be stored using MAM in the participant's archive.". It seems to be a fundamental design idea of MIX that the primary archive of channel messages is the one of the participant. While this distributes the load of a single channel across multiple archives, I don't see a reason why this is a hard requirement. I would at least s/MUST/SHOULD/ here. § 3.9.7 ------- "A MIX channel MAY require that all participants publish presence." Why is that an option? How could that be enforced? By having the participant to accept a presence subscription request from the channel? If so, then this should be clearly stated. Nit: "and NOT using pubsub protocol." 'NOT' is not a RFC 2119 keyword. "Clients MUST NOT directly access the presence node using pubsub." I'm confused, then why have we the node in the first place? Just so that entities can subscribe to it and receive presence? If so, what is the point of having Example 3? But if we already put the MIX channel in the roster, then why can't we simply use standard presence subscription (requests) instead and drop the presence node? § 6.1.2 ------- Adding the channel to the roster triggers a roster push after <join/>. It is not specified if the pushed roster item is MIX annotated or not. It possibly should be annotated. Nit: Possibly s/no presence information is sent about the MIX channel to the user./no presence information about the MIX channel is sent to the user./ § 6.1.4 ------- Nit: Example 37 is missing the 'xmlns' attribute and usually <items/> always has exclusively direct <item/> children. § 6.1.10 -------- There is probably no way we could make Example 48 less complex without dropping support for proxy JIDs and the jidmap, but it should be at least uniformly indented. As it is right now, it is pretty scary. § 6.1.14 -------- Nit: "<id> attribute" should be "'id' attribute" § 6.1.16 -------- Nit: "checks with disco" sounds a little bit to informal. § 6.3 ----- The approach specified herein is fragile and prone to duplicate or lost messages (especially if SM is not used on s2s). The main design flaw is this """ When this happens, the MIX channel MUST take responsibility to ensure that the message is retransmitted and delivered. """ Instead the protocol should exploit the fact that not the MIX channel but the participant's server has an greater motivation to provide its user a gap-free groupchat experience. Therefore I suggest shifting most of the responsibility from the MIX channel to the participant's service. That is, instead of "MIX channel MUST take responsibility to ensure that the message is retransmitted and delivered.", the MIX channel simply sends the marker to the participant's service, upon which the participant's server re-syncs its archive with the MIX channel archive (e.g. by using MAM). Note that this reassembles the invaluable design idea of djb's Internet Mail 2000 and StubMail somewhat. Furthermore, the participant's service could periodically query the MIX channel for its last message ID and total message count, re-syncing, possibly using bisection, if both don't add up. Example's 65 response could be simply an empty result IQ. § 6.5.1 ------- It appears dangerous to announce features depending on who asks. This could cause all sorts of troubles, for example with ecaps/ecaps2. § 6.5.4 ------- Suddenly talks about MUCs (possibly a copy and paste error). And a good candidate to factor out into an add-on XEP. § 6.5.7 ------- Example 72 response is missing <item/>. Example 73 is missing <item/>. § 6.5.8 ------- Example 74 is missing <item/>. Example 75 is missing <item/>. Getting PubSub right is sadly hard. § 7.2 ----- "The participant's server MUST NOT make any other modifications to each message." I think the server will possibly at least inject a MAM-ID using <stanza-id/> into the message. Thus the strong normative wording seems wrong here. Further Nits ------------ - Example 44 has broken indentation - Example 46 has broken indentation - s/$gt;/>/ - Some PubSub examples violate XEP-0060 § 7.1.1.: "Depending on the node configuration, the <publish/> element MAY contain no <item/> elements or one <item/> element."
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
