[Standards] LAST CALL: XEP-0280 (Message Carbons)
georg at op-co.de
Wed Jun 22 16:06:02 UTC 2016
* 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. Then it is in the responsibility of the MUC service to
deploy whatever Multi-Session-Nick magic it has and to send copied
messages to all joined clients.
> 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. 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:
And it looks like people all have their strong opinions on how to
proceed, maybe this needs to be voted upon?
|| 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