[Standards] XEP-0280 (Carbons) proposals

Georg Lukas georg at op-co.de
Thu Jun 1 11:51:30 UTC 2017

Hi Kev,

* Kevin Smith <kevin.smith at isode.com> [2017-06-01 12:39]:
> I promised to review and start a thread on the pending PR for Carbons updates

Thanks very much for reviewing it :)

> Removing no-copy:
> I think this goes beyond just removing no-copy, and makes what was
> before a hint by the client now normative. While hints are fine, I
> don’t think mandating this behaviour is right.

The <private> element was normative initially, then XEP-0334 appeared
with a hint, then there were multiple long discussions about using or
not using 0334 in Carbons, e.g:

and a possible conclusion in

And then 0334 was -1ed by council, so it looks like we are back to
normative <private/>. I don't have stakes in this game, but I want to
make Carbons a better XEP. For me, either <no-copy/> or <private/> or
even both of them will work, on the client side.

> MUC rules:
> https://github.com/xsf/xeps/commit/7f529e1fb8841cdc16b122bb62539f8e727650b0
> I think the ‘must’ here is misplaced,

I'd be fine with a 'needs to' as this is a rationale, not normative

> [...] giving the user the option to join the MUC on this client too
> seems quite a sensible alternative.

This is a good catch, I haven't thought about that. I will change the
wording to allow a more flexible handling; my major issue was that
without joining, the client techically can't respond to that message.

> Requiring servers to implement particular delivery rules:
> https://github.com/xsf/xeps/commit/9c388a51c61541507c599832038b6562f3d01841
> I don’t think this is right, I think we want to allow servers to make
> their own judgements on what needs carbonsing. This was the consensus
> compromise we made previously (after considerable effort) to remove
> the objections to 280 going to Draft. 

I have to disagree. The current wording is inadequate for a network
protocol specification: it does not provide any consistency between
implementations, leading to subtle differences in observed behavior and
to user confusion.

Carbons is now over seven years old, so all server implementations
should have figured out their rules by now, or at least a set of rules
which we can make mandatory. I can see how creating such a mandatory
rule set might have been an issue back at the inception of the XEP, but
right now, we should have the accumulated knowledge to nail it, finally.

I've deliberately used 'SHOULD' in the text so that it is not impossible
for server implementations to deviate. If there are specific change
requests to be made or rules to add, I'd love to prepare according PRs.

Actually, there are two other open issues with Carbons rules that are
not yet addressed by the PR: consistency with MAM and bodyless messages:

MAM defines its own set of rules for what is eligible (and relies on
XEP-0334 for exceptions). The MAM rules are different from the Carbons
rules, so that a MAM+Carbons client will receive different sets of data
depending on whether it's connected "live" or catching up after a

Modern clients send bodyless messages with 0085 CSNs and 0184 ACKs to
provide additional communication metadata. There is value in
carbon-copying both of these message types, but there might be existing
use-cases for bodyless messages where carbon-copying would do harm.
Because I don't know all the use-cases for bodyless messages, I struggle
to provide a rule for how to handle CSNs and ACKs.

|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170601/4a0bf749/attachment-0001.sig>

More information about the Standards mailing list