On 22.06.2016 18:16, Peter Saint-Andre wrote: > On 6/22/16 10:06 AM, Georg Lukas wrote: >> * Peter Saint-Andre <stpe...@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.
+1 >>> 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. +1 >> 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. Exactly. > 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/>. A generic element like <no-copy/> makes much more sense then <private/>. E.g. the new OpenPGP XEPs use the <store/> hint of xep334. Your approach of removing the controversial parts seems like a handy compromise, but Matthew's suggestion at http://mail.jabber.org/pipermail/standards/2015-September/030341.html appears to be something we all could agree on, no? I also still think that we should clarify somewhere if the carbons state is kept after a stream resumption or not [1]. Not sure if the right place for this would be xep280 or xep198. - Florian 1: http://mail.jabber.org/pipermail/standards/2015-August/030221.html
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
