[Standards] Move Carbons to Last Call ("Proposed")

Dave Cridland dave at cridland.net
Wed Aug 12 09:54:06 UTC 2015

On 12 August 2015 at 09:01, Georg Lukas <georg at op-co.de> wrote:

> * Steve Kille <steve.kille at isode.com> [2015-08-12 08:14]:
> > Given that a MAM based approach may be the  preferred medium term
> > approach, it seems to me that we should focus efforts to work out what
> > the medium term approach is going to be.
> +1
> > Also, if there is a list of issues that some people view need fixing
> > with carbons, I think it would be good to have that list explicitly
> I've tried to compile a more general list of issues some time ago, to
> be found here:
> http://mail.jabber.org/pipermail/standards/2015-April/029722.html
Thanks, this is well worth [re-]reading, as it's a good summary of
multidevice issues.

> The carbon relevant things from that list and from the last 0280 advance
> discussion are:
> * Carbons for non-"chat" messages. Jingle signalling of incoming calls
>   to all interested clients was mentioned IIRC.
That use-case won't work anyway because Jingle calls are initiated with an

> * No filtering mechanism. Carbons are only for type="chat", the client
>   can't add / remove types according to its needs.
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'.

> * "False-positive" Carbons of MUC private messages (which are of
>   type="chat"; see
>   http://mail.jabber.org/pipermail/standards/2015-May/029819.html and
>   following messages for a discussion and possible solutions). I think
>   the solutions need to be codified in the XEP.
I think there's a number of cases where a user's server needs to know that
a remote entity is a MUC (and thankfully, with MUC, this is relatively
simple to achieve). FWIW, the same issue also affects PEP (where PEP
doesn't use headline, at least), but is rather simpler to solve on a
stanza-by-stanza basis.

For MUC, I'll summarize our conversation online as servers already have to
track directed presence to chatrooms; 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).

> * Carbon notifications (not strictly an XEP issue, rather one of proper
>   UX) - when should a client ring a bell? Recommendations for this case
>   might or might not be appropriate in the XEP.

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?

> Georg
> --
> || http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
> || gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
> || Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
> ++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150812/49791be0/attachment.html>

More information about the Standards mailing list