[Standards] Carbons - inbound messages to bare jid
holger at zedat.fu-berlin.de
Fri Apr 25 13:04:07 UTC 2014
* Christian Schudt <christian.schudt at 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 casing of messages received to bare JIDs
from XEP-0280; i.e., my proposal would be to remove section 6 in favor
of treating those messages just like messages received to full JIDs.
Unless I'm overlooking something (which may well be possible of course),
it complicates the XEP for no good reason.
I've implemented¹ the wrap-all-messages behaviour for ejabberd just like
Zash did for Prosody, as it would be pretty hard to get the special
casing of bare JIDs right in an ejabberd module. One of the issues this
would introduce is mentioned in section 10.3 of the XEP itself:
| When a receiving server attempts to deliver a forked message, and that
| message bounces with an error for any reason, the receiving server
| MUST NOT forward that error back to the original sender. The
| receiving server SHOULD use the sent element in the bounce to
| determine that an error is from a forked message.
It no doubt makes sense to suppress error bounces for carbon copies, but
a forked message that was received to a bare JID won't *have* a <sent/>
element as per section 6; so AFAICS, the XEP is inconsistent here.²
> It's easier for clients to use carbons, because they don't need to
> modify their message logic (i.e. unwrap the forwarded message etc.).
Huh? Clients that support XEP-0280 must add this logic anyway, in order
to handle messages sent to full JIDs. Or am I misunderstanding your
In my view, it's clearly a feature if clients can treat carbons sent to
bare JIDs just like carbons sent to full JIDs (e.g., they might want to
omit notifications for carbon copies or whatever).
² I'm extra confused by the fact that section 10.3 just talks about
"forked" messages specifically. Elsewhere in the XEP, these are
distinguished from "wrapped" messages. Only the latter would have a
<sent/> element, but they aren't mentioned in section 10.3. As
always, I may well just be misunderstanding these things.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4596 bytes
Desc: not available
More information about the Standards