[Standards] Move Carbons to Last Call ("Proposed")
georg at op-co.de
Wed Aug 12 10:43:47 UTC 2015
* Dave Cridland <dave at cridland.net> [2015-08-12 11:55]:
> > * Carbons for non-"chat" messages.
> That use-case won't work anyway because Jingle calls are initiated with an
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
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
* 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
* 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
> 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:
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 811 bytes
Desc: Digital signature
More information about the Standards