In one of our chat clients we have developed it is possible for a user to have what amounts to multiple conversations occurring at the same time with a single other user (I.e. In our case a user can have multiple chat tabs open to another user).
Reading the 301 spec, there doesn't seem to be any way to relate the rtt messages to the final message other than the sequence they are received. It's worth noting that I think there would be ways around it in our specific case, but there may be a more general case where a user is able to edit multiple messages to a single user/room at once, thereby sending multiple interlaced streams of rtt data. I'm not sure this is actually worth adding to the protocol now since I doubt there are very many implementations where this would be required, but I thought I would just mention it. Ash From: Mark Rejhon <[email protected]> Reply-To: XMPP Standards <[email protected]> Date: Friday, 22 June 2012 20:56 To: XMPP Standards <[email protected]> Subject: [Standards] Comments Needed: Upgrading XEP-0301 to Draft. (In-Band Real Time Text) Short Version: We want to upgrade XEP-0301 (Real Time Text) from "Experimental" Status to "Draft" Status. I'd like to hear your comments, edits for http://www.xmpp.org/extensions/xep-0301.html I've already notified Peter. I'd like everybody's comments -- feel free to reply Detailed Version: (for those unfamiliar) Real-time text is text transmitted instantly while it is being typed or created. The recipient can immediately read the sender's text as it is written, without waiting. In addition, it is a very useful mode of communications for the deaf too, especially those who cannot use the phone, so this is a standard that enhances accessibility of XMPP chats. It is a fun enhancement for main stream instant messaging, for whenever recipients are in a more chatty mood, too -- plus, the accessibility nature makes it interesting to accesibility purposes, such as text-to-9-1-1 emergency service for people who cannot use the phone, etc. Our group (www.realtimetext.org <http://www.realtimetext.org> ) is now working to solidify XEP-0301 so it can be upgraded to Draft status, given the recent use of evaluations of XEP-0301 for Next Generation 9-1-1 (including at the FCC text-to-911 demo) as well as inquiries coming in from various Accessibility organizations. The upgrade from "Experimental" status to the next step ("Draft") would be a huge step. It is my (author's) opinion that the standard is almost ready, with just a bunch of minor corrections and fixes. At least three different implementations are now available publicly, more to come, and at least a few private (internal) implementations being demoed. If you just need a quick basic understanding without reading the whole standard yet, A good introduction is written in the section 1 & 2 of http://www.xmpp.org/extensions/xep-0301.html If you want to a webpage about what Real-Time Text looks like: Animation at http://www.realjabber.org/real_time_text_demo.html If you want to try it out: There is a RealJabber installer from www.realjabber.org <http://www.realjabber.org> -- it is a simple Google Talk client (for Windows) I wrote that implements XEP-0301 If you need to view open source code: Full RealJabber: http://code.google.com/p/realjabber/ <http://code.google.com/p/realjabber/source/browse/trunk/CSharp/RealTimeText .cs> C# XEP-0301 module: http://code.google.com/p/realjabber/source/browse/trunk/CSharp/RealTimeText. cs Java XEP-0301 module: http://code.google.com/p/realjabber/source/browse/trunk/Java/src/RealTimeTex t.java <http://code.google.com/p/realjabber/source/browse/trunk/Java/src/RealTimeTe xt.java?r=20> Note that the Java version implements Version 0.1 of the standard and the C# implements Version 0.2. Both still interoperate with each other, thanks to the backwards compatibility. All code is Apache 2.0 open source code license, commercial use allowed. I'd like your comments on changes, edits, revisions, corrections, improvements, those that you think would be widely agreed changes. Currently queued corrections/revisions below: Section 7.9: Last action element has missing tag closer: <t p='12'> should be <t p='12'/> Section 7.7: "Cursor Pos" should be "Cursor Position" Section 7.7: Reword the sentence about cursor position, for clarification. Section 7.8: Clarify the phrase "The seq attribute always increments.", because seq can change whenever there's a different 'event' attribute. Section 7.9: Reword sentence "In order to maximize precision..." for clarity Section 1 - Replace first two sentence with agreed consensus: Real-time text is text transmitted instantly while it is being typed or created. The recipient can immediately read the sender's text as it is written, without waiting. Section 4.5.2 - Rename "Rules for Attribute Values" into "Summary of Attribute Values" for better consistency with "Summary of Action Elements" Section 4.5.5 - Error: U+1FFFF should be U+10FFFF Section 4.6.3 - Add "or" to end of first bullet. Section 4.6.3 - Turn number bullets into dot bullets because it isn't a sequence of events. Section 4.6.4 - Change "in the following situations" to "in any of the following situations" Section 6.1.2 - Add a link to [[[Monitoring Message Edits]]] Section 6.1.3 - Change "to monitor or transmit" into "to transmit" Section 6.1.3 - Change "for transcription." into "for real-time transcription." Section 6.3.1 - Change "after an action element" to "after processing an action element" Section 6.4.1 - Mention "(such as rapid copy and pastes)" Section 6.4.1 - Missing auto-transmit text? (this appears to be a regression error) Section 6.2 - In general, could be better & more concise eventually Section 8 - This could be more clear and compact, with more efficient wording. There is too much fluff words. Phrases are repeated (i.e. second paragraph in 8.2 repeats phrases already written in the first paragraph of sectoin 8). Reword into more efficient and does not mention NG911 interop. Section 7: Examples can be improved/expanded to be easier to understand. I've got some comments of some of the inadequacy of some of the examples. Section 6.1.4: Improve wording about eliminating <w/> elements Section 6.1.4: Investigate changing title "Reduced Precision Text Smoothing Methods" into "Bandwidth and Precision Reduced Text Smoothing" Section 4.1, 6.4.1: Replace "chat message" with "message". (produces confusion) Section 8.1 change: "it is generally recommended to use the real-time text specification of the specific session control standard in use for that particular session." INTO: "it is generally recommended to use the real-time text specification that is most appropriate for that particular session." Section 8.2 change: ". . .Another reason is that SIP is the currently dominating peering protocol between services, and many implementations of real-time text in SIP exist." INTO: ". . . Another reason is that SIP is the currently dominating real-time session control protocol and many implementations of real-time text controlled by SIP exist." For other further suggestions to modifications to http://www.xmpp.org/extensions/xep-0301.html please let us know, Thanks Mark Rejhon Author of XEP-0301
