XEP-0280: Rewrite of the 'Messages Eligible for Carbons Delivery' section

[ge0rg]

Hi,

this PR combines multiple changes, again ordered by level of controversy.

• aac8f94 Removal of the private element, as +1ed by @linuxwolf on standards@ - this requires a version bump IMO, as it changes the server behavior when parsing messages with only the private element present.
• f0e432c Improvement of the "Messages Eligible for Carbons Delivery" section that conveys the same set of rules in less words
• 7f529e1 addition of clear MUC / MUC-PM instructions, as suggested on standards@
• c60ec80 minor wording correction to accomodiate the above changes
• 9c388a5 controversial change of the "Messages Eligible for Carbons Delivery" languge from "serves MAY do this" to "servers SHOULD do this" (based on field experience with running Carbons in the wild). The language in the old XEP is very vague and non-binding, and this patch attempts to make clearly defined rules for clear use cases, so that clients can expect consistent behavior (even though they may not rely on it).

If we are doing a version bump, we should make the most out of it (without nonzas, at least).

[ge0rg]

Rendered version: https://op-co.de/tmp/xep-0280.html#which-messages

[ge0rg]

This is not the final set of changes yet to make everything perfect.

I'm pondering about adding these two rules:

• carbon-copy bodyless messages containing a 0184 ack
• carbon-copy bodyless messages containing a 0333 chat marker

But maybe those two XEPs need to be fixed up to mandate type=chat?

[ge0rg]

Another open issue that just came up on xsf@/gajim@ MUC is messages-to-self. I've sent a problem statement to standards@.

[tfar]

@ge0rg Are you proposing these changes to be merged? Could you open a thread on standards ML to have them discussed please? Ta.

[ge0rg]

The relevant standards@ threads are linked above, and there even was some discussion on them.

However, in the meantime it looks like the council -1ed XEP-0334 (Message Processing Hints), which was the excuse to bump the Carbons namespace. Council discussion:

https://mail.jabber.org/pipermail/standards/2017-April/032583.html and followup discussion

I'm really not sure how to move forward from here. While I don't care much about which hint is to be added into the messages, I really want to make the Carbons rule properly specified, and I'm not sure this would be possible without a bump.

[SamWhited]

In the council meeting today Kev brought up starting a document (details to TBD) that will explore the routing rules of XMPP, where the problems are, and how they can be solved. In light of this, are you okay with closing this PR @ge0rg and waiting on the results of that document? Hopefully we'll have a better idea of what needs to be done afterwards and this discussion will be a bit easier. Naturally this PR can be reopened if we decide that its rules are the correct ones.

[ge0rg]

I'd prefer to keep this open as a reminder of the unsolved problem, but whatever works for the editor team is OK with me.

[horazont]

I prefer to have this closed, to be honest. I don’t like having a baseline of open PRs.

I also don’t think that the PRs in the xeps repository are necessarily a good place to keep reminders about open problems, unless a concrete solution is proposed. That solution is then either merged or rejected. I think in this case, when we agree that this is part of a broader scope and must be solved e.g. in coherence with MAM and MR2.0, this should be closed.

Feel free to reopen if you disagree about the last part.