[Standards] Review of XEP-0369: Mediated Information Exchange (MIX) v0.9.5
dave at cridland.net
Wed Mar 21 09:26:31 UTC 2018
I agree with much of what is written here, so I'll concentrate on the parts
I do not agree with.
On 20 March 2018 at 16:34, Florian Schmaus <flo at geekplace.eu> wrote:
> 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 § 18.104.22.168.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.
I think it's useful for servers to be able to identify groupchat messages.
a) A server can identify them easily within a MAM archive so as not to
present them to clients which don't understand MIX.
b) It can route them differently for the same reasons.
I'd go along with type='normal' or type='chat' with much regret - but it's
considerably better than wrapping in pubsub.
> 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.
This seems fine to me.
> 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).
So, two things here:
1) I think the pseudonymity offered by MIX is useful, and it's done under
the user's control, which is an important step forward from MUC.
2) I don't like the JidMap. I'd be fine with stuffing the real jid into the
3) I think the messages ought to come from the proxy jids. I appreciate
this means that filtering/blocking issues need to be addressed, but I'd
note that servers need to do this anyway.
> 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#bar at mix.example/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.
It's nice to be able to link a MIX channel to your broadcast presence
state. Most of the time that's what we want, I think.
It's also nice not to have to - lots of times it'd be nice to be able to
track a channel without actually announcing my presence to it.
Feels like this area can be an optimisation under the user's control later,
since we can do directed presence for now.
> § 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/
> § 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
> § 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
> 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.
Not sure I agree with your solution, but I agree the current design is a
> § 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."
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards