* Thijs Alkemade <th...@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.² Holger ¹ http://xmpp.org/rfcs/rfc6121.html#rfc.section.8.5.2.1.1 ² With the exception that XEP-0280 also allows delivery to resources with negative priority, but meh.
smime.p7s
Description: S/MIME cryptographic signature
