[Standards] LAST CALL: XEP-0280 (Message Carbons)

Ruslan N. Marchenko me at ruff.mobi
Mon Feb 13 18:29:07 UTC 2017


On 13.02.2017 15:29, Georg Lukas wrote:
> * Ruslan N. Marchenko <me at ruff.mobi> [2017-02-12 16:33]:
>> No, the no-copy use is ambiguous. Are private and no-copy equivalent? Are
>> they complementing each other? what is the server behaviour when only one of
>> them is provided?
>> I personally am in favour of <private/> order for owner and no-copy hint for
>> remote party. And then - should server always strip <private/> before
>> routing? Should it replace it with <no-copy/> hint?
> This has been discussed already in the previous "last" call:
>
> https://github.com/xsf/xeps/pull/83
> and
> https://mail.jabber.org/pipermail/standards/2015-September/030288.html
>
> As there was no consensus two years ago, I just added both elements to
> 0280 in https://github.com/xsf/xeps/pull/382
>
> The rationale is to ensure widest compatibility without a namespace
> bump:
>
> - a client complying to the latest version adds both elements
> - a server interprets the message as no-carbons-please if either element
>    is present
>   
Thanks for clarification, but then still, why two? if <private/> is 
still required to avoid bump, why not to stick to that? Especially if, 
as it was pointed out in referenced thread - they have different 
semantic, but XEP expects them to provide same outcome within 
specification/implementation.
>
> I don't think there is a use-case where you only want to prevent a local
> forwarding to your other client, or only a remote forwarding to the
> receiver's other clients. For OTR at least, you want both.
>
>
> Georg
>
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170213/e2fb612d/attachment.html>


More information about the Standards mailing list