[Standards] Carbons - inbound messages to bare jid

Holger Weiß holger at zedat.fu-berlin.de
Fri Apr 25 13:20:34 UTC 2014

* Thijs Alkemade <thijs at xnyhps.nl> [2014-04-25 14:57]:
> 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.

This is already taken care of by plain XMPP IM¹: The server delivers
bare JID messages to one or more(!) available resources without wrapping
them either way.  XEP-0280 only deals with deliveries that would *not*
have taken place by means of RFC 6121.  Those are carbon copies by
definition, so they are *not* the I'm-looking-for-a-responsive-resource
type of broadcast messages you have in mind.  The fact that I want my
client to not beep on those copies is precisely one of the reasons I'd
prefer XEP-0280 to treat them just like messages sent to full JIDs.

By the way: As RFC 6121 basically allows the server to "fork" all bare
JID messages to all resources it sees fit, the server would still be
free to implement the current XEP-0280 behaviour by means of RFC 6121
even if section 6 of XEP-0280 was removed.²


¹ http://xmpp.org/rfcs/rfc6121.html#rfc.section.

² With the exception that XEP-0280 also allows delivery to resources
  with negative priority, but meh.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4596 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140425/d11eeb54/attachment.bin>

More information about the Standards mailing list