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