On 6/22/16 10:06 AM, Georg Lukas wrote:
* Peter Saint-Andre <[email protected]> [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/>.
Peter
_______________________________________________
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
