> On Oct 10, 2015, at 2:58 PM, Matthew Wild <[email protected]> wrote: > > After various discussions, including here at the summit, I'm seeing a > rough consensus that the <private/> element in Carbons or the > ~equivalent <no-copy/> hint in XEP-0334 cause more trouble than they > are worth. > > The only use-case I've been able to find is preventing OTR messages > from being received by clients that cannot decrypt them. It is > debateable whether receiving garbage is worse than not knowing that > someone is trying to contact you on another resource. > > As the elements are basically only a workaround for OTR, and OTR is a > hack, and OTR has its own methods to solve this issue, one could argue > that we shouldn't be using these elements. > > Does anyone have strong feelings about this?
Aside from OTR specific issues.... and whether there's actually any use case for this: my view is that <private/> is best used by a carbon-requested client to tell its server not to carbon particular stanzas to its other clients (sharing the same bare JID).... whereas <no-copy/> is a hint to any server who might be making copies. The former should be trimmed at the sender's client server (assuming it supports carbons). The latter isn't. Otherwise we're in-tangling security considerations.... > > Regards, > Matthew > > PS. I don't want to get this discussion tangled up with the > advancement of Carbons, right now I'd rather just determine whether > these elements are useful or not.
smime.p7s
Description: S/MIME cryptographic signature
