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

Dave Cridland dave at cridland.net
Wed Sep 23 15:34:26 UTC 2015


On 17 September 2015 at 11:12, Florian Schmaus <flo at geekplace.eu> wrote:

> 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.
>
>
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150923/8f9e5ba5/attachment.html>


More information about the Standards mailing list