[Standards] Carbons - inbound messages to bare jid
georg at op-co.de
Tue Apr 29 10:15:14 UTC 2014
[this is a slightly modified version of a message that got lost in moderation]
* Thijs Alkemade <thijs at xnyhps.nl> [2014-04-25 16:02]:
> Thinking about this a bit more, I actually disagree with this proposal.
I second the suggestion to remove or strongly reword section 6. It
should keep a reference to XMPP-IM forking, and mandate that no more
than one copy shall be sent per resource, however not enforce forking
A carbons-enabled client is able to handle incoming carbons anyway, and
having different semantics for bare- vs. full-JID messages only makes
matters more complicated.
> 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.
This is actually horribly under-defined in XEP-0280. Generally, a client
should make less intrusive user notifications on incoming carbons
(compared to regular chat messages). However, there are many situations
where the sender's resource locking mechanism fails, and you do not see
an important message that was directed to you, because your client only
got a carbon copy of it and did not notify you.
Therefore, yaxim deploys a complicated logic to make a notification
sound on the first(*) incoming carbon message, and on all regular
(*) The counter is reset whenever the user opens the chat window for the
> 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 fails to account for clients (like yaxim) that do not implement
resource locking and instead always address the bare JID, relyin on the
Also, the first-message-is-special semantics is essentially achieved
by the above application-level logic, with the bonus feature that a user
hopping his clients (i.e. when he goes out of his home) has a higher
chance to notice a new message, even if it was sent to his home
> 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.
On the other hand, the XEP currently requires server logic (and state!)
to distinguish XEP-0280-forked bare-JID messages from other bare-JID
messages, to allow error inhibition according to section 10.3
That state keeping could be avoided if a server only needs to inhibit
errors for <forwarded> stanzas.
|| http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++
|| gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ ||
|| Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 811 bytes
Desc: Digital signature
More information about the Standards