> On Sep 23, 2015, at 8:34 AM, Dave Cridland <[email protected]> wrote: > > > > On 17 September 2015 at 11:12, Florian Schmaus <[email protected] > <mailto:[email protected]>> wrote: > On 16.09.2015 23:26, Dave Cridland wrote: > > On 16 September 2015 at 22:21, Florian Schmaus <[email protected] > > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > The last time this came up, many many months ago, I recall there not > > > being consensus to change. But that was then and this is now. > > > > > > What are implementers doing today? > > > > > > * Are implementations using XEP-0280's <private/>? > > > * Are implementations using XEP-0334's <no-copy/>? > > > > Smack's doing <private/> > > > > > * Are implementations supporting both, but favoring XEP-0334's > > <no-copy/>? > > > > I would switch to xep334 in an instant. Kurt has a valid point about > > xep334 <no-copy/> being not as strict as <private/>. Hence I think we > > should change that bit in xep334 and incorporate the semantics of > > xep280's <private/>. > > > > > > The point of '334 is that it's pure a hint and cannot be relied upon to > > provide any particular behaviour. > > > > I think changing that would probably be a mistake. > > > > Despite your argument to the contrary, I think you and Kurt have > > convinced me that we should keep Carbons (and <private/>) as-is. > > I get your point. But it feels wrong to define nearly identical > extension elements in two XEPs. The author of xep334, Matthew Wild, > already expressed his willingness to change xep334 so that it can be > re-used in xep280. Therefore I'm all for changing xep334, then issue a > last call for it, ideally advance it to draft, then issue another last > call for a xep280 version using xep334 elements, and finally advance it > to draft. > > > So summarizing... > > Procedurally: > > If we don't switch, then Carbons goes through to Draft now, and Hints either > loses <no-copy/> or has a duplicate with softer requirements. > > If we do switch, then Carbons is delayed and has a version bump, and Hints > needs editing and goes through Last Call to Draft. > > Technically: > > <private/> is a mandatory part of Carbons.
I can think of many good reasons why a server might want to deliver the message… This has MY server trusting some other client (and possibly other servers) to specify <private/> in some way that doesn’t interfere with MY use of carbons. > > <no-copy/> is an expression of opinion from the sender that Carbon copying > and similar will not be useful or desirable. > > Which semantics make more sense? <no-copy/> at least for senders which don’t have the same bare jid as the client which requested the carbons. That is, I think if I don’t want carbons for traffic I produce, then <private/> semantics with a SHOULD NOT would be okay. But for traffic coming from other bare jids, <private/> should be ignored and but <no-copy/> treated as hint (as intended). > > (And by the way I'd rather rephrase XEP-0334 in that way). > > If we don't fix it right now, we will potentially never get another > chance to fix it. > > Not really true, we get to wonder if <no-copy/> is useful in the face of > <private/> at a later date. > > But even if you were right, and certainly some options close on this > decision, there is the question of whether this actually matters much. > > The only path I strongly object to would be making any of XEP-0334's Hints > have mandatory (or even recommended in the RFC 2119 sense) behaviour. > > > - Florian > >
