[Standards] On 'private' and 'no-copy'

Kurt Zeilenga kurt.zeilenga at isode.com
Sun Oct 11 15:00:03 UTC 2015


> On Oct 10, 2015, at 2:58 PM, Matthew Wild <mwild1 at gmail.com> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3803 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20151011/74cd0112/attachment.bin>


More information about the Standards mailing list