On 3/3/11 12:58 PM, Mark Rejhon wrote: > Okay, time to unify the "protocol simplification" subject this into one > message.
Thanks. I've finally had time to read the proposal and this email thread, so first I'd like to make a few observations: 1. It seems to me that the real-time-text feature is very important to a few small classes of users (mainly deaf people, but perhaps also to certain users of specialized applications such as emergency services and hotlines). To everyone else, it is merely a curiosity. 2. Given that user profile, I'm less concerned about producing a more complex protocol *if* that is the only way to really optimize the experience for the target population(s). Naturally, if we can design a simpler protocol that gets the job done, we'll all be happier. 3. Do we really need feature negotiation and session establishment? It seems simpler to use disco and caps (XEPs 30 and 155) to see if the other side supports RTT, then just start sending messages. 4. We need to describe how RTT interacts with chat states (XEP-0085). 5. In several places the space defines multiple ways of doing the same thing (e.g., type='reset' and <r/>). Let's avoid that if possible. 6. I agree with most of the comments made in this thread about cleaning up the namespacing, moving the UI and implementation stuff to separate sections, not designing around out-of-order messages and packet loss in existing XMPP servers or deployed services, etc. > 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. Could you clarify what you mean by "transform-based mechanism"? I don't see that term in version 0.0.1 of the proposal. > 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). Why are we optimizing for backward compatibility with pre-alpha software? > 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 Here again I think it would be better to recommend one approach, or at least not reflect different implementation approaches in the protocol itself. > -- 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 See above about having two ways to do that same thing. > -- 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 +1 > -- 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" I have no strong opinion here yet. > -- 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'. Type is OK, but let's remove <r/>. > -- 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). We might not want to try to do everything in one spec. Small pieces loosely joined, and all that. > 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)!!! We already have that, see the spec for Shared XML Editing: http://xmpp.org/extensions/xep-0284.html If RTT really is just collaborative editing in another form, I think we'd want to investigate whether we can just use SXE. > -- 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. Yeah, this scares me somewhat -- although here again it might be useful for certain specialized user communities. (See arguments for and against chat state notifications in MUC.) > -- 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. I think we can cover almost all of the use cases with disco and caps. We prefer not to design for use cases we don't know about or can only imagine at this time. > Please chime in! Done. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
