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

Kurt Zeilenga kurt.zeilenga at isode.com
Wed Sep 23 17:14:24 UTC 2015


> On Sep 23, 2015, at 8:34 AM, Dave Cridland <dave at cridland.net> wrote:
> 
> 
> 
> On 17 September 2015 at 11:12, Florian Schmaus <flo at geekplace.eu <mailto: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>
> > <mailto: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.


I can think of many good reasons why a server might want to deliver the message…  

This has MY server trusting some other client (and possibly other servers) to specify <private/> in some way that doesn’t interfere with MY use 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?

<no-copy/> at least for senders which don’t have the same bare jid as the client which requested the carbons. 

That is, I think if I don’t want carbons for traffic I produce, then <private/> semantics with a SHOULD NOT would be okay.

But for traffic coming from other bare jids, <private/> should be ignored and but <no-copy/> treated as hint (as intended).

> 
> (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/5e14ce5e/attachment.html>


More information about the Standards mailing list