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. /K
