* Dave Cridland <[email protected]> [2015-08-12 11:55]: > > * Carbons for non-"chat" messages. > That use-case won't work anyway because Jingle calls are initiated with an > <iq/>.
Ah, the discussion thread for that somewhat complicated use case can be found here: http://mail.jabber.org/pipermail/standards/2014-August/029100.html In http://wiki.xmpp.org/web/XEP-Remarks/XEP-0280:_Message_Carbons there is also a link to http://mail.jabber.org/pipermail/standards/2013-January/026988.html which seems to be an implementation/misunderstanding issue. > > * No filtering mechanism. > True; do we need this in order to deploy Carbons, though? I suspect we > ultimately do to cover non-IM scenarios, but for normal IM we can probably > handle just type='chat'. IMHO, we should not add any kind of filtering to Carbons. However, I wanted to bring up that point as it was mentioned in one of our many earlier Carbons discussion threads. > > * "False-positive" Carbons of MUC private messages > I think there's a number of cases where a user's server needs to know that > a remote entity is a MUC [...]. We need to codify what MUC services, XMPP servers and clients have to do with MUC PM Carbons, in the context of multiple clients. I see this as the major show-stopper in advancing 0280. The first problem is, that if only one of your clients is joined to a MUC, the others will still receive MUC PM carbons, causing really weird effects. Possible approaches to solve this are: Variant 1 (as implemented by prosody, and probably also ejabberd): * MUC service tags all PMs with <x xmlns='http://jabber.org/protocol/muc#user' /> * XMPP server does not carbonize tagged messages * MUC-joined client needs to be modified to tag "sent" PMs as well * carbon-receiving client remains unmodified Variant 2: * MUC service remains as is * XMPP server has a list of MUCs per client session, exempts "sent" and "received" messages from carbonization according to this list * client remains unmodified Variant 3: * MUC service tags all PMs as in Variant 1 * XMPP server does nothing * client has to special-case tagged messages, i.e. by opening a MUC-PM window instead of a regular PM window, and by addressing responses to the full JID accordingly. I am very much in favor of writing down Variant 1 or 2, or a mix of them, in the XEP. I think that tagging of MUC PMs has some value on its own, but this is a 0045 thing, not a 0280 thing. Variant 2 requires no client modification, but having a list on the server might or might not induce additional cost. The other problem is, when two of your clients are joined into the same MUC sharing the same nickname. There are no obvious routing rules for such a case, causing even more weird issues. One example is when your client /A sends an IQ request to a MUC participant, the IQ response is routed back to /B (this is happening on production servers today). For PM routing, things look similarly bad. I am not sure if we can/should address this situation in the context of 0280 at all, this might be rather something for MUC2. However, I would like to have a discussion of the use-case (two clients with identical bare-JID joined to the same MUC, exchanging PMs with other users) including its corner cases, and I can imagine a solution involving Carbons. > it should be relatively low-cost to check responses and mark those as > chatrooms as needed, and then perform a lookup for Carbons purposes. > > I think I can patch Openfire to do this, and I believe you suggested > Prosody may do something like this already (but I may have misunderstood). Prosody's MUC component is tagging messages, as of http://hg.prosody.im/trunk/rev/09151d26560a - and tagged messages are exempted from carbonization. > > * Carbon notifications > I made the comment on HN that, as a community, we tend not to try to get a > consistent UX, and that perhaps we should, and explaining when to notify > (and how) would be a great start - maybe we should kick that off with a > Wiki page and see where it goes? I heard there is such a wiki page already: http://wiki.xmpp.org/web/XMPP_IM_Client_Design_Guidelines I think it would be a welcome addition, but I struggle to promote my own idea (as implemented in yaxim) as the way to go, at least without some feedback. Georg
signature.asc
Description: Digital signature
