[Standards] XEP-0280: <private/> vs. <no-copy/>

Dave Cridland dave at cridland.net
Wed Sep 16 21:26:06 UTC 2015


On 16 September 2015 at 22:21, Florian Schmaus <flo at geekplace.eu> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150916/38f943e1/attachment.html>


More information about the Standards mailing list