[Standards] XEP-0280: <private/> vs. <no-copy/>
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
> > > 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
> > 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 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.
<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...
More information about the Standards