Dave,
Comments below, in red. From: Standards <[email protected]> On Behalf Of Dave Cridland Sent: 18 March 2019 17:43 To: XMPP Standards <[email protected]> Subject: Re: [Standards] MIX Have removed <submission-id/> and added reference to XEP-0359 That would, mind, be a breaking change - so I hope you're bumping the namespace. [Steve Kille] If you insist! Are you happy with this change? I’d like to ensure we are all happy. I’ll bump the namespace when things have settled down. I can see more changes coming in the next few days. * Section 7.1.5 suggests MIX messages should be archived at the server. This is very different to MUC, where clients always request messages directly from the MUC. It's a useful model with non-chat and other non-trivial cases, where the archive might actually be synthesized on demand from the source of whatever history is. Is there a rationale here? The existing MUC/MAM model seems to work very well. I imagine this probably doesn't matter, beyond clients having to guess when they joined a channel in order to redirect MAM requests. [Steve Kille] This model seems to arise naturally from the MIX-PAM model. Every message is sent to every client. It feels right to keep a copy at the client’s server, particularly to efficiently support multiple clients. It also works well if servers don’t have 24x7 connectivity. I do think we want to support the model of MIX-PAM server doing the archive. We could explicitly support both models, and have a MIX-PAM capability, so that the client does not have to guess. What do you think? I think we always support both models implicitly. The issue is that the client has to guess which one to use, so MIX-PAM has to be able to tell the client when it joined. Efficient support of clients and slow links probably means that we need to do both, but it feels like an area where we could improve - perhaps MIX-PAM could mediate MAM queries and service them from the local cache if available, rather than just dumping messages unfiltered into the "general" MAM? [Steve Kille] I think the mediation is too complex. I have made a change to MIX-PAM (and bumped the namespace) so that archiving is an optional service. Changes for review on Github. I’ve also change the message retrieval text in MIX-CORE. Changes on Github. On Sending, you must send a Nick if one is set. Of course you need one for JID Hidden. I don't think either of those statements are true, are they? §7.1.6 and Ex 27 don't discuss the sender putting in a nickname, and I don't think there's any difference between jid hidden and jid visible except what the jid is, is there? The following text seems clear and I think reflects what I say above. Am I missing something? 1. A <nick> element that contains the Nick of the message sender, taken from the Participants Node. This MUST be present if a Nick is defined for the user. 2. A <jid> element containing the real JID of the sender. This MUST be present, unless following the "JID Hidden" model defined in MIX-ANON. If this element is omitted, the <nick> element MUST be present. Presence (XEP-0403 3.5) is also clear. You must share the Nick if set. Again, no Nick only works for JID Visible. Again, looks to me like if the nickname isn't set, it'd all work fine. The following text from 3.5 seems clear and I think reflects what I say above. Am I missing something? 1. A <nick> element that contains the Nick of the message sender, taken from the Participants Node. This MUST be present if a Nick is defined for the user. 2. A <jid> element containing the full JID of the client. This MUST be present, unless following the "JID Hidden" model defined in MIX-ANON. If this element is omitted, the <nick> element MUST be present. * Old participants never die, they're merely removed from the pubsub node and require endless searching through MAM, or having all their data copied to the outgoing messages. MIX has lent toward both those options over its development, currently leaning toward the latter. Should we just include the participant element in the outgoing messages, instead of duplicating its contents? [Steve Kille] It does not matter much, but I think the current approach of including the information as cleanly as possible is best Specifically, I'm suggesting replacing: <message ...> <mix xmlns='..'> <stuff-here/> </mix> </message> with: <message ...> <participant xmlns='..'> <stuff-here/> </participant> </message> where the <participant/> here is identical to the definition in §4.7.3. The two elements are almost identical anyway - the major difference was the possible inclusion of the submission-id, but that's now gone. Hmmm, the intent of using <mix/>, was that this is a bucket for MIX-specific information in the message. <participant/> feels wrong, as this is all information relating to the message originator. I’m inclined to leave as is, unless anyone feels very strongly. Steve
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
