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 <[email protected]> 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 § 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. > I think it's useful for servers to be able to identify groupchat messages. Two reasons: 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 message. 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#[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. > 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/ > 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. > Not sure I agree with your solution, but I agree the current design is a bit rubbish. > > § 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: [email protected] > _______________________________________________ > >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
