On Thu, Jun 28, 2012 at 8:03 AM, Ashley Ward <[email protected]>wrote:
> 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. > -- Actually, you can correspond separate RTT streams via full JID rather than the bare JID, and have multiple concurrent RTT's from the same user, either in the same window or in separate windows. So this problem is considered solved from the perspective of XEP-0301. It's also how you would treat MUC (groupchat) -- correspond RTT with each full JID. Even if the same user logs on multiple times into the same chatroom from multiple computers, and both computers were simultaneously sending RTT streams (i.e. having a family member type at the same time under the same account). Each real time message would have their separate buffer, for each full JID. This would work regardless of whether or not Resource Locking (XEP-0296) was implemented (there would be different behaviours, each individually acceptable, depending on the situation). -- In situations where it is a single JID (single login), it's likely a single application, and therefore typically only have one keyboard focus at a time (one textbox). You'd simply use section 4.6.4 (Message Retransmission) whenever the keyboard focus changes to the other conversation and you resume typing. So the real time text suddenly automatically refreshes to the correct sender text box of current focus. This may be acceptable behaviour, too. If neither is the solution for you, can you explain further? Thanks, Mark Rejhon > > 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) 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 -- 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/RealTimeText.java<http://code.google.com/p/realjabber/source/browse/trunk/Java/src/RealTimeText.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 >
