[Standards] Carbons - inbound messages to bare jid
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.²
² With the exception that XEP-0280 also allows delivery to resources
with negative priority, but meh.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4596 bytes
Desc: not available
More information about the Standards