<p dir="ltr">Right; this is what we intended the semantics to be.  I think the other proposal is not a good idea.<br></p>
<p dir="ltr">- m&m<br>
{mobile}</p>
<div class="gmail_quote">On Apr 25, 2014 6:58 AM, "Thijs Alkemade" <<a href="mailto:thijs@xnyhps.nl">thijs@xnyhps.nl</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 25 apr. 2014, at 13:32, Kim Alvefur <<a href="mailto:zash@zash.se">zash@zash.se</a>> wrote:<br>
<br>
> Hello,<br>
><br>
> It has been brought up that my Carbons implementation does not follow<br>
> the Receiving Messages to the Bare JID¹ section.  This section says<br>
> include carbons-enabled sessions in the normal forking of messages as<br>
> described by XMPP IM².<br>
><br>
> What I implemented was instead to send carbons-wrapped messages to<br>
> carbons-enabled sessions that would not already receive them based on<br>
> the XMPP IM rules.  So a message will always be carbons-wrapped if it<br>
> was sent because carbons was enabled.  I believe this makes sense, does<br>
> anyone else?<br>
><br>
> ¹ <a href="http://xmpp.org/extensions/xep-0280.html#inbound-bare" target="_blank">http://xmpp.org/extensions/xep-0280.html#inbound-bare</a> (version 0.9)<br>
> ² <a href="http://xmpp.org/rfcs/rfc6121.html#rfc.section.8.5.2.1.1" target="_blank">http://xmpp.org/rfcs/rfc6121.html#rfc.section.8.5.2.1.1</a><br>
<br>
Hi Kim,<br>
<br>
Thinking about this a bit more, I actually disagree with this proposal.<br>
<br>
The semantics of receiving a carbon copy should be "hey this other resource<br>
has a conversation going, here's a copy of this message in case you want to<br>
follow along". That might imply, for example, that the client uses a different<br>
way of notifying the user: the user might have configured their client to not<br>
make a sound when receiving a carbon copy, as multiple devices making sounds<br>
gets annoying.<br>
<br>
A bare-JID message is a different situation. Sending one implies the sender is<br>
looking for a resource that will reply to start a conversation with it, so for<br>
these I think it would be fine if a carbons-enabled client notifies the user<br>
as if it were a normal message.<br>
<br>
Of course the client could add extra logic for this ("if it's a carbon copy,<br>
and the first message we've seen from this user this session/hour/day, play<br>
sounds"), but I think doing it in the way that is currently in the XEP is a<br>
much cleaner solution.<br>
<br>
Regards,<br>
Thijs Alkemade<br>
</blockquote></div>