Hi Kev, * Kevin Smith <[email protected]> [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: https://mail.jabber.org/pipermail/standards/2015-September/030288.html and a possible conclusion in https://mail.jabber.org/pipermail/standards/2015-September/030341.html 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 language. > [...] 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 reconnect. 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. Georg -- || 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 ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
