On 17 Aug 2015, at 14:37, Kevin Smith <[email protected]> wrote: > > On 13 Aug 2015, at 09:51, Kevin Smith <[email protected]> wrote: >> >> On 12 Aug 2015, at 15:44, Ralph Meijer <[email protected]> wrote: >>> * Could your envisioned changes be add-on instead? I.e. is there a chance >>> of future proofing this (now)? >> >> Ralph’s mail led to me thinking what the minimum necessary change would be >> to allow future proofing, so thanks to Ralph for asking the right question. >> There are two basic issues I see: >> >> 1) type=normal needs to be carboned too in various circumstances (but not >> blindly, because of IBB and things). >> 2) There has to be scope for the rules being changed in the future (without >> negotiation) as new specs are written that may influence what should and >> shouldn’t be carboned. As 280 stands, one could implement a client by the >> letter of the spec that later had interop issues if what was carboned >> changed. For example, we need to have a path to mamsub-style carbons in the >> future. I believe the answer is this (and have run it past Ralph, Sam, Dave, >> Georg and others already). >> >> I think we say "The server should carbonise chat and IM-related messages, >> definition of which is an implementation detail, but is expected to be >> something like type=chat and those type=normal with a body, maybe not from a >> MUC. It is possible for future specs to define rules that override these, >> and such new schemes will be defined, including a negotiation mechanism, in >> other specs such that a client doing vanilla 280 can expect this to be >> IM-only. Without further negotiation a client can't rely on precisely what >> will be carbonised." and we're largely covered. I think that leaves the door >> wide open for mamsub, and also for any tweaks needed to support the other >> things going on, like MUC2 or PubsubAccount, or just trying to silently fix >> MUC1 PMs. >> >> If there are other schemes like mamsub in the future, it is reasonable to >> enable them with a different mechanism, such as a different iq, or some >> atomic query-and-enable-carbons iq or whatever. Such schemes might much >> more formally define precisely which messages are carbonised (e.g. ‘every >> message that goes into the MAM archive that you have not otherwise received, >> including reflection of your own messages, which is what I’m dubbing >> mamsub’). >> >> Lance then checked existing server implementations, and it seems that most >> aren’t compliant anyway, ignoring that carbons should only be for chats, and >> doing it for normal. Which leads me to think that any existing client >> implementations must cope with this, and we can avoid a namespace bump for >> the above change. Unless anyone objects, I’ll submit a PR updating the XEP >> along these lines. On the basis that implementations won’t need to change as >> they’re closer to the new text than complying with the old text, I think we >> would be able to move to Draft in Not Very Long after the new version is >> published. > > I have attempted to capture this in > https://github.com/Kev/xeps/commit/a48df19308f442c8f7239b2b2c70530613550ff5 > Can people please review, and I’ll then submit if people don’t think it fails > to capture the discussions.
After discussion in the XSF MUC, I’ve pushed another change, so probably best to track via the https://github.com/Kev/xeps/commits/carbons branch. /K
