Peter, Very good response to Mark's summary.
A small point regarding observation 1. No-one should re-create communication islands for Deafies. They communicate with more non-Deafies than Deafies so mainstream RTT is the way to go. Also, I see RTT as a feature that many young people would love to use (especially with their need for 'immediacy') which could create an extended market for XMPP. I like the idea of XMPP-RTT as it appears to meet both of those needs. And the Chat mode and RTT mode seem to sit well together - which is very important. Cheers, /Barry Barry Dingle Fellow of University of Melbourne, Electrical and Electronic Eng., Australia Fixed - +61(0)3-9725-3937 Mob - +61(0)41-911-7578 > Supporter of Linux + Open Source software On Fri, Mar 4, 2011 at 7:53 AM, Peter Saint-Andre <[email protected]>wrote: > 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/ > > > >
