Hello,
It has been brought up that my Carbons implementation does not follow
the Receiving Messages to the Bare JID¹ section. This section says
include carbons-enabled sessions in the normal forking of messages as
described by XMPP IM².
What I implemented was instead to send carbons-wrapped
Hi,
Ive recently implemented XEP-280 for Openfire and have to say I like the bare JID behavior as it is.
I dont see a reason to wrap the message in a forwarded extension for the bare JID case.
Its easier for clients to use carbons, because they dont need to modify their message logic
On 25 apr. 2014, at 13:32, Kim Alvefur z...@zash.se wrote:
Hello,
It has been brought up that my Carbons implementation does not follow
the Receiving Messages to the Bare JID¹ section. This section says
include carbons-enabled sessions in the normal forking of messages as
described by
Right; this is what we intended the semantics to be. I think the other
proposal is not a good idea.
- mm
{mobile}
On Apr 25, 2014 6:58 AM, Thijs Alkemade th...@xnyhps.nl wrote:
On 25 apr. 2014, at 13:32, Kim Alvefur z...@zash.se wrote:
Hello,
It has been brought up that my Carbons
* Christian Schudt christian.sch...@gmx.de [2014-04-25 14:10]:
I've recently implemented XEP-280 for Openfire and have to say I like
the bare JID behavior as it is.
I don't see a reason to wrap the message in a forwarded extension for
the bare JID case.
I'd prefer to omit this special
* 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
Hi Peter,
At 16:18 08-04-2014, Peter Saint-Andre wrote:
Before we released the security note about application-layer
compression last week [1] (which now seems to have been overshadowed
by the heartbleed bug in OpenSSL), I started to work on some updates
to XEP-0138. Here is my proposed text
