Okay, time to unify the "protocol simplification" subject this into one message. The agreement more-or-less is that the the XMPP Real Time Text specification will continue to use a transform-based mechansim because of the clear advantages.
First: From what I can see, it looks like I am able to chop at least 40% of non-boilerplate text (including splitting out implementation details into Implementation notes) with only extremely minor modifications to existing experimental software (keep seq/msg/type attribute, keep all edit code transforms). Those of you who saw an example pasted source code, realize that the coding is actually simpler than the specification itself. However, there's still an incentive to simplify the XMPP Real Time Text protocol even further, to simplify the spec even further. Some areas that's already been discussed, and some areas that not yet been discussed, I'll now consolidate into one message. __________ Proposed Real Time Text Protocol Changes -- Merge the Backspace/Delete edit code transform? A backspace could be done by using a delete operation with repositioned cursor. (or vice versa). The intent to include both was to make it easy to use the keypress-recording technique of real time text. (If an implementor decides not to use the before-and-after text compare method to generate the edit code transforms) LEANING: Undecided -- Remove the Reset code? <r/> This code is really simple, and this code is transmitted if the user clears their message before sending. LEANING: Keep code -- Removal of support for multiple <rtt> in one <message> This is a no-brainer and there's unamious agreement by everyone on this. LEANING: Remove this -- Keep or modify the "seq" attribute? Changes to missing message detection algorithm? This is absolutely required, based on our tests. We need to run over existing networks on existing servers. Currently I use the 'seq' attribute. There are other options like parsing the <message> id, since Google Talk appends an incrementing number to it. But not all XMPP implementations do that. Alternative methods is to use CRC or checksums, to check integrity of the post-transform message, to detect that we've missed an edit transform. LEANING: Keep "seq" -- Keep, simplify or remove the "type" attribute? This signals clearing the real time text and starting a new blank real time text line. It is good for resetting too as well. In theory, you can use messages with <body> to do the same signal instead. This attribute becomes more critical if I change the seq to a checksum instead. Another alternative is to parse the message for a reset code <r/>, but that makes implementation more complex. LEANING: Keep "type", but simplify to use only type='new' instead of type='reset'. -- Remove the 'msg' attribute? This is not necessary for the functioning of real time text. It will slightly downgrade error recovery capabilities, but this isn't a big concern if we keep 'seq'. On the other hand, 'msg' definitely keeps the door open for retroactive message editing (which I may still do as a private extension for a niche clients). I can also, additoinally, simplify the requirements for the 'msg' attribute by not talking about it as much. It could even be renamed to an 'id' attribute and use a string, too, but using a number is equivalent to using a line number. LEANING: Remove "msg"; but allow it to be usable as an undocumented extension for special-market software. NOTE: If I remove, we lose a good opportunity to standardize a potential method of retroactive message editing (collaborative text editing)!!! -- Support for group chat. The protocol can certainly later extended to support group chat, but I am going to skip including this in this spec. It could be reintroduced at a future time, if necessary, if interoperability is required. LEANING: Remove support for group chat. -- Simplify, change or remove protocol negotiation? It'd be nice to delete a whole section of the spec, actually. But there are caveats. Protocol negotiation is actually not necessary for XMPP Real Time Text. It actually works if I start blindly sending real time text. But this makes implementation of turning it on/off on both sides simultaneously difficult. (Both ICQ old splitscreen, and AIM real time text, used an "initiation" procedure). I'd like comments about the idea of eliminating protocol negotiation for XMPP Real Time Text. (Including interoperability concerns about legacy systems). Removing protocol negotiation may make negotiation of real time text simpler for a future theoretical group chat extension, and have better scalability. Also, if I remove protocol negotiation, the disadvantage is that one-sided real time text can occur, with one party sending real time text, and the other party not sending real time text because the user turned that off due to wanting privacy of entering text? There are definitely some situations where it may be useful for future group chat extensions, where only the 'lecturer' is allowed to transmit real time text -- useful for educational settings, online business meetings focussed on one speaker, or conference settings. There are a lot of cans of worms keeping protocol negotiatoin, and a lot of cans of worms removing protocol negotiation. LEANING: Undecided. I feel more discussion is needed. For now, I'll keep until I'm almost done with other things. Please chime in! Thanks, Mark Rejhon
