[Standards] LAST CALL: XEP-0280 (Message Carbons)

Peter Saint-Andre stpeter at stpeter.im
Wed Jun 22 16:16:47 UTC 2016

On 6/22/16 10:06 AM, Georg Lukas wrote:
> * Peter Saint-Andre <stpeter at stpeter.im> [2016-06-22 17:44]:
>>    A <message/> is not eligible for carbons delivery if it is
>>    determined to have been sent by a MUC room or service, even if it
>>    would be otherwise eligible (this also includes private messages
>>    from MUC participants).
> IMHO, this rule is more relevant than ever. A client that has enabled
> Carbons has no way to know to which MUCs other clients of the user are
> joined. Therefore, it has no sane way to participate in a MUC, and would
> misunderstand incoming MUC PMs for regular messages.
> If a client wants to receive the content of a MUC, it should explicitly
> join this MUC.

Aha, OK. I think it would be helpful to add a note about that in 
XEP-0280 so client developers know what to do.

>> 3. §10.3 uses the term "forked messages", but that term is not used
>> elsewhere. I suggest that we call these carbon copies or (as in §11)
>> forwarded copies.
> +1 for either carbon or forwarded. I think the notion "forked message"
> should rather be used for multiple deliveries by means of RFC 6121
> §8.5.3, or in the above MUC MSN PM scenario.
> The Carbons XEP introduced a <private/> element, which was later
> superseded(?) by XEP-0334 <no-copy/>. I'm not sure how many clients
> properly use either (or both), the main use case that comes to my mind
> is OTR, which is generally broken.

Does this not apply to other e2e encryption schemes?

> I'm not sure if LC is the correct
> place to address this issue, and whether it would be a good idea to kill
> <private/>. The respective discussion is here:
> http://mail.jabber.org/pipermail/standards/2015-September/030288.html
> And it looks like people all have their strong opinions on how to
> proceed, maybe this needs to be voted upon?

IMHO it would be good to settle this before moving XEP-0280 to Draft.

Specifically, if we don't have consensus on this point then I suggest 
that we remove <private/> for now, move the rest of Carbons to Draft 
(since there is no controversy there), and figure out what to do about 
<private/> vs. <no-copy/>.


More information about the Standards mailing list