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. If we don't fix it right now, we will potentially never get another chance to fix it. - Florian
signature.asc
Description: OpenPGP digital signature
