On 16 September 2015 at 22:21, Florian Schmaus <[email protected]> wrote:
> On 16.09.2015 16:33, Matthew A. Miller wrote: > > A pull request was submitted to remove <private/> and use the > > <no-copy/> processing hint: https://github.com/xsf/xeps/pull/83 > > A short remark about the changes of the PR: xep334 should be added to > the xep280 dependencies. > > Since it appears that xep280 is going to advance to draft and given that > xep334 is experimental: Can a draft xep depend on an experimental one? > That is a very good point. I'd rather not have dependencies which are unstable. > > > 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. Dave.
