[Standards] Carbons - inbound messages to bare jid

Matthew Miller linuxwolf at outer-planes.net
Fri Apr 25 13:00:41 UTC 2014

Right; this is what we intended the semantics to be.  I think the other
proposal is not a good idea.

- m&m
On Apr 25, 2014 6:58 AM, "Thijs Alkemade" <thijs at xnyhps.nl> wrote:

> On 25 apr. 2014, at 13:32, Kim Alvefur <zash at zash.se> wrote:
> > Hello,
> >
> > It has been brought up that my Carbons implementation does not follow
> > the Receiving Messages to the Bare JID¹ section.  This section says
> > include carbons-enabled sessions in the normal forking of messages as
> > described by XMPP IM².
> >
> > What I implemented was instead to send carbons-wrapped messages to
> > carbons-enabled sessions that would not already receive them based on
> > the XMPP IM rules.  So a message will always be carbons-wrapped if it
> > was sent because carbons was enabled.  I believe this makes sense, does
> > anyone else?
> >
> > ¹ http://xmpp.org/extensions/xep-0280.html#inbound-bare (version 0.9)
> > ² http://xmpp.org/rfcs/rfc6121.html#rfc.section.
> Hi Kim,
> Thinking about this a bit more, I actually disagree with this proposal.
> The semantics of receiving a carbon copy should be "hey this other resource
> has a conversation going, here's a copy of this message in case you want to
> follow along". That might imply, for example, that the client uses a
> different
> way of notifying the user: the user might have configured their client to
> not
> make a sound when receiving a carbon copy, as multiple devices making
> sounds
> gets annoying.
> A bare-JID message is a different situation. Sending one implies the
> sender is
> looking for a resource that will reply to start a conversation with it, so
> for
> these I think it would be fine if a carbons-enabled client notifies the
> user
> as if it were a normal message.
> Of course the client could add extra logic for this ("if it's a carbon
> copy,
> and the first message we've seen from this user this session/hour/day, play
> sounds"), but I think doing it in the way that is currently in the XEP is a
> much cleaner solution.
> Regards,
> Thijs Alkemade
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140425/493750c8/attachment.html>

More information about the Standards mailing list