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

Florian Schmaus flo at geekplace.eu
Thu Sep 17 10:12:52 UTC 2015


On 16.09.2015 23:26, Dave Cridland wrote:
> On 16 September 2015 at 22:21, Florian Schmaus <flo at geekplace.eu
> <mailto:flo at 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.

If we don't fix it right now, we will potentially never get another
chance to fix it.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150917/43c24dc9/attachment.sig>


More information about the Standards mailing list