On 23 September 2015 at 18:14, Kurt Zeilenga <kurt.zeile...@isode.com> wrote:
> > On Sep 23, 2015, at 8:34 AM, Dave Cridland <d...@cridland.net> wrote: > > > > On 17 September 2015 at 11:12, Florian Schmaus <f...@geekplace.eu> wrote: > >> On 16.09.2015 23:26, Dave Cridland wrote: >> > On 16 September 2015 at 22:21, Florian Schmaus <f...@geekplace.eu >> > <mailto:f...@geekplace.eu>> 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). > > Oh, hmmm - is that saying you'd like both, but <private/> should be outbound only? > > (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 >> >> > >
