On 17 September 2015 at 11:12, Florian Schmaus <[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]>> 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. <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? (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 > >
