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

Dave Cridland dave at cridland.net
Wed Sep 23 17:19:59 UTC 2015


On 23 September 2015 at 18:14, Kurt Zeilenga <kurt.zeilenga at isode.com>
wrote:

>
> 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> 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.
>
>
> 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).
>
>
Oh, hmmm - is that saying you'd like both, but <private/> should be
outbound only?

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


More information about the Standards mailing list