Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
On 2013-05-20 00:52, Peter Saint-Andre wrote: On 5/19/13 7:51 AM, Edward Tie wrote: Mark, It's done and ready for LAST CALL . Yes, I've already brought that to the attention of the XMPP Council, which is next meeting this Wednesday. Good. The issues in version 0.8 discussed in the list are solved. The existence of two well interoperating implementations in different technologies is a good extra indication of the maturity and implementability. /Gunnar Peter
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
I second the motion for last call. From my perspective as a JavaScript implementer, I consider the XEP-0301 document to be in good shape. Christian Sent from my mobile phone. Please excuse any touchscreen-induced weirdness. On May 18, 2013 1:45 PM, Mark Rejhon marky...@gmail.com wrote: On Sat, May 18, 2013 at 1:04 PM, XMPP Extensions Editor edi...@xmpp.orgwrote: Version 0.9 of XEP-0301 (In-Band Real Time Text) has been released. Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. Real-time text is text transmitted instantly while it is being typed or created. URL: http://xmpp.org/extensions/xep-0301.html There is now multiple open-source implementations of XEP-0301 to try: 1. Easy: Web based version. Just logon using Google credentials and chat XEP-0301 right away. http://tap.gallaudet.edu/rtt/ (This is a strophe.js JavaScript XEP-0301 plugin; Chris Vogler will release it on GIT shortly). 2. Downloadable C# client for XEP-0301 for Windows. http://www.realjabber.org/ They also interop with each other. There are also other prototype implementations (e.g. Gunnar's Omnitor, Indigital Inc., Gregg Vanderheiden's Trace Center), which are not listed here. Gallaudet Univerity's TAP (Technology Access Program) released the Javascript version of XEP-0301, showing real-time text streaming between web browsers. We all have unamious agreement that XEP-0301 is mature for LAST CALL. The out-in-open independently developed implementations is proof. I am hereby submitting a request to XSF to proceed with LAST CALL. Sincerely, Mark Rejhon Primary Author of XEP-0301
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Mark, Version 0.9 of XEP-0301 reads really well. It appears to cover all the issues that were raised some time ago - and some parts are even easier to understand. It is a very comprehensive Spec. Well done. It appears to be ready for Last Call for Draft. Cheers, /Barry Barry Dingle Fixed - +61(0)3-9725-3937Mob - +61(0)41-911-7578 Fellow of University of Melbourne, Electrical and Electronic Eng., Australia Linux + Android + Apple + Open Source software On Sun, May 19, 2013 at 3:45 AM, Mark Rejhon marky...@gmail.com wrote: On Sat, May 18, 2013 at 1:04 PM, XMPP Extensions Editor edi...@xmpp.orgwrote: Version 0.9 of XEP-0301 (In-Band Real Time Text) has been released. Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. Real-time text is text transmitted instantly while it is being typed or created. URL: http://xmpp.org/extensions/xep-0301.html There is now multiple open-source implementations of XEP-0301 to try: 1. Easy: Web based version. Just logon using Google credentials and chat XEP-0301 right away. http://tap.gallaudet.edu/rtt/ (This is a strophe.js JavaScript XEP-0301 plugin; Chris Vogler will release it on GIT shortly). 2. Downloadable C# client for XEP-0301 for Windows. http://www.realjabber.org/ They also interop with each other. There are also other prototype implementations (e.g. Gunnar's Omnitor, Indigital Inc., Gregg Vanderheiden's Trace Center), which are not listed here. Gallaudet Univerity's TAP (Technology Access Program) released the Javascript version of XEP-0301, showing real-time text streaming between web browsers. We all have unamious agreement that XEP-0301 is mature for LAST CALL. The out-in-open independently developed implementations is proof. I am hereby submitting a request to XSF to proceed with LAST CALL. Sincerely, Mark Rejhon Primary Author of XEP-0301
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Mark, It's done and ready for LAST CALL . Mark Rejhon schreef op 18/05/2013 19:45: On Sat, May 18, 2013 at 1:04 PM, XMPP Extensions Editor edi...@xmpp.org mailto:edi...@xmpp.org wrote: Version 0.9 of XEP-0301 (In-Band Real Time Text) has been released. Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. Real-time text is text transmitted instantly while it is being typed or created. URL: http://xmpp.org/extensions/xep-0301.html There is now multiple open-source implementations of XEP-0301 to try: 1. Easy: Web based version. Just logon using Google credentials and chat XEP-0301 right away. http://tap.gallaudet.edu/rtt/ (This is a strophe.js JavaScript XEP-0301 plugin; Chris Vogler will release it on GIT shortly). 2. Downloadable C# client for XEP-0301 for Windows. http://www.realjabber.org/ They also interop with each other. There are also other prototype implementations (e.g. Gunnar's Omnitor, Indigital Inc., Gregg Vanderheiden's Trace Center), which are not listed here. Gallaudet Univerity's TAP (Technology Access Program) released the Javascript version of XEP-0301, showing real-time text streaming between web browsers. We all have unamious agreement that XEP-0301 is mature for LAST CALL. The out-in-open independently developed implementations is proof. I am hereby submitting a request to XSF to proceed with LAST CALL. Sincerely, Mark Rejhon Primary Author of XEP-0301
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
On 5/19/13 7:51 AM, Edward Tie wrote: Mark, It's done and ready for LAST CALL . Yes, I've already brought that to the attention of the XMPP Council, which is next meeting this Wednesday. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
On Sat, May 18, 2013 at 1:04 PM, XMPP Extensions Editor edi...@xmpp.orgwrote: Version 0.9 of XEP-0301 (In-Band Real Time Text) has been released. Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. Real-time text is text transmitted instantly while it is being typed or created. URL: http://xmpp.org/extensions/xep-0301.html There is now multiple open-source implementations of XEP-0301 to try: 1. Easy: Web based version. Just logon using Google credentials and chat XEP-0301 right away. http://tap.gallaudet.edu/rtt/ (This is a strophe.js JavaScript XEP-0301 plugin; Chris Vogler will release it on GIT shortly). 2. Downloadable C# client for XEP-0301 for Windows. http://www.realjabber.org/ They also interop with each other. There are also other prototype implementations (e.g. Gunnar's Omnitor, Indigital Inc., Gregg Vanderheiden's Trace Center), which are not listed here. Gallaudet Univerity's TAP (Technology Access Program) released the Javascript version of XEP-0301, showing real-time text streaming between web browsers. We all have unamious agreement that XEP-0301 is mature for LAST CALL. The out-in-open independently developed implementations is proof. I am hereby submitting a request to XSF to proceed with LAST CALL. Sincerely, Mark Rejhon Primary Author of XEP-0301
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- Comments on New Section?
Hi Gunnar, I do two things to prevent this from happening: - on the receiver side I do modulo 2**31 arithmetic - on the sender side I limit the maximum random sequence restart number to 2**30. I hope you mean: - on the sender and receiver side I do modulo 2**31 arithmetic - on the sender side I limit the maximum random sequence restart number to 2**30. actually yes, I do - but the difference between 2**31 and 2**30 is a cool billion, so wraparound really is never ever going to happen if the sender implements this strategy. Under these circumstances, doing modulo arithmetic is a mere precaution against clients that ignore this issue. I'm fine with specifying something re the wraparound in the standard, though - in fact, I would feel better if there were something. Mark, I have not forgotten about putting up other comments on XEP-0301, but this will have to wait for a few more days, while I take care of things that cannot wait. Best wishes Christian -- Christian Vogler, PhD Director, Technology Access Program Department of Communication Studies SLCC 1116 Gallaudet University http://tap.gallaudet.edu/ VP: 202-250-2795
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- Comments on New Section?
On 2013-04-12 14:08, Christian Vogler wrote: I hope you mean: - on the sender and receiver side I do modulo 2**31 arithmetic - on the sender side I limit the maximum random sequence restart number to 2**30. actually yes, I do - but the difference between 2**31 and 2**30 is a cool billion, so wraparound really is never ever going to happen if the sender implements this strategy. Under these circumstances, doing modulo arithmetic is a mere precaution against clients that ignore this issue. I'm fine with specifying something re the wraparound in the standard, though - in fact, I would feel better if there were something. Right, I agree, it is sufficient the way you state it. - Looking at how others have handled wrap around issues, I found this exotic but relevant statement in RFC 3550 RTP section 4 on NTP wrap around: The NTP timestamp will wrap around to zero some time in the year 2036, but for RTP purposes, only differences between pairs of NTP timestamps are used. So long as the pairs of timestamps can be assumed to be within 68 years of each other, using modular arithmetic for subtractions and comparisons makes the wraparound irrelevant. -- So, we are in good company if we devote a few words to rare wrap-around issue prevention. /Gunnar
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- Comments on New Section?
On 2013-04-11 00:09, Gunnar Hellstrom wrote: I remember that there was a discussion on the risk for wrap-over in handling seq. Is the wording now in line with the outcome of the discussion? Was it acceptable as it is now, with no mentioning about the risk for wrap-around when incrementing seq. Maybe all implementors should be wise enough to handle wrap around properly. Or did the discussion end up with the conclusion that a requirement should be inserted about usual handling of the counter wrapping around? I found it. It was handled in a mail of July 27, 2012, where you said about text about the initial value on SEQ for section 4.2.1: I already say Senders MAY limit the size of the new starting seq value, to keep rtt/ compact while allowing plenty of incrementing room without overflow. which already provides the umbrella for this. I found no further change on this, so I think the sentence in above should be in section 4.2.1 Gunnar
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) - Logic of example 1.
On 2012-08-14 03:09, Mark Rejhon wrote: Barry may have presented a compromise I can accept. The first (introductory) stanza is still full word, and the second and third is not too difficult for most readers to figure out. On 2012-08-13 8:44 PM, Barry Dingle btdin...@gmail.com mailto:btdin...@gmail.com wrote: Mark, Regarding the example in 4.1, I agree with Gunnar. The first example gives the wrong initial impression by sending only complete words in the rtt/. (It made me go and double check how the protocol worked.) I suggest that we keep the first rtt/ as is, but slightly change the second and third rtt/ text contents to: *tmy J**/t* and *tuliet!/t* respectively. This retains the readability but also shows that the rtt/ is sent independently of word boundaries. Cheers, /Barry This was item #5 Let us try to keep track of the issue numbers and their state. I accept the solution. /Gunnar
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
[ Real-Time Text at http://xmpp.org/extensions/xep-0301.html ] Hello Gunnar, Thanks very much for the minor corrections to XEP-0301. I have queued your edits. My present judgement is that your edits are safely queued until LC, however, I'd like comments from other key XSF members: There is ONE bullet meriting further discussion. Talk related to section 6.2 Activation/Deactivation. Especially if Kevin/Peter/MM/etc has major comments about section 6.2 ... though Kevin says it didn't need to be relocated to a Business Rules section, and therefore is okay where it is for LC, I'm told. But does MM disagree, for example? On Sun, Aug 12, 2012 at 10:13 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: 1. 4.2.3 id The text should start with a description of what function this attribute supports. Insert after the title: The id attribute is used to enable real-time correction of the last completed message. [Minor Clarification Change] Good suggestion. I'll queue this edit till LC. (unless a 0.8 is warranted prior, e.g. comments from mm/peter/kevin et cetra) Insert the title of XEP-0308 XEP-0308 Last message correction 2. 4.2.3 id On second line. Reception must always be supported if both 0308 and 0301 are supported. c/MUST use this attribute if/MUST support reception of this attribute, and MUST transmit this attribute if/ [Minor Clarification Change] Clients that support incoming corrections don't necessarily do outgoing corrections. Therefore, a different change is better: c/clients MUST use this attribute if/clients MUST support this attribute in situations where/ I'll queue this edit, too. 3. 6.2.1 Activation guidelines Can we really accept the weak indication that discovery is recommended? I think it shall be mandated. Proposal: c/Before sending real-time text, it is preferable for a sender client to/Before sending real-time text, a sender client SHALL/ [Comment] Peter told me that RFC2119 normatives do not belong in Implementation Notes. Therefore, if RFC2119 is used, the whole section 6.2 would automatically need a relocation upwards closer to Protocol instead of Implementation Notes. I'm open to suggestions by others, such as moving to a Business Rules section (just below Discovering Support and above Implementation Notes) However, Kevin of XSF said that it is fine where it is. However, I agree this is an item meriting some discussion, though I'm not 100% sure if this needs to be addressed before LC. (Comments from others? Does it?) Section 6.2: http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text 4. Section 1, intro, last bullet point, to make the description of REACH112 correct.: c/A component within Total Conversation, used by Reach112 [4] in Europe, an accessible emergency service with real-time text./The real-time text component within Total Conversation, for example used by Reach112 [4] in Europe, a project for accessible communication services including emergency service. [Minor Clarification Change] Thanks for the Reach112 clarification. I'll queue this edit, too. 5. Section 4.1 Example 1 should have a more natural distribution of letters in the different rtt/ elements, appearing from the transmission in regular intervals as specified in section 4.1. This comment has been made from different sources a number of times. [Comment] I already mentioned that the existing example is more readable to a wider variety of less experienced people. The smart people (like us) will figure it out just fine, and the other examples illustrate this already. I'm going to cater for the majority here. 6. 4.7 Third paragraph. Language correction. This is an enumeration of only two elements. Connect them with or instead of comma: s/ messages, incorrect/ messages or incorrect/ [Minor Grammar] Thanks, I'll queue this edit, too. Note that e.g. represents partial list of examples, and automatically assumes etc. at the end. So there are other situations as well, so it's not just two. Even though only two are listed. 7. Appendix G: 4 s/ Reach112: European emergency service with real-time text./ Reach112: European accessible communication and emergency service project with total conversation including real-time text./ [Minor Clarification Change] Thanks for the Reach112 clarification. I'll queue this edit, too. 8. 4.1 xml:lang Describe explicit or implicit use of the xml:lang attribute similarly as it is described for body/ in RFC 6221. This attribute can introduce alternative language variants of the text in messages and other elements. The use is described in RFC 6221. For XEP-0301 it would be natural to offer the same opportunity to provide the alternative languages in the same message. This would at least go into section 4.2 RTT attributes and 4.5.3.1 t/ element Each language will have its own editing elements and values, so the xml:lang attribute should be on the rtt/ level. I propose
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Mark, Regarding the example in 4.1, I agree with Gunnar. The first example gives the wrong initial impression by sending only complete words in the rtt/. (It made me go and double check how the protocol worked.) I suggest that we keep the first rtt/ as is, but slightly change the second and third rtt/ text contents to: *tmy J**/t* and *tuliet!/t* respectively. This retains the readability but also shows that the rtt/ is sent independently of word boundaries. Cheers, /Barry Barry Dingle Fixed - +61(0)3-9725-3937Mob - +61(0)41-911-7578 Fellow of University of Melbourne, Electrical and Electronic Eng., Australia Apple + Linux + Open Source software On Tue, Aug 14, 2012 at 1:29 AM, Mark Rejhon marky...@gmail.com wrote: [ Real-Time Text at http://xmpp.org/extensions/xep-0301.html ] Hello Gunnar, Thanks very much for the minor corrections to XEP-0301. I have queued your edits. My present judgement is that your edits are safely queued until LC, however, I'd like comments from other key XSF members: There is ONE bullet meriting further discussion. Talk related to section 6.2 Activation/Deactivation. Especially if Kevin/Peter/MM/etc has major comments about section 6.2 ... though Kevin says it didn't need to be relocated to a Business Rules section, and therefore is okay where it is for LC, I'm told. But does MM disagree, for example? On Sun, Aug 12, 2012 at 10:13 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: 1. 4.2.3 id The text should start with a description of what function this attribute supports. Insert after the title: The id attribute is used to enable real-time correction of the last completed message. [Minor Clarification Change] Good suggestion. I'll queue this edit till LC. (unless a 0.8 is warranted prior, e.g. comments from mm/peter/kevin et cetra) Insert the title of XEP-0308 XEP-0308 Last message correction 2. 4.2.3 id On second line. Reception must always be supported if both 0308 and 0301 are supported. c/MUST use this attribute if/MUST support reception of this attribute, and MUST transmit this attribute if/ [Minor Clarification Change] Clients that support incoming corrections don't necessarily do outgoing corrections. Therefore, a different change is better: c/clients MUST use this attribute if/clients MUST support this attribute in situations where/ I'll queue this edit, too. 3. 6.2.1 Activation guidelines Can we really accept the weak indication that discovery is recommended? I think it shall be mandated. Proposal: c/Before sending real-time text, it is preferable for a sender client to/Before sending real-time text, a sender client SHALL/ [Comment] Peter told me that RFC2119 normatives do not belong in Implementation Notes. Therefore, if RFC2119 is used, the whole section 6.2 would automatically need a relocation upwards closer to Protocol instead of Implementation Notes. I'm open to suggestions by others, such as moving to a Business Rules section (just below Discovering Support and above Implementation Notes) However, Kevin of XSF said that it is fine where it is. However, I agree this is an item meriting some discussion, though I'm not 100% sure if this needs to be addressed before LC. (Comments from others? Does it?) Section 6.2: http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text 4. Section 1, intro, last bullet point, to make the description of REACH112 correct.: c/A component within Total Conversation, used by Reach112 [4] in Europe, an accessible emergency service with real-time text./The real-time text component within Total Conversation, for example used by Reach112 [4] in Europe, a project for accessible communication services including emergency service. [Minor Clarification Change] Thanks for the Reach112 clarification. I'll queue this edit, too. 5. Section 4.1 Example 1 should have a more natural distribution of letters in the different rtt/ elements, appearing from the transmission in regular intervals as specified in section 4.1. This comment has been made from different sources a number of times. [Comment] I already mentioned that the existing example is more readable to a wider variety of less experienced people. The smart people (like us) will figure it out just fine, and the other examples illustrate this already. I'm going to cater for the majority here. 6. 4.7 Third paragraph. Language correction. This is an enumeration of only two elements. Connect them with or instead of comma: s/ messages, incorrect/ messages or incorrect/ [Minor Grammar] Thanks, I'll queue this edit, too. Note that e.g. represents partial list of examples, and automatically assumes etc. at the end. So there are other situations as well, so it's not just two. Even though only two are listed. 7. Appendix G: 4 s/ Reach112: European emergency service with real-time text./
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Barry may have presented a compromise I can accept. The first (introductory) stanza is still full word, and the second and third is not too difficult for most readers to figure out. On 2012-08-13 8:44 PM, Barry Dingle btdin...@gmail.com wrote: Mark, Regarding the example in 4.1, I agree with Gunnar. The first example gives the wrong initial impression by sending only complete words in the rtt/. (It made me go and double check how the protocol worked.) I suggest that we keep the first rtt/ as is, but slightly change the second and third rtt/ text contents to: *tmy J**/t* and *tuliet!/t* respectively. This retains the readability but also shows that the rtt/ is sent independently of word boundaries. Cheers, /Barry Barry Dingle Fixed - +61(0)3-9725-3937Mob - +61(0)41-911-7578 Fellow of University of Melbourne, Electrical and Electronic Eng., Australia Apple + Linux + Open Source software On Tue, Aug 14, 2012 at 1:29 AM, Mark Rejhon marky...@gmail.com wrote: [ Real-Time Text at http://xmpp.org/extensions/xep-0301.html ] Hello Gunnar, Thanks very much for the minor corrections to XEP-0301. I have queued your edits. My present judgement is that your edits are safely queued until LC, however, I'd like comments from other key XSF members: There is ONE bullet meriting further discussion. Talk related to section 6.2 Activation/Deactivation. Especially if Kevin/Peter/MM/etc has major comments about section 6.2 ... though Kevin says it didn't need to be relocated to a Business Rules section, and therefore is okay where it is for LC, I'm told. But does MM disagree, for example? On Sun, Aug 12, 2012 at 10:13 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: 1. 4.2.3 id The text should start with a description of what function this attribute supports. Insert after the title: The id attribute is used to enable real-time correction of the last completed message. [Minor Clarification Change] Good suggestion. I'll queue this edit till LC. (unless a 0.8 is warranted prior, e.g. comments from mm/peter/kevin et cetra) Insert the title of XEP-0308 XEP-0308 Last message correction 2. 4.2.3 id On second line. Reception must always be supported if both 0308 and 0301 are supported. c/MUST use this attribute if/MUST support reception of this attribute, and MUST transmit this attribute if/ [Minor Clarification Change] Clients that support incoming corrections don't necessarily do outgoing corrections. Therefore, a different change is better: c/clients MUST use this attribute if/clients MUST support this attribute in situations where/ I'll queue this edit, too. 3. 6.2.1 Activation guidelines Can we really accept the weak indication that discovery is recommended? I think it shall be mandated. Proposal: c/Before sending real-time text, it is preferable for a sender client to/Before sending real-time text, a sender client SHALL/ [Comment] Peter told me that RFC2119 normatives do not belong in Implementation Notes. Therefore, if RFC2119 is used, the whole section 6.2 would automatically need a relocation upwards closer to Protocol instead of Implementation Notes. I'm open to suggestions by others, such as moving to a Business Rules section (just below Discovering Support and above Implementation Notes) However, Kevin of XSF said that it is fine where it is. However, I agree this is an item meriting some discussion, though I'm not 100% sure if this needs to be addressed before LC. (Comments from others? Does it?) Section 6.2: http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text 4. Section 1, intro, last bullet point, to make the description of REACH112 correct.: c/A component within Total Conversation, used by Reach112 [4] in Europe, an accessible emergency service with real-time text./The real-time text component within Total Conversation, for example used by Reach112 [4] in Europe, a project for accessible communication services including emergency service. [Minor Clarification Change] Thanks for the Reach112 clarification. I'll queue this edit, too. 5. Section 4.1 Example 1 should have a more natural distribution of letters in the different rtt/ elements, appearing from the transmission in regular intervals as specified in section 4.1. This comment has been made from different sources a number of times. [Comment] I already mentioned that the existing example is more readable to a wider variety of less experienced people. The smart people (like us) will figure it out just fine, and the other examples illustrate this already. I'm going to cater for the majority here. 6. 4.7 Third paragraph. Language correction. This is an enumeration of only two elements. Connect them with or instead of comma: s/ messages, incorrect/ messages or incorrect/ [Minor Grammar] Thanks, I'll queue this edit, too. Note that e.g.
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- candidate for LAST CALL
On Sun, Jul 22, 2012 at 11:00 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: Yes, good to distinguish between service discovery, and activating support. There is something missing in a sentence in version 0.4, chapter 5. In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in . What was your intention after in? I suspect you're looking at the xepdiff tool - some things don't get correctly marked and one of them is sometimes that references won't be rendered in the diff. /K
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- candidate for LAST CALL
On 2012-07-23 10:13, Kevin Smith wrote: On Sun, Jul 22, 2012 at 11:00 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: Yes, good to distinguish between service discovery, and activating support. There is something missing in a sentence in version 0.4, chapter 5. In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in . What was your intention after in? I suspect you're looking at the xepdiff tool - some things don't get correctly marked and one of them is sometimes that references won't be rendered in the diff. /K Right, that was the reason. Thanks Gunnar
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- candidate for LAST CALL
On 2012-07-22 03:19, Mark Rejhon wrote: Hello XSF members (Peter and Kevin, et cetra) I incorporated Gunnar's edit today. Do you prefer I submit an 0.5 immediately before you review? The only changes I did were editorial -- word edits, phrase edits and sentence edits/moves, in approximately 15 locations, no protocol changes over 0.4. Mark, thanks for taking the trouble to transpose my edit proposals to 0.4 and creating and submitting 0.5. Even if there are a few remaing items I am not in total agreement with you about, I think these could either be accepted as you have proposed them or be accepted as editorial changes during a last call. See some comments on these below. ( stille referring to 0.3 section numbering) 11. Section 4.1, Example 1, Line 9 , make the text part my Ju , so that it is obvious that it is not about word by word transmission. 12. Section 4.1, Example 1, Line 15 , make the text part liet only, so that it is obvious that it is not about word by word transmission. 13. Section 4.2.2 event='new' third line. change display, and then process to reception, and then process text and. Because we must not assume that all applications display the text. 11/12. Edit Deferred -- It is merely an introductory example. Also, if people chunk text instead of preserving key press intervals, then whole-word burst transmission is greatly preferred over broken-word burst transmission. But why do you want to confuse the reader with giving the impression that transmission is word-wise, when it is time-sampled in reality. I suggest to accept my edit proposal in order to not cause wrong impression what it is all about. 13. Edit Deferred -- It's a great suggestion in theory, but in all practicality, the change is too confusing. Most implementers of blind-assistive software will figure out display means reception or present to the user The word display is pretty standard in many XEP's, from a search I did. Even it's an XML element in some, i.e. XEP-0202 (A Final standard) uses a display/ element. I was thinking of non-displaying software as gateways, multi-party-bridges, applications etc. They never initialize a new real-time message for display. But I can accept your proposal. The final intention is in most cases to display. 14. Section 4.2.2 event='cancel'. How does this behave through multi-user chat and multiple login situations? Is the event='cancel' sent through to all? I see a risk that one user sending event='cancel' would turn off rtt for all recipients. If this is true, I see three solutions: a) Delete event='cancel'. b) Add a sentence saying event='cancel' SHALL not be used in a MUC or multi-login session. c) Add a sentence saying event='cancel' SHOULD be ignored in MUC and multi-login sessions. I have a slight preference for solution a), to delete cancel from the specification. If it is deleted, also the sections in 6.2.1 and 6.2.2 dealing with cancel shall be deleted. 14. Explanation -- Cancel is critical to the needs of several implementers. See Activating/Deactivating text section http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text Also, cancel is 100% appropriate for multi-login session. I clarified the MUC chapter to say that cancel should not deactivate outgoing transmission since it would allow one participant to suppress real-time text between other willing participants. (senders may still use it, in order to discard their unfinished real-time message when logging off, etc) However, an edit was made to the Activation/Deactivation section to clarify cancel behaviour during Multi-User Chat. [2 sentences modified] I need to see this before judging. 18. Consider deleting the Forward Delete d action element. It cannot be used with the default value for p because that would point outside the real-time message. Therefore, a p must always be calculated and included. Then it is equal in complexity to use it as Backspace. Having both just seem to add complexity to implementations. ( It would have been different and of value if it worked from a current cursor position.) But if you have good reasons, e.g. easily matching some editing operation result, you can keep it. 18. Edit deferred -- Explanation given in long email. Forward delete just introduces complexity. Since you do not have the concept of current position in the specification, a forward delete and a backspace of anything else than the last character are equally long in coding. But, if you want to have these two codings of the same operation, I can accept it. 19. Section 4.5.2, third bullet point. I would like to see the words Unicode Code Points replace Unicode Character Counting. Code points is the safe base that we count. 20. Section 4.5.4.1 At the end, insert paragraph: Characters consisting of
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- candidate for LAST CALL
(Peter, please go ahead and proceed to publish 0.5 I submitted ASAP -- so that people have context when reading this. Fixes can go into 0.6, if deemed important) On Sun, Jul 22, 2012 at 6:00 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: 11. Section 4.1, Example 1, Line 9 , make the text part my Ju , so that it is obvious that it is not about word by word transmission. 12. Section 4.1, Example 1, Line 15 , make the text part liet only, so that it is obvious that it is not about word by word transmission. 13. Section 4.2.2 event='new' third line. change display, and then process to reception, and then process text and. Because we must not assume that all applications display the text. 11/12. Edit Deferred -- It is merely an introductory example. Also, if people chunk text instead of preserving key press intervals, then whole-word burst transmission is greatly preferred over broken-word burst transmission. But why do you want to confuse the reader with giving the impression that transmission is word-wise, when it is time-sampled in reality. I suggest to accept my edit proposal in order to not cause wrong impression what it is all about. It's all a matter of perspective -- It is relative. I suspect more than half of people here would agree your suggestion is NOT simpler in this case because: ... Primary reason: My opinion is that the first introductory example MUST be as simple as possible. I think most would agree with me here. There is no wrong impression to convey here, because other subsequent examples are self explanatory on what's allowed (breaking up text, turning things into single keypresses, key press intervals, and the new example I added to v0.5, really makes it much easier to understand key press intervals.). But the bottom line, it is an introductory example, and the introductory example must be as simple as possible to explain. ... Secondary explanation: When displayed in forced-color-code XML on the website (i.e. published at http://www.xmpp.org/extensions/xep-0301.html)... the transmitted real-time text words are no longer separately color-highlighted like the draft copy in the Word version. So the full words make them easier to glance out than if they are fragmented words, too. ... Tertiary explanation: We need to view this specification from a less experienced developer perspective. People who are less experienced with protocols (we are protocol authors, other people are not), need to be able to see the simplest possible example (see primary rason) (Even if you only agree with one or two of the above reasons, that should be good enough, no?) 18. Consider deleting the Forward Delete d action element. It cannot be used with the default value for p because that would point outside the real-time message. Therefore, a p must always be calculated and included. Then it is equal in complexity to use it as Backspace. Having both just seem to add complexity to implementations. ( It would have been different and of value if it worked from a current cursor position.) But if you have good reasons, e.g. easily matching some editing operation result, you can keep it. 18. Edit deferred -- Explanation given in long email. Forward delete just introduces complexity. Since you do not have the concept of current position in the specification, a forward delete and a backspace of anything else than the last character are equally long in coding. But, if you want to have these two codings of the same operation, I can accept it. About complexity: It only adds 5 lines of complexity to the implementation: http://code.google.com/p/realjabber/source/browse/trunk/Java/src/RealTimeText.java?r=24#551 About reasoning: ... Reason 1. There are situations where it made a lot of sense to have the two separate, including recipient-side time-smoothed display which was something you also suggested. For example, e n=5/ can be automatically converted to the equivalent e/e/e/e/e/ for time-smoothed display with the cursor animated backwards. And d p='10' n='5'/ can automatically be converted to the equivalent d p='10'/d p='10'/d p='10'/d p='10'/d p='10'/ for time-smoothed display with the cursor staying stationary. If we merged the two, then we can't have distinctive time-smoothed display of either. (As I recall, you're a strong proponent of time-smoothed display) But of course, it might not be that important, even to you. ... Reason 2. Ability to do accurate journalling of edits, for emergency purposes. However, this reason can become moot, especially if we're not using the 'n' argument, since a single-character backspace transmitted can be indistinguishable from a single-character delete operation (even for time-smoothed display). ... Reason 3. It slightly simplifies Monitoring Key Presses Directly for senders http://xmpp.org/extensions/xep-0301.html#monitoring_key_presses_directly ... (I know that's not the preferred method) ... Reason 4. It
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
On Sun, Jul 22, 2012 at 11:11 PM, XMPP Extensions Editor edi...@xmpp.orgwrote: Version 0.5 of XEP-0301 (In-Band Real Time Text) has been released. Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. Changelog: Minor corrections and clarifications. (MDR) Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.4/vs/0.5 URL: http://xmpp.org/extensions/xep-0301.html Oh wow, just as a click Send, this pops up in my Inbox. This 0.5 spec incorporates the vast majority of Gunnar's suggestions. 0.5 diff is about 10 times less cluttered than diff 0.3-04 0.5 diff is about 100 times less cluttered than diff 0.2-0.3 So, I feel it is getting there to maturity. Even so, the spec is largely backward compatible all the way back to 0.0.2, despite some protocol changes since. (I know it didn't need to stay compatible during Experimental, but it happens most changes apparently didn't affect compatibility. I hope this is an indication of a protocol that is mature enough to not even need any dramatic changes.) I'd like comments from key people (Peter, Kevin, Matt, etc), to review the whole specification, as well as review my reply to Gunnar. Is it ready for LAST CALL? Thanks, Mark Rejhon
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- Unicode Character Counting
On Mon, Jul 23, 2012 at 12:17 AM, Mark Rejhon marky...@gmail.com wrote: 19. Edit deferred -- Explanation given in previous email. It helps reader associate WHICH definition of character we are using. Even the RFC's say that the word has multiple interpretations, so it's appropriate here in the title. The title is like a glossary entry, and the contents explain we're using code points as the method of counting characters. I still regard this dangerous and confusing. We are counting Unicode code points, and that needs to be clear in all explanations. We will have to agree to disagree -- I think it's safer and less confusing: Did you know there are 47 occurances of the word character in the whole document? Therefore, I prefer not to remove the word Character in the heading Unicode Character Counting. Thus, it is like the heading of an extended *glossary* definition here -- and it is in my opinion safer and less confusing. Obviously, the section is too big to move to the glossary section, but I am open to alternate ideas of defining the word character from this mailing list. For this, I defer to public comment (once 0.5 is up). Referring to: http://unicode.org/glossary/ , which says the following: *Code Point http://unicode.org/glossary/#code_point*. (1) Any value in the Unicode codespace; that is, the range of integers from 0 to 1016. (See definition D10 in Section 3.4, Characters and Encodinghttp://www.unicode.org/versions/Unicode6.1.0/ch03.pdf#G2212.) Not all code points are assigned to encoded characters. See *code point typehttp://unicode.org/glossary/#code_point_type *. (2) *A value, or position, for a character, in any coded character set.* Other rationale: - Other XEP's use character terminology - People are already familiar with character terminology. - There's 47 occurances of word character in XEP-0301 (e.g. ...Remove 1 character from...) - Search-Replace all of them into code points would make document _even_ more confusing to those who are not familiar with code point terminology. - Therefore, I feel that the lesser of evil is to treat Unicode Character Counting as a definition of XEP-0301's use of the word character. If an implementer makes an error in interpreting the word character this this section clarifies it. - If several people here agree with Gunnar that Unicode Character Counting should be renamed to Unicode Code Point Counting, they would probably also agree that the word still needs to be defined somewhere else -- such as in the Glossary section. (defining the word character from the perspective of XEP-0301, since character has multiple interpretations, so it is necessary to define the word character, and I chose Unicode Character Counting as the definition of character) I am open to alternative methods of defining character, but it needs to be less confusing, not even more confusing. I'd like to hear opinions from others about this matter, as well as general comments about Accurate Processing of Action Elements (of which Unicode Character Counting is included within). http://xmpp.org/extensions/xep-0301.html#accurate_processing_of_action_elements Thanks, Mark Rejhon
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- candidate for LAST CALL
Sending reply that covered the bullets. Also, some of this is already outdated, as I already made some changes (independently). You might want to review which bullets still apply, and which bullets are outdated. -- Forwarded message -- From: Mark Rejhon marky...@gmail.com Date: Mon, Jul 9, 2012 at 5:26 AM Subject: Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) To: XMPP Standards standards@xmpp.org On Mon, Jul 9, 2012 at 3:51 AM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: This looks good. I have some comments, but very few influence the protocol. So even if there are minor adjustments to do, the spec looks mature. Excellent comments, and the vast majority of your comments is useful -- most of your change will be implemented. I will address comments to the ones that needs further discussion: 5. Section 2.4, Title. Change to Usable for mainstream and accessibility purposes. The current heading is a single word: Accessible -- I prefer to keep it because it's correct, clear, and short. It catches attention of the accessibility people better, including the Access Board that has already contacted us, about the specification too. The word 'mainstream is also mentioned at end of section 1, also even in section 2.4, in section 6.2. I therefore believe that I've carefully balanced accessibility and mainstream, and satisfied both targets, while aiming to achieve the goal of eventually becoming an important part of future Accessibility standards. (That said, I'll fix the first bullet) 14. Section 4.2.2 event='cancel'. How does this behave through multi-user chat and multiple login situations? Is the event='cancel' sent through to all? I see a risk that one user sending event='cancel' would turn off rtt for all recipients. If this is true, I see three solutions: a) Delete event='cancel'. b) Add a sentence saying event='cancel' SHALL not be used in a MUC or multi-login session. c) Add a sentence saying event='cancel' SHOULD be ignored in MUC and multi-login sessions. 1. It is appropriate for a multi-login session; there is no issue with using the cancel during a multi-login -- it is completely appropriate for multi-login. (Regardless of whether or not you cancel before/after switching, and regardless of whether or not you reactivate before/after switching logins. All scenarios result in acceptable behavior.) 2. I already mention that it should not be used for MUC, in the MUC section: http://xmpp.org/extensions/xep-0301.html#multiuser_chat I have a slight preference for solution a), to delete cancel from the specification. If it is deleted, also the sections in 6.2.1 and 6.2.2 dealing with cancel shall be deleted. It is already optional. But some implementations need it. For example, one party clicks a button to turn off real-time text. This specific implementation requires ability to synchronize the disabiling of real-time text. How do we notify the other end of the intent to end a real-time text session? Example use case: - A party activates real-time text by pressing a button. - Both ends synchronize the enabling of real-time text via rtt event='start'/. - A party deactivates real-time text. - Both ends synchronize the disabling of real-time text via rtt event='cancel'/. Various methods of synchronizing activation/deactivation of real-time text is listed at: http://www.xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_texthttp://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text Certainly, not all implementations necessarily need to follow the above behaviour (maybe your implementation doesn't need it). However, there are other vendors that definitely need to be able to do this behaviour (after displaying a confirmation prompt) As a result, I cannot remove event='cancel' and deny the other vendors the ability to synchronize the disabling of real-time text. That said, unidirectional real-time text is allowed by XEP-0301, so synchronizing the enabling/disabling of real-time text is not a requirement, but some vendors require this ability (much like synchronizing enabling/disabling of audio/video after a confirmation prompt). I intend to respect both behaviours. 16. Section 4.4, line 3, after conversation, add in most network conditions. On GPRS, having 1.5 s network latency, the usability requirement will not be met, and that must be accepted. ( F.700 requires 2 seconds end-to-end for usable real-time text and 1 second for good real-time text. ) Technically you're right. I'll make this wording adjustment, since it is what F.700 says for technical compliance purposes. That said, real-world usability comment: I would like to comment that the innovation of encoding key press intervals ( http://www.realjabber.org/anim/real_time_text_demo.html ) gives an approximately 1.5x-2x multiplier to the maximum usable latency. i.e. a NRTT (Near-Real-Time-Text) bursty conversation with a 2
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- candidate for LAST CALL
I missed some articles at Capther 8 8. Interoperability Considerations I missed some articles about Captional telephone (SMS) and classic text telephones (V.18 and V.22 bis) . Can you explain why do you not added a sub article about a gateway to classic textphones and Capational telephones? Earlier week have some poeple dissussed about addional proposual article ? Op 21/07/2012 16:04, Mark Rejhon schreef: Sending reply that covered the bullets. Also, some of this is already outdated, as I already made some changes (independently). You might want to review which bullets still apply, and which bullets are outdated. -- Forwarded message -- From: *Mark Rejhon* marky...@gmail.com mailto:marky...@gmail.com Date: Mon, Jul 9, 2012 at 5:26 AM Subject: Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) To: XMPP Standards standards@xmpp.org mailto:standards@xmpp.org On Mon, Jul 9, 2012 at 3:51 AM, Gunnar Hellström gunnar.hellst...@omnitor.se mailto:gunnar.hellst...@omnitor.se wrote: This looks good. I have some comments, but very few influence the protocol. So even if there are minor adjustments to do, the spec looks mature. Excellent comments, and the vast majority of your comments is useful -- most of your change will be implemented. I will address comments to the ones that needs further discussion: 5. Section 2.4, Title. Change to Usable for mainstream and accessibility purposes. The current heading is a single word: Accessible -- I prefer to keep it because it's correct, clear, and short. It catches attention of the accessibility people better, including the Access Board that has already contacted us, about the specification too. The word 'mainstream is also mentioned at end of section 1, also even in section 2.4, in section 6.2. I therefore believe that I've carefully balanced accessibility and mainstream, and satisfied both targets, while aiming to achieve the goal of eventually becoming an important part of future Accessibility standards. (That said, I'll fix the first bullet) 14. Section 4.2.2 event='cancel'. How does this behave through multi-user chat and multiple login situations? Is the event='cancel' sent through to all? I see a risk that one user sending event='cancel' would turn off rtt for all recipients. If this is true, I see three solutions: a) Delete event='cancel'. b) Add a sentence saying event='cancel' SHALL not be used in a MUC or multi-login session. c) Add a sentence saying event='cancel' SHOULD be ignored in MUC and multi-login sessions. 1. It is appropriate for a multi-login session; there is no issue with using the cancel during a multi-login -- it is completely appropriate for multi-login. (Regardless of whether or not you cancel before/after switching, and regardless of whether or not you reactivate before/after switching logins. All scenarios result in acceptable behavior.) 2. I already mention that it should not be used for MUC, in the MUC section: http://xmpp.org/extensions/xep-0301.html#multiuser_chat I have a slight preference for solution a), to delete cancel from the specification. If it is deleted, also the sections in 6.2.1 and 6.2.2 dealing with cancel shall be deleted. It is already optional. But some implementations need it. For example, one party clicks a button to turn off real-time text. This specific implementation requires ability to synchronize the disabiling of real-time text. How do we notify the other end of the intent to end a real-time text session? Example use case: - A party activates real-time text by pressing a button. - Both ends synchronize the enabling of real-time text via rtt event='start'/. - A party deactivates real-time text. - Both ends synchronize the disabling of real-time text via rtt event='cancel'/. Various methods of synchronizing activation/deactivation of real-time text is listed at: http://www.xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text Certainly, not all implementations necessarily need to follow the above behaviour (maybe your implementation doesn't need it). However, there are other vendors that definitely need to be able to do this behaviour (after displaying a confirmation prompt) As a result, I cannot remove event='cancel' and deny the other vendors the ability to synchronize the disabling of real-time text. That said, unidirectional real-time text is allowed by XEP-0301, so synchronizing the enabling/disabling of real-time text is not a requirement, but some vendors require this ability (much like synchronizing enabling/disabling of audio/video after a confirmation prompt). I intend to respect both behaviours. 16. Section 4.4, line 3, after conversation, add in most network conditions. On GPRS, having 1.5 s
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- candidate for LAST CALL
On 7/21/12 9:01 AM, Kevin Smith wrote: On Sat, Jul 21, 2012 at 3:56 PM, Mark Rejhon marky...@gmail.com wrote: Can someone else outside the R3TF also comment about the inclusion of a small TTY/textphone paragraph in Interoperability considerations? (Yea's and Nay's -- I know I've gotten a couple of Nay's already.) It's an XMPP extension - I'm not sure it greatly benefits anything to include details of various related protocols that aren't pertinent to implementing this XEP. (Nay) I agree with Kev. /psa
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- candidate for LAST CALL
Hello XSF members (Peter and Kevin, et cetra) I incorporated Gunnar's edit today. Do you prefer I submit an 0.5 immediately before you review? The only changes I did were editorial -- word edits, phrase edits and sentence edits/moves, in approximately 15 locations, no protocol changes over 0.4. On Sat, Jul 21, 2012 at 1:46 AM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: 1. Chapter 1, last line: Move last sentence first. And make an empty line after it. Now it takes the whole chapter before we get to know what the specification is about. 2. Chapter 1, last bullet point. Change to: As one medium in Total Conversation, e.g. deployed in the European project REACH112 [5] for accessible communication and emergency service. Motivation: ( Total conversation was the theme. It was about both person-to-person and emergency service) 3. Section 2.1, point 4. add and replication after transmission. ( just transmission is not sufficient for the intended effect.) 4. Section 2.2, point 3. change traversal protocols to traversal mechanisms, because they are more mechanisms than protocols. 1. Done [1 sentence move] -- Barry recommended it be a standalone sentence, too. 2. Done [1 sentence edit] -- Made similiar but not identical edit 3. Done [2 words added] -- I used and reproduction 4. Done [1 word edit] -- Verbatim edit 5. Section 2.4, Title. Change to Usable for mainstream and accessibility purposes. 6. Section 2.4, point 1. Change word accessibility to service description. Because F.703 is a general standard. The total conversation part is of accessibility interest. 7. Chapter 3, Real-time text. Change in real time to instantly , to match definition in chapter 1. 8. Chapter 3, Add JID and its explanation. 5. Edit deferred -- explanation given in earlier email message. 6. Done [1 word removed] -- I removed the word accessibility 7. Done [1 phrase edit] -- Verbatim edit 8. Edit deferred -- It is a standard XMPP Core terminology. Other specs don't first explain JID (e.g. XEP-0296) 9. Section 4.1, second line. Add client after sender, to make it clear that the user dies not need to bother about transmission. 10. Section 4.1 Second paragraph. Change word live to in real-time to be consistent. 11. Section 4.1, Example 1, Line 9 , make the text part my Ju , so that it is obvious that it is not about word by word transmission. 12. Section 4.1, Example 1, Line 15 , make the text part liet only, so that it is obvious that it is not about word by word transmission. 13. Section 4.2.2 event='new' third line. change display, and then process to reception, and then process text and. Because we must not assume that all applications display the text. 9. Done [1 word added] -- Already done in v0.4 10. Done [1 phrase change] -- Verbatim edit 11/12. Edit Deferred -- It is merely an introductory example. Also, if people chunk text instead of preserving key press intervals, then whole-word burst transmission is greatly preferred over broken-word burst transmission. 13. Edit Deferred -- It's a great suggestion in theory, but in all practicality, the change is too confusing. Most implementers of blind-assistive software will figure out display means reception or present to the user The word display is pretty standard in many XEP's, from a search I did. Even it's an XML element in some, i.e. XEP-0202 (A Final standard) uses a display/ element. 14. Section 4.2.2 event='cancel'. How does this behave through multi-user chat and multiple login situations? Is the event='cancel' sent through to all? I see a risk that one user sending event='cancel' would turn off rtt for all recipients. If this is true, I see three solutions: a) Delete event='cancel'. b) Add a sentence saying event='cancel' SHALL not be used in a MUC or multi-login session. c) Add a sentence saying event='cancel' SHOULD be ignored in MUC and multi-login sessions. I have a slight preference for solution a), to delete cancel from the specification. If it is deleted, also the sections in 6.2.1 and 6.2.2 dealing with cancel shall be deleted. 14. Explanation -- Cancel is critical to the needs of several implementers. See Activating/Deactivating text section http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text Also, cancel is 100% appropriate for multi-login session. I clarified the MUC chapter to say that cancel should not deactivate outgoing transmission since it would allow one participant to suppress real-time text between other willing participants. (senders may still use it, in order to discard their unfinished real-time message when logging off, etc) However, an edit was made to the Activation/Deactivation section to clarify cancel behaviour during Multi-User Chat. [2 sentences modified] 15. Section 4.4, line 3, after F.700 insert usability requirement section A.3.2.1 so that the reader understands why this requirement
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- candidate for LAST CALL
On 7/21/12 7:19 PM, Mark Rejhon wrote: Hello XSF members (Peter and Kevin, et cetra) I incorporated Gunnar's edit today. Do you prefer I submit an 0.5 immediately before you review? The only changes I did were editorial -- word edits, phrase edits and sentence edits/moves, in approximately 15 locations, no protocol changes over 0.4. I see no harm in publishing 0.5 -- that way, folks will be reviewing the latest and greatest. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) -- candidate for LAST CALL
On Fri, Jul 20, 2012 at 9:33 PM, XMPP Extensions Editor edi...@xmpp.orgwrote: Version 0.4 of XEP-0301 (In-Band Real Time Text) has been released. Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. Changelog: Spelling, grammar, and clarification edits, including section clarifications recommended from public discussion. Interop with XEP-0308 message correction. (MDR) Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.3/vs/0.4 URL: http://xmpp.org/extensions/xep-0301.html This is the version of the spec I would like to announce LAST CALL, if at least a few people think it is ready. Peter Saint Andre mentioned he believed it was ready, Gunnar has mentioned it is ready, but I would like Peter's opinion again, as well as Kevin's opinion. More detail about the changes made, based on discussion on this mailing list, as well as within the Real Time Text Taskforce, and discussion to other parties. The diff is much less dense than between 0.2-0.3, with mainly hundreds of tiny edits (mostly grammatical and spelling), and at least a couple of significant section changes/slight reordering. - Protocol Change: (Backwards compatible) Add new optional 'id' attribute for good compatibility with XEP-0308 Last Message Correction - Editorial: Many minor grammar and spelling mistakes fixed (with help of Microsoft Word) - Editorial: Adjusted uppercase And, For, With in headings to lowercase - Editorial: implementor changed to implementer (consistent with usage by other Final XEP's) - Editorial: Vast majority of Barry Dingle's corrections incorporated - Editorial: Minor changes to Multi-User Chat section - Rename: Real-Time Text Operations renamed to Real-Time Text Actions (consistency) - Rename: Element w/ - Interval into Element w/ - Wait Interval in order to reduce confusion with Transmission Interval, and someone also asked what W in w/ stood for. - Optimization: Rewrote 6.1.2 Preserving Key Press Intervals to be much clearer, while 15% smaller. - Optimization: Section 1 Introduction, optimized one sentence in last paragraph. Shorter yet extolls additional mainstream advantages. - Optimization: Section 8 Interoperability Considerations optimized by approximately 40% in size, with no loss of info. - Clarification: Section 4.1 first two paragraphs has very minor edits, including four-word explanation why body/ is still used. - Clarification: Added word default to 4.4 Transmission Interval. - Clarification: Reorganize section 6.4 Real-Time Text Transmission Methodologies to be more user-friendly (also based on Gunnar comments). Some section names have been changed, and information has been recategorized in a different order. - Clarification: Section 4.6.3 Message Reset, changed third bullet to be more appropriate, some sentences updated. - Clarification: Section 5 Determining Support improvement, now includes XEP-0115. (Continues to allow XEP-0085 style fallback) - Clarification: Clarification of several examples, new examples added to Use Cases NOTE: Despite the evolution of this specification, all versions of XEP-0301 since v0.1 have remained backwards compatible with each other (at least in intended interpretation -- wording is much more clarified in v0.4 thanks to everyone's help!) I would appreciate opinions about announcing LAST CALL, for this specification. Thank you so much, everyone! Mark Rejhon
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) - Odd strategies
Mark, I see that you in this version have introduced a couple of odd real-time text transmission strategies in sections 6.4.1 and 6.4.2, based on the 'reset' event. http://xmpp.org/extensions/xep-0301.html#realtime_text_transmission_methodologies I get the impression that you have introduced them after getting feedback that it is complicated to detect and convey real-time editing within a real-time message. 6.4.1 proposes to send the whole real-time message for every transmission interval that there has been any addition or modification to it. 6.4.2 proposes to send the whole real-time message repeatedly while the user is editing within the real-time message. They are certainly possible to use, but have, as you point out in the last sentence of each section, some obvious disadvantages. One is that the length of these messages can be very long if the user has the habit of seldom indicating end of message. That behavior maybe becomes a common habit when you get used to real-time text. A new reader of the specification would however maybe not detect that the methods are odd, but read the headings and get the impression that this is the normal way of transmitting real-time text. 6.4.1 has the heading Basic Real-Time Text. leading to the conclusion that this is normal. I suggest some reordering, modifications of headers and slight wording changes to amend this. 1. Insert explanation in 6.4 This section describes alternatives for how to detect and compose what shall be transmitted during real-time text operation. 2. In first line of 6.4.4 insert after method : to detect what changes to transmit 3. Combine 6.4.3 and 6.4.4 to one section. 6.4.3 just describes a method that is not recommended, and does not specify a solution, so it suits better as introductory warning words. Use the title 6.4.3 Monitoring message changes. delete title 6.4.4 4. Replace the second sentence in 6.4.3 (starting with However...), with However, this method has disadvantages. 5. Rename 6.4.1 to Using 'reset' events to transmit changes. 6. Include a new first sentence in 6.4.1: As an alternative to detecting and transmitting only the changes in the real-time message, the following method can be considered. 7. Move 6.4.3 to become 6.4.1, pushing earlier 6.4.1 and 6.4.2 down to become 6.4.2 and 6.4.3 respectively. ___ Gunnar Hellström Omnitor gunnar.hellst...@omnitor.se +46708204288
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) - Odd strategies
On Tue, Jul 10, 2012 at 2:58 AM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: Mark, I see that you in this version have introduced a couple of odd real-time text transmission strategies in sections 6.4.1 and 6.4.2, based on the 'reset' event. http://xmpp.org/extensions/**xep-0301.html#realtime_text_** transmission_methodologieshttp://xmpp.org/extensions/xep-0301.html#realtime_text_transmission_methodologies Gunnar -- several are excellent suggestions. An explanation at the beginning of 6.4 The transmission strategy in 6.4.1 and 6.4.2 is not recommended for messages bigger than approximately SMS size, for mobile devices that want to write very compact simple implementations of real-time text that does not require much processing or battery -- and they can take advantage of stream compression to eliminate the redundancy disadvantage of message resets. It was explained to me that it may actually use less bandwidth and less CPU in certain situations. Even though it means a disadvantage of losing key press intervals (the intervals demonstrated at www.realjabber.org/anim/real_time_text_demo.html) which I already mention. Stream compression compensates for the bandwidth penalty of doing repeated message resets as the method of a bare-bones implementation of XEP-0301. I also should additionally cite this as part of this paragraph, that if it's done, it's a good idea to use stream compression, if available. So when done, the strategy isn't odd anymore :-) 3. Combine 6.4.3 and 6.4.4 to one section. 6.4.3 just describes a method that is not recommended, and does not specify a solution, so it suits better as introductory warning words. Use the title 6.4.3 Monitoring message changes. delete title 6.4.4 The only one I'd be cautious about is that 6.4.3 needs to be a distinct section; because it is less confusing to vendors trying to transmit from key press events; that way they can understand the gotchas of doing that (i.e. missed autospell fixes, missed copy+paste events, etc.) ... I've gotten feedback that gave an excellent rationale for 6.4.3 being part of 6.4 Thanks Mark Rejhon
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
On Mon, Jul 9, 2012 at 8:20 PM, Barry Dingle btdin...@gmail.com wrote: Mark, Really good job. My suggestions are mainly minor edits. Some (hopefully) improve the meaning. Barry, excellent job -- I've saved your list, too. It'll definitely reduce last call workload (if agreement is achieved with Section 5) Thanks, Mark Rejhon
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) - Odd strategies
Op 10/07/2012 17:32, Mark Rejhon schreef: On Tue, Jul 10, 2012 at 2:58 AM, Gunnar Hellström gunnar.hellst...@omnitor.se mailto:gunnar.hellst...@omnitor.se wrote: Mark, I see that you in this version have introduced a couple of odd real-time text transmission strategies in sections 6.4.1 and 6.4.2, based on the 'reset' event. http://xmpp.org/extensions/xep-0301.html#realtime_text_transmission_methodologies Gunnar -- several are excellent suggestions. An explanation at the beginning of 6.4 The transmission strategy in 6.4.1 and 6.4.2 is not recommended for messages bigger than approximately SMS size, for mobile devices that want to write very compact simple implementations of real-time text that does not require much processing or battery -- and they can take advantage of stream compression to eliminate the redundancy disadvantage of message resets. It was explained to me that it may actually use less bandwidth and less CPU in certain situations. Even though it means a disadvantage of losing key press intervals (the intervals demonstrated at www.realjabber.org/anim/real_time_text_demo.html http://www.realjabber.org/anim/real_time_text_demo.html ) which I already mention. I have found a information about larger sms : Message size Transmission of short messages between the SMSC and the handset is done whenever using the Mobile Application Part http://en.wikipedia.org/wiki/Mobile_Application_Part (MAP) of the SS7 http://en.wikipedia.org/wiki/Signaling_System_7 protocol. Messages are sent with the MAP MO- and MT-ForwardSM operations, whose payload length is limited by the constraints of the signaling protocol to precisely 140 octets http://en.wikipedia.org/wiki/Octet_%28computing%29 (140 octets = 140 * 8 bits = 1120 bits). Short messages can be encoded using a variety of alphabets: the default GSM 7-bit alphabet http://en.wikipedia.org/wiki/GSM_03.38, the 8-bit http://en.wikipedia.org/wiki/Bit data alphabet, and the 16-bit UCS-2 http://en.wikipedia.org/wiki/UCS-2 alphabet.^[35] http://en.wikipedia.org/wiki/Short_Message_Service#cite_note-3GPP_23.038-34 Depending on which alphabet the subscriber has configured in the handset, this leads to the maximum individual short message sizes of 160 7-bit http://en.wikipedia.org/wiki/Bit characters, 140 8-bit characters, or 70 16-bit characters. GSM 7-bit alphabet support is mandatory for GSM handsets and network elements,^[35] http://en.wikipedia.org/wiki/Short_Message_Service#cite_note-3GPP_23.038-34 but characters in languages such as Arabic, Chinese, Korean, Japanese or Cyrillic alphabet languages (e.g. Russian, Serbian, Bulgarian, etc.) must be encoded using the 16-bit UCS-2 http://en.wikipedia.org/wiki/UCS-2 character encoding http://en.wikipedia.org/wiki/Character_encoding (see Unicode http://en.wikipedia.org/wiki/Unicode). Routing http://en.wikipedia.org/wiki/Routing data and other metadata http://en.wikipedia.org/wiki/Metadata is additional to the payload size. *Larger content (concatenated SMS http://en.wikipedia.org/wiki/Concatenated_SMS, multipart or segmented SMS, or long SMS) can be sent using multiple messages, in which case each message will start with a user data header (UDH) containing segmentation information. Since UDH is part of the payload, the number of available characters per segment is lower: 153 for 7-bit encoding, 134 for 8-bit encoding and 67 for 16-bit encoding. The receiving handset is then responsible for reassembling the message and presenting it to the user as one long message. **While the standard theoretically permits up to 255 segments,^[36] http://en.wikipedia.org/wiki/Short_Message_Service#cite_note-35 6 to 8 segment messages are the practical maximum, and long messages are often billed as equivalent to multiple SMS messages.*
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) - Odd strategies
On Tue, Jul 10, 2012 at 11:58 AM, Edward Tie fam...@xs4all.nl wrote: I have found a information about larger sms : Edward, thanks -- but I'm already aware of this. Message Resets has no size limit, so implementers need to decide when too big is too big. I do warn about bandwidth issues in that paragraph already, so that is sufficient. The implementer is responsible for determining the maximum size of messages, as an implementation issue, and is beyond the scope of the protocol. P.S. We want to limit out-of-scope discussion, please. We're hogging the mailing list, and I'd like to refocus discussions. Thanks Mark Rejhon
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) - Odd strategies
On 2012-07-10 17:32, Mark Rejhon wrote: The only one I'd be cautious about is that 6.4.3 needs to be a distinct section; because it is less confusing to vendors trying to transmit from key press events; that way they can understand the gotchas of doing that (i.e. missed autospell fixes, missed copy+paste events, etc.) ... I've gotten feedback that gave an excellent rationale for 6.4.3 being part of 6.4 I found it strange, that 6.4 intended to be about real-time methodologies, and then 6.4.3 tells about a non-recommended method, but does not tell what to do instead. ( that is found in 6.4.4. ) I did want to start the advice in 6.4 subsections with something positive to follow in the normal case. Therefore 6.4.4 with added precaution in the beginning about why not using keypresses seemed to cause the best flow. But if you want, you could start with 6.4.4, changing a little in the beginning so that it does not refer to something earlier discussed. then follow on with 6.4.3 and add a conclusion at the end Therefore it is better to use change detection instead of keypresses. Then 6.4.1 and 6.4.2 Gunnar
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Op 09/07/2012 06:10, Mark Rejhon schreef: On Sat, Jul 7, 2012 at 7:53 PM, Peter Saint-Andre stpe...@stpeter.im mailto:stpe...@stpeter.im wrote: Hi Mark, Thanks for working so diligently to incorporate the mass of feedback you received recently. Given the scope of the changes, you might want to give folks more than just a few days to provide feedback before pushing out 0.4 (perhaps a week from now?). I know I plan to review it again this week. That would be fine -- I'll suggest that there's time until Friday, with a goal of submitting a Version 0.4 next week (July 16th) which will be the version that goes through LAST CALL. Cheers, Mark Rejhon I want to tell to you: older textphones uses DTMF-tonen. (not same as T.140) We have tested with old generation textphones that uses dtmf-tonen with VOIP. It works fine. but I think about converting from DTMF to XMPP..
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Hi Mark, I want to add on history of textphone and XMPP to old telephones that uses older protocols: Protocols There are many different textphone standards. Baudot code The original standard used by TTYs is the Baudot code http://en.wikipedia.org/wiki/Baudot_code implemented asynchronously at either 45.5 or 50 baud, 1 start bit, 5 data bits, and 1.5 stop bits. Baudot is a common protocol in the US. Turbo Code In addition to regular Baudot, the UltraTec http://en.wikipedia.org/w/index.php?title=UltraTecaction=editredlink=1 company implements another protocol known as Enhanced TTY, which it calls Turbo Code, in its products. Turbo Code has some advantages over Baudot protocols, such as a higher data rate, full ASCII http://en.wikipedia.org/wiki/ASCII compliance, and full-duplex capability. However, Turbo Code is proprietary, and UltraTec only gives its specifications to parties who are willing to license it. Other legacy protocols Other protocols used for text telephony are European Deaf Telephone (EDT) and Dual-tone multi-frequency signaling http://en.wikipedia.org/wiki/Dual-tone_multi-frequency_signaling (DTMF). The ITU V series recommendations are a collection of early modem standards approved by the ITU http://en.wikipedia.org/wiki/ITU in 1988. * ITU V.21 http://en.wikipedia.org/wiki/ITU_V.21 [1] http://www.itu.int/rec/T-REC-V.21/recommendation.asp?lang=enparent=T-REC-V.21-198811-I specifies 300 bits per second duplex mode. * ITU V.23 http://en.wikipedia.org/wiki/ITU_V.23 [2] http://www.itu.int/rec/T-REC-V/recommendation.asp?lang=enparent=T-REC-V.23 specifies audio frequency-shift keying http://en.wikipedia.org/wiki/Audio_frequency-shift_keying modulation to encode and transfer data at 600/1200 bits per second. V.18 In 1994 the ITU http://en.wikipedia.org/wiki/International_Telecommunication_Union approved the V.18 http://en.wikipedia.org/w/index.php?title=ITU_V.18action=editredlink=1 standard [3] http://www.itu.int/rec/T-REC-V.18/en. V.18 is a dual standard. It is both an umbrella protocol that allows recognition and interoperability of some of the most commonly used textphone protocols, as well as offering a native V.18 mode, which is an ASCII http://en.wikipedia.org/wiki/ASCII full- or half-duplex modulation method. Computers can, with appropriate software and modem, emulate a V.18 TTY. Some voice modems, coupled with appropriate software, can now be converted to TTY modems by using a software-based decoder for TTY tones. Same can be done with such software using a computer's sound card, when coupled to the telephone line. In the UK, a virtual V.18 network, called TextDirect, exists as part of the Public Switched Telephone Network http://en.wikipedia.org/wiki/Public_Switched_Telephone_Network, thereby offering interoperability between textphones using different protocols. The platform also offers additional functionality like call progress and status information in text and automatic invocation of a relay service for speech-to-text calls.
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Hi Edward, I understand about the need to educate people about the 'traditional' Textphone/TTY text protocols. However, I think that XEP-0301 should specify real-time text over XMPP only. We can put such interworking explanatory text in a separate 'Guideline' document. Something like the Framework document (RFC5194) for RFC4103 real-time text. Something is needed to discuss how to interwork between Textphone/TTYs that support text and/or voice with XEP-0301 plus voice in some form. Cheers, /Barry Barry Dingle Fixed - +61(0)3-9725-3937Mob - +61(0)41-911-7578 Fellow of University of Melbourne, Electrical and Electronic Eng., Australia Apple + Linux + Open Source software On Mon, Jul 9, 2012 at 4:05 PM, Edward Tie fam...@xs4all.nl wrote: Op 09/07/2012 06:10, Mark Rejhon schreef: On Sat, Jul 7, 2012 at 7:53 PM, Peter Saint-Andre stpe...@stpeter.imwrote: Hi Mark, Thanks for working so diligently to incorporate the mass of feedback you received recently. Given the scope of the changes, you might want to give folks more than just a few days to provide feedback before pushing out 0.4 (perhaps a week from now?). I know I plan to review it again this week. That would be fine -- I'll suggest that there's time until Friday, with a goal of submitting a Version 0.4 next week (July 16th) which will be the version that goes through LAST CALL. Cheers, Mark Rejhon I want to tell to you: older textphones uses DTMF-tonen. (not same as T.140) We have tested with old generation textphones that uses dtmf-tonen with VOIP. It works fine. but I think about converting from DTMF to XMPP..
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
On 2012-07-07 23:21, XMPP Extensions Editor wrote: Version 0.3 of XEP-0301 (In-Band Real Time Text) has been released. Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. Changelog: Edits recommended from public discussion. (MDR) Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.2/vs/0.3 URL: http://xmpp.org/extensions/xep-0301.html Mark, This looks good. I have some comments, but very few influence the protocol. So even if there are minor adjustments to do, the spec looks mature. These are my observations and propsals: 1. Chapter 1, last line: Move last sentence first. And make an empty line after it. Now it takes the whole chapter before we get to know what the specification is about. 2. Chapter 1, last bullet point. Change to: As one medium in Total Conversation, e.g. deployed in the European project REACH112 [5] for accessible communication and emergency service. Motivation: ( Total conversation was the theme. It was about both person-to-person and emergency service) 3. Section 2.1, point 4. add and replication after transmission. ( just transmission is not sufficient for the intended effect.) 4. Section 2.2, point 3. change traversal protocols to traversal mechanisms, because they are more mechanisms than protocols. 5. Section 2.4, Title. Change to Usable for mainstream and accessibility purposes. 6. Section 2.4, point 1. Change word accessibility to service description. Because F.703 is a general standard. The total conversation part is of accessibility interest. 7. Chapter 3, Real-time text. Change in real time to instantly , to match definition in chapter 1. 8. Chapter 3, Add JID and its explanation. 9. Section 4.1, second line. Add client after sender, to make it clear that the user dies not need to bother about transmission. 10. Section 4.1 Second paragraph. Change word live to in real-time to be consistent. 11. Section 4.1, Example 1, Line 9 , make the text part my Ju , so that it is obvious that it is not about word by word transmission. 12. Section 4.1, Example 1, Line 15 , make the text part liet only, so that it is obvious that it is not about word by word transmission. 13. Section 4.2.2 event='new' third line. change display, and then process to reception, and then process text and. Because we must not assume that all applications display the text. 14. Section 4.2.2 event='cancel'. How does this behave through multi-user chat and multiple login situations? Is the event='cancel' sent through to all? I see a risk that one user sending event='cancel' would turn off rtt for all recipients. If this is true, I see three solutions: a) Delete event='cancel'. b) Add a sentence saying event='cancel' SHALL not be used in a MUC or multi-login session. c) Add a sentence saying event='cancel' SHOULD be ignored in MUC and multi-login sessions. I have a slight preference for solution a), to delete cancel from the specification. If it is deleted, also the sections in 6.2.1 and 6.2.2 dealing with cancel shall be deleted. 15. Section 4.4, line 3, after F.700 insert usability requirement section A.3.2.1 so that the reader understands why this requirement exists and where to find it. 16. Section 4.4, line 3, after conversation, add in most network conditions. On GPRS, having 1.5 s network latency, the usability requirement will not be met, and that must be accepted. ( F.700 requires 2 seconds end-to-end for usable real-time text and 1 second for good real-time text. ) 17. Section 4.5, last word. Replace delivered with completed . 18. Consider deleting the Forward Delete d action element. It cannot be used with the default value for p because that would point outside the real-time message. Therefore, a p must always be calculated and included. Then it is equal in complexity to use it as Backspace. Having both just seem to add complexity to implementations. ( It would have been different and of value if it worked from a current cursor position.) But if you have good reasons, e.g. easily matching some editing operation result, you can keep it. 19. Section 4.5.2, third bullet point. I would like to see the words Unicode Code Points replace Unicode Character Counting. Code points is the safe base that we count. 20. Section 4.5.4.1 At the end, insert paragraph: Characters consisting of multiple Unicode code points SHOULD be sent together in the same t/ element. Values of /*p*/ and /*n*/ SHOULD NOT result in pointing within such combinations of code points.( this is to avoid the situations described with the long note to section 4.5.4.2. The actions to avoid it should be more on the sender side as I propose here. 21. Section 4.5.4.2 First paragraph, line 3. Delete the sentence starting In an ideal. There are different standard Unicode normalizations, so a receiver normalizing received Unicode that was normalized
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
On Mon, Jul 9, 2012 at 3:51 AM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: This looks good. I have some comments, but very few influence the protocol. So even if there are minor adjustments to do, the spec looks mature. Excellent comments, and the vast majority of your comments is useful -- most of your change will be implemented. I will address comments to the ones that needs further discussion: 5. Section 2.4, Title. Change to Usable for mainstream and accessibility purposes. The current heading is a single word: Accessible -- I prefer to keep it because it's correct, clear, and short. It catches attention of the accessibility people better, including the Access Board that has already contacted us, about the specification too. The word 'mainstream is also mentioned at end of section 1, also even in section 2.4, in section 6.2. I therefore believe that I've carefully balanced accessibility and mainstream, and satisfied both targets, while aiming to achieve the goal of eventually becoming an important part of future Accessibility standards. (That said, I'll fix the first bullet) 14. Section 4.2.2 event='cancel'. How does this behave through multi-user chat and multiple login situations? Is the event='cancel' sent through to all? I see a risk that one user sending event='cancel' would turn off rtt for all recipients. If this is true, I see three solutions: a) Delete event='cancel'. b) Add a sentence saying event='cancel' SHALL not be used in a MUC or multi-login session. c) Add a sentence saying event='cancel' SHOULD be ignored in MUC and multi-login sessions. 1. It is appropriate for a multi-login session; there is no issue with using the cancel during a multi-login -- it is completely appropriate for multi-login. (Regardless of whether or not you cancel before/after switching, and regardless of whether or not you reactivate before/after switching logins. All scenarios result in acceptable behavior.) 2. I already mention that it should not be used for MUC, in the MUC section: http://xmpp.org/extensions/xep-0301.html#multiuser_chat I have a slight preference for solution a), to delete cancel from the specification. If it is deleted, also the sections in 6.2.1 and 6.2.2 dealing with cancel shall be deleted. It is already optional. But some implementations need it. For example, one party clicks a button to turn off real-time text. This specific implementation requires ability to synchronize the disabiling of real-time text. How do we notify the other end of the intent to end a real-time text session? Example use case: - A party activates real-time text by pressing a button. - Both ends synchronize the enabling of real-time text via rtt event='start'/. - A party deactivates real-time text. - Both ends synchronize the disabling of real-time text via rtt event='cancel'/. Various methods of synchronizing activation/deactivation of real-time text is listed at: http://www.xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_texthttp://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text Certainly, not all implementations necessarily need to follow the above behaviour (maybe your implementation doesn't need it). However, there are other vendors that definitely need to be able to do this behaviour (after displaying a confirmation prompt) As a result, I cannot remove event='cancel' and deny the other vendors the ability to synchronize the disabling of real-time text. That said, unidirectional real-time text is allowed by XEP-0301, so synchronizing the enabling/disabling of real-time text is not a requirement, but some vendors require this ability (much like synchronizing enabling/disabling of audio/video after a confirmation prompt). I intend to respect both behaviours. 16. Section 4.4, line 3, after conversation, add in most network conditions. On GPRS, having 1.5 s network latency, the usability requirement will not be met, and that must be accepted. ( F.700 requires 2 seconds end-to-end for usable real-time text and 1 second for good real-time text. ) Technically you're right. I'll make this wording adjustment, since it is what F.700 says for technical compliance purposes. That said, real-world usability comment: I would like to comment that the innovation of encoding key press intervals ( http://www.realjabber.org/anim/real_time_text_demo.html ) gives an approximately 1.5x-2x multiplier to the maximum usable latency. i.e. a NRTT (Near-Real-Time-Text) bursty conversation with a 2 second latency, is more uncomfortable than an NRTT smooth conversation with a 3 second latency with key press intervals being encoded. That said, I'm speaking via real-world usability comments by actual users, as the RealJabber open source software has a tester's latency interval adjustment for usability trials that I have tried with several people. But I agree -- we need to be consistent with the F.700 definition of real-time
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
On Mon, Jul 9, 2012 at 2:09 AM, Edward Tie fam...@xs4all.nl wrote: Hi Mark, I want to add on history of textphone and XMPP to old telephones that uses older protocols: Hello Edward, Good history -- however, this is already beyond scope of XEP-0301. Anybody can create an XEP-0301 gateway that converts to almost anything (including any of the protocols you mention). One sentence will be added to satisfy this. http://xmpp.org/extensions/xep-0301.html#interoperability_considerations To just simply mention that ...a gateway can be built as a part of a complete solution (i.e. with optional audio, such as to support Voice Carry Over) to support any legacy protocols used by TTY and textphones using various protocols including Baudot, 300 baud ASCII, DTMF, ITU-T V.18, ITU-T V.22, and other text transmission protocols. (wording will be refined upon consultation within R3TF including Gregg Vanderheiden who helps out in this area) There was a lot of debate within our group (i.e. Gregg Vanderheiden) about the careful choice of wording, because we need to be sensitive about the complete solution (such as worldwide interoperability, the ability to use voice, accessibility to people who don't have Internet, etc). Protocols There are many different textphone standards. Baudot code The original standard used by TTYs is the Baudot codehttp://en.wikipedia.org/wiki/Baudot_codeimplemented asynchronously at either 45.5 or 50 baud, 1 start bit, 5 data bits, and 1.5 stop bits. Baudot is a common protocol in the US. Turbo Code In addition to regular Baudot, the UltraTechttp://en.wikipedia.org/w/index.php?title=UltraTecaction=editredlink=1company implements another protocol known as Enhanced TTY, which it calls Turbo Code, in its products. Turbo Code has some advantages over Baudot protocols, such as a higher data rate, full ASCIIhttp://en.wikipedia.org/wiki/ASCIIcompliance, and full-duplex capability. However, Turbo Code is proprietary, and UltraTec only gives its specifications to parties who are willing to license it. Other legacy protocols Other protocols used for text telephony are European Deaf Telephone (EDT) and Dual-tone multi-frequency signalinghttp://en.wikipedia.org/wiki/Dual-tone_multi-frequency_signaling(DTMF). The ITU V series recommendations are a collection of early modem standards approved by the ITU http://en.wikipedia.org/wiki/ITU in 1988. - ITU V.21 http://en.wikipedia.org/wiki/ITU_V.21 [1]http://www.itu.int/rec/T-REC-V.21/recommendation.asp?lang=enparent=T-REC-V.21-198811-Ispecifies 300 bits per second duplex mode. - ITU V.23 http://en.wikipedia.org/wiki/ITU_V.23 [2]http://www.itu.int/rec/T-REC-V/recommendation.asp?lang=enparent=T-REC-V.23specifies audio frequency-shift keyinghttp://en.wikipedia.org/wiki/Audio_frequency-shift_keyingmodulation to encode and transfer data at 600/1200 bits per second. V.18 In 1994 the ITUhttp://en.wikipedia.org/wiki/International_Telecommunication_Unionapproved the V.18http://en.wikipedia.org/w/index.php?title=ITU_V.18action=editredlink=1standard [3] http://www.itu.int/rec/T-REC-V.18/en. V.18 is a dual standard. It is both an umbrella protocol that allows recognition and interoperability of some of the most commonly used textphone protocols, as well as offering a native V.18 mode, which is an ASCII http://en.wikipedia.org/wiki/ASCIIfull- or half-duplex modulation method. Computers can, with appropriate software and modem, emulate a V.18 TTY. Some voice modems, coupled with appropriate software, can now be converted to TTY modems by using a software-based decoder for TTY tones. Same can be done with such software using a computer's sound card, when coupled to the telephone line. In the UK, a virtual V.18 network, called TextDirect, exists as part of the Public Switched Telephone Networkhttp://en.wikipedia.org/wiki/Public_Switched_Telephone_Network, thereby offering interoperability between textphones using different protocols. The platform also offers additional functionality like call progress and status information in text and automatic invocation of a relay service for speech-to-text calls.
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Op 09/07/2012 11:40, Mark Rejhon schreef: On Mon, Jul 9, 2012 at 2:09 AM, Edward Tie fam...@xs4all.nl mailto:fam...@xs4all.nl wrote: Hi Mark, I want to add on history of textphone and XMPP to old telephones that uses older protocols: Hello Edward, Good history -- however, this is already beyond scope of XEP-0301. Anybody can create an XEP-0301 gateway that converts to almost anything (including any of the protocols you mention). One sentence will be added to satisfy this. http://xmpp.org/extensions/xep-0301.html#interoperability_considerations To just simply mention that ...a gateway can be built as a part of a complete solution (i.e. with optional audio, such as to support Voice Carry Over) to support any legacy protocols used by TTY and textphones using various protocols including Baudot, 300 baud ASCII, DTMF, ITU-T V.18, ITU-T V.22, and other text transmission protocols. (wording will be refined upon consultation within R3TF including Gregg Vanderheiden who helps out in this area) There was a lot of debate within our group (i.e. Gregg Vanderheiden) about the careful choice of wording, because we need to be sensitive about the complete solution (such as worldwide interoperability, the ability to use voice, accessibility to people who don't have Internet, etc). it's now a clear history :-) Protocols There are many different textphone standards. Baudot code The original standard used by TTYs is the Baudot code http://en.wikipedia.org/wiki/Baudot_code implemented asynchronously at either 45.5 or 50 baud, 1 start bit, 5 data bits, and 1.5 stop bits. Baudot is a common protocol in the US. Turbo Code In addition to regular Baudot, the UltraTec http://en.wikipedia.org/w/index.php?title=UltraTecaction=editredlink=1 company implements another protocol known as Enhanced TTY, which it calls Turbo Code, in its products. Turbo Code has some advantages over Baudot protocols, such as a higher data rate, full ASCII http://en.wikipedia.org/wiki/ASCII compliance, and full-duplex capability. However, Turbo Code is proprietary, and UltraTec only gives its specifications to parties who are willing to license it. Other legacy protocols Other protocols used for text telephony are European Deaf Telephone (EDT) and Dual-tone multi-frequency signaling http://en.wikipedia.org/wiki/Dual-tone_multi-frequency_signaling (DTMF). The ITU V series recommendations are a collection of early modem standards approved by the ITU http://en.wikipedia.org/wiki/ITU in 1988. * ITU V.21 http://en.wikipedia.org/wiki/ITU_V.21 [1] http://www.itu.int/rec/T-REC-V.21/recommendation.asp?lang=enparent=T-REC-V.21-198811-I specifies 300 bits per second duplex mode. * ITU V.23 http://en.wikipedia.org/wiki/ITU_V.23 [2] http://www.itu.int/rec/T-REC-V/recommendation.asp?lang=enparent=T-REC-V.23 specifies audio frequency-shift keying http://en.wikipedia.org/wiki/Audio_frequency-shift_keying modulation to encode and transfer data at 600/1200 bits per second. V.18 In 1994 the ITU http://en.wikipedia.org/wiki/International_Telecommunication_Union approved the V.18 http://en.wikipedia.org/w/index.php?title=ITU_V.18action=editredlink=1 standard [3] http://www.itu.int/rec/T-REC-V.18/en. V.18 is a dual standard. It is both an umbrella protocol that allows recognition and interoperability of some of the most commonly used textphone protocols, as well as offering a native V.18 mode, which is an ASCII http://en.wikipedia.org/wiki/ASCII full- or half-duplex modulation method. Computers can, with appropriate software and modem, emulate a V.18 TTY. Some voice modems, coupled with appropriate software, can now be converted to TTY modems by using a software-based decoder for TTY tones. Same can be done with such software using a computer's sound card, when coupled to the telephone line. In the UK, a virtual V.18 network, called TextDirect, exists as part of the Public Switched Telephone Network http://en.wikipedia.org/wiki/Public_Switched_Telephone_Network, thereby offering interoperability between textphones using different protocols. The platform also offers additional functionality like call progress and status information in text and automatic invocation of a relay service for speech-to-text calls.
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
I think it is better to capture both audiences -- and not make this about just one group but I see how you want accessible to stand out how about Accessible - and mainstream too. Gregg Gregg Vanderheiden Ph.D. Director Trace RD Center Professor Industrial Systems Engineering and Biomedical Engineering University of Wisconsin-Madison Co-Director, Raising the Floor - International and the Global Public Inclusive Infrastructure Project http://Raisingthefloor.org --- http://GPII.net On Jul 9, 2012, at 11:26 AM, Mark Rejhon wrote: 5. Section 2.4, Title. Change to Usable for mainstream and accessibility purposes. The current heading is a single word: Accessible -- I prefer to keep it because it's correct, clear, and short. It catches attention of the accessibility people better, including the Access Board that has already contacted us, about the specification too. The word 'mainstream is also mentioned at end of section 1, also even in section 2.4, in section 6.2. I therefore believe that I've carefully balanced accessibility and mainstream, and satisfied both targets, while aiming to achieve the goal of eventually becoming an important part of future Accessibility standards. (That said, I'll fix the first bullet) smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Just reread that and it sounded a bit Jingo -y maybe Accessible features of use to Mainstream as well. And further discussion will be off list on this. Gregg Gregg Vanderheiden Ph.D. Director Trace RD Center Professor Industrial Systems Engineering and Biomedical Engineering University of Wisconsin-Madison Co-Director, Raising the Floor - International and the Global Public Inclusive Infrastructure Project http://Raisingthefloor.org --- http://GPII.net On Jul 9, 2012, at 1:02 PM, Gregg Vanderheiden wrote: I think it is better to capture both audiences -- and not make this about just one group but I see how you want accessible to stand out how about Accessible - and mainstream too. Gregg Gregg Vanderheiden Ph.D. Director Trace RD Center Professor Industrial Systems Engineering and Biomedical Engineering University of Wisconsin-Madison Co-Director, Raising the Floor - International and the Global Public Inclusive Infrastructure Project http://Raisingthefloor.org --- http://GPII.net On Jul 9, 2012, at 11:26 AM, Mark Rejhon wrote: 5. Section 2.4, Title. Change to Usable for mainstream and accessibility purposes. The current heading is a single word: Accessible -- I prefer to keep it because it's correct, clear, and short. It catches attention of the accessibility people better, including the Access Board that has already contacted us, about the specification too. The word 'mainstream is also mentioned at end of section 1, also even in section 2.4, in section 6.2. I therefore believe that I've carefully balanced accessibility and mainstream, and satisfied both targets, while aiming to achieve the goal of eventually becoming an important part of future Accessibility standards. (That said, I'll fix the first bullet) smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
One sentence will be added to satisfy this. http://xmpp.org/extensions/xep-0301.html#interoperability_considerations To just simply mention that ...a gateway can be built as a part of a complete solution (i.e. with optional audio, such as to support Voice Carry Over) to support any legacy protocols used by TTY and textphones using various protocols including Baudot, 300 baud ASCII, DTMF, ITU-T V.18, ITU-T V.22, and other text transmission protocols. (wording will be refined upon consultation within R3TF including Gregg Vanderheiden who helps out in this area) There was a lot of debate within our group (i.e. Gregg Vanderheiden) about the careful choice of wording, because we need to be sensitive about the complete solution (such as worldwide interoperability, the ability to use voice, accessibility to people who don't have Internet, etc). it's now a clear history :-) I agree with Mark. XEP-0301 is a protocol specification for XMPP, mainly on the transport level, and should not be loaded with too much info on other possibly related areas. But, since we already have that interoperability chapter, it can be extended with a sentence. I suggest this addition: 8.3 Textphones and TTYs in the PSTN (Informational) Real-time text is also implemented in the PSTN, through various text telephone modulation protocols specified in ITU-T V.18. It is possible to implement gateways between audio and XEP-0301 based real-time text in IP networks and textphones (called TTY in North America) based on V.18 or any of its Annexes in the PSTN. When designing such gateways, the limitations in speed, transmission direction, character sets and media simultaneity valid for these textphone protocols must be taken into consideration as well as the user need to be able to at least alternate between audio and real-time text during the call. Gunnar Protocols There are many different textphone standards. Baudot code The original standard used by TTYs is the Baudot code http://en.wikipedia.org/wiki/Baudot_code implemented asynchronously at either 45.5 or 50 baud, 1 start bit, 5 data bits, and 1.5 stop bits. Baudot is a common protocol in the US. Turbo Code In addition to regular Baudot, the UltraTec http://en.wikipedia.org/w/index.php?title=UltraTecaction=editredlink=1 company implements another protocol known as Enhanced TTY, which it calls Turbo Code, in its products. Turbo Code has some advantages over Baudot protocols, such as a higher data rate, full ASCII http://en.wikipedia.org/wiki/ASCII compliance, and full-duplex capability. However, Turbo Code is proprietary, and UltraTec only gives its specifications to parties who are willing to license it. Other legacy protocols Other protocols used for text telephony are European Deaf Telephone (EDT) and Dual-tone multi-frequency signaling http://en.wikipedia.org/wiki/Dual-tone_multi-frequency_signaling (DTMF). The ITU V series recommendations are a collection of early modem standards approved by the ITU http://en.wikipedia.org/wiki/ITU in 1988. * ITU V.21 http://en.wikipedia.org/wiki/ITU_V.21 [1] http://www.itu.int/rec/T-REC-V.21/recommendation.asp?lang=enparent=T-REC-V.21-198811-I specifies 300 bits per second duplex mode. * ITU V.23 http://en.wikipedia.org/wiki/ITU_V.23 [2] http://www.itu.int/rec/T-REC-V/recommendation.asp?lang=enparent=T-REC-V.23 specifies audio frequency-shift keying http://en.wikipedia.org/wiki/Audio_frequency-shift_keying modulation to encode and transfer data at 600/1200 bits per second. V.18 In 1994 the ITU http://en.wikipedia.org/wiki/International_Telecommunication_Union approved the V.18 http://en.wikipedia.org/w/index.php?title=ITU_V.18action=editredlink=1 standard [3] http://www.itu.int/rec/T-REC-V.18/en. V.18 is a dual standard. It is both an umbrella protocol that allows recognition and interoperability of some of the most commonly used textphone protocols, as well as offering a native V.18 mode, which is an ASCII http://en.wikipedia.org/wiki/ASCII full- or half-duplex modulation method. Computers can, with appropriate software and modem, emulate a V.18 TTY. Some voice modems, coupled with appropriate software, can now be converted to TTY modems by using a software-based decoder for TTY tones. Same can be done with such software using a computer's sound card, when coupled to the telephone line. In the UK, a virtual V.18 network, called TextDirect, exists as part of the Public Switched Telephone Network http://en.wikipedia.org/wiki/Public_Switched_Telephone_Network, thereby offering interoperability between textphones using different protocols. The platform also offers additional functionality like call progress and status
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Op 09/07/2012 13:12, Gunnar Hellström schreef: One sentence will be added to satisfy this. http://xmpp.org/extensions/xep-0301.html#interoperability_considerations To just simply mention that ...a gateway can be built as a part of a complete solution (i.e. with optional audio, such as to support Voice Carry Over) to support any legacy protocols used by TTY and textphones using various protocols including Baudot, 300 baud ASCII, DTMF, ITU-T V.18, ITU-T V.22, and other text transmission protocols. (wording will be refined upon consultation within R3TF including Gregg Vanderheiden who helps out in this area) There was a lot of debate within our group (i.e. Gregg Vanderheiden) about the careful choice of wording, because we need to be sensitive about the complete solution (such as worldwide interoperability, the ability to use voice, accessibility to people who don't have Internet, etc). it's now a clear history :-) I agree with Mark. XEP-0301 is a protocol specification for XMPP, mainly on the transport level, and should not be loaded with too much info on other possibly related areas. No. it's not clear enough. That are six a seven standaard different protocols. The developers must know what they uses all of protocols to build a whole gateway PSTN-SIP-XMPP But, since we already have that interoperability chapter, it can be extended with a sentence. I suggest this addition: 8.3 Textphones and TTYs in the PSTN (Informational) Real-time text is also implemented in the PSTN, through various text telephone modulation protocols specified in ITU-T V.18 *or V.22 or 300 baud ASCII or DTMF.* It is possible to implement gateways between audio and XEP-0301 based real-time text in IP networks and textphones (called TTY in North America) based on V.18*or V.22 or *any of its Annexes in the PSTN. When designing such gateways, the limitations in speed, transmission direction, character sets and media simultaneity valid for these textphone protocols must be taken into consideration as well as the user need to be able to at least alternate between audio and real-time text during the call. Gunnar
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
On 7/9/12 12:24 AM, Barry Dingle wrote: Hi Edward, I understand about the need to educate people about the 'traditional' Textphone/TTY text protocols. However, I think that XEP-0301 should specify real-time text over XMPP only. Yes, please. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
On 2012-07-09 13:31, Edward Tie wrote: 8.3 Textphones and TTYs in the PSTN (Informational) Real-time text is also implemented in the PSTN, through various text telephone modulation protocols specified in ITU-T V.18 *or V.22 or 300 baud ASCII or DTMF.* It is possible to implement gateways between audio and XEP-0301 based real-time text in IP networks and textphones (called TTY in North America) based on V.18*or V.22 or *any of its Annexes in the PSTN. When designing such gateways, the limitations in speed, transmission direction, character sets and media simultaneity valid for these textphone protocols must be taken into consideration as well as the user need to be able to at least alternate between audio and real-time text during the call. Edward, We shall not try to tell the whole story about PSTN text telephony (and TTY) in this XMPP document. I rather want to follow Peter's advice to reduce it. XEP-0301 has its important role as improvement of user experience of XMPP text messaging. Details on interoperability should be specified elsewhere. I suggest a very brief paragraph to be kept about legacy textphone interoperability. (coming soon) - Anyway, for your info, ITU-T V.18 has one annex for each of the legacy textphone protocols: Baudot (=TTY), V.21, DTMF, V.23(Minitel and even Prestel), Bell 103(ASCII), and even for V.18 itself. You wanted to add V.22 to the list. I know it is in use in The Netherlands, but The Netherlands never wanted it to be included in V.18. So, V.22 is not standardized anywhere as a textphone transport, and as I understand it, all Dutch V.22 textphones can also do automatic switching to DTMF based text telephony. Therefore mentioning V.18 or its annexes could be as far as we go here. ( if at all...) Gunnar
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Op 09/07/2012 16:30, Gunnar Hellström schreef: On 2012-07-09 13:31, Edward Tie wrote: 8.3 Textphones and TTYs in the PSTN (Informational) Real-time text is also implemented in the PSTN, through various text telephone modulation protocols specified in ITU-T V.18 *or V.22 or 300 baud ASCII or DTMF.* It is possible to implement gateways between audio and XEP-0301 based real-time text in IP networks and textphones (called TTY in North America) based on V.18*or V.22 or *any of its Annexes in the PSTN. When designing such gateways, the limitations in speed, transmission direction, character sets and media simultaneity valid for these textphone protocols must be taken into consideration as well as the user need to be able to at least alternate between audio and real-time text during the call. Edward, We shall not try to tell the whole story about PSTN text telephony (and TTY) in this XMPP document. I rather want to follow Peter's advice to reduce it. XEP-0301 has its important role as improvement of user experience of XMPP text messaging. Details on interoperability should be specified elsewhere. I suggest a very brief paragraph to be kept about legacy textphone interoperability. (coming soon) - Anyway, for your info, ITU-T V.18 has one annex for each of the legacy textphone protocols: Baudot (=TTY), V.21, DTMF, V.23(Minitel and even Prestel), Bell 103(ASCII), and even for V.18 itself. You wanted to add V.22 to the list. I know it is in use in The Netherlands, but The Netherlands never wanted it to be included in V.18. yes. it's true So, V.22 is not standardized anywhere as a textphone transport, and as I understand it, Only Dutch next generation textphone (HGT teksttelefoon) supports V.22 (1200) and V.22bis. It called TDD. See dutch summery: http://home.planet.nl/~hgtgm000/Downloads/TT_appendix_A_en_B.pdf all Dutch V.22 textphones can also do automatic switching to DTMF based text telephony. Yes. Dutch old generation textphones (Goedhart visicom and PTT teksttelefoon) supports only DTMF.
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
I propose a shorter section added to Interoperability, since it is listed as one of the Requirements (TTY alternative) in Section 2, so it is very prudent that I expand on how it's accomplished, by adding this section to Interoperability: *8.3 TTY and Textphones* *Real-time text is implemented in assistive telephone devices that operate on the PSTN (e.g. TTY in North America, textphone in Europe), using various text telephone modulation protocols such as those specified in ITU-T V.18 and its annexes (e.g. Baudot, DTMF). It is possible to implement gateways between them and XEP-0301 based real-time text, and can be combined with an audio protocol such as XEP-0166 (e.g. for Voice Carry Over). * It satisfies everyone concerns I hope, because: 1. Its first sentence is jargon-free 2. It is reasonably short. 3. I use various text modulation protocols to include any possible text modulation protocols, not just those in V.18 (I only use the phrase such as -- which keeps the door open to anything) 4. Any audio protocol may be used. 5. Further implementation details are left out of this; and best covered by a FAQ site (like the one I eventually plan to create) On Mon, Jul 9, 2012 at 10:57 AM, Edward Tie fam...@xs4all.nl wrote: Op 09/07/2012 16:30, Gunnar Hellström schreef: On 2012-07-09 13:31, Edward Tie wrote: 8.3 Textphones and TTYs in the PSTN (Informational) Real-time text is also implemented in the PSTN, through various text telephone modulation protocols specified in ITU-T V.18 *or V.22 or 300 baud ASCII or DTMF.* It is possible to implement gateways between audio and XEP-0301 based real-time text in IP networks and textphones (called TTY in North America) based on V.18* or V.22 or *any of its Annexes in the PSTN. When designing such gateways, the limitations in speed, transmission direction, character sets and media simultaneity valid for these textphone protocols must be taken into consideration as well as the user need to be able to at least alternate between audio and real-time text during the call. Edward, We shall not try to tell the whole story about PSTN text telephony (and TTY) in this XMPP document. I rather want to follow Peter's advice to reduce it. XEP-0301 has its important role as improvement of user experience of XMPP text messaging. Details on interoperability should be specified elsewhere. I suggest a very brief paragraph to be kept about legacy textphone interoperability. (coming soon) - Anyway, for your info, ITU-T V.18 has one annex for each of the legacy textphone protocols: Baudot (=TTY), V.21, DTMF, V.23(Minitel and even Prestel), Bell 103(ASCII), and even for V.18 itself. You wanted to add V.22 to the list. I know it is in use in The Netherlands, but The Netherlands never wanted it to be included in V.18. yes. it's true So, V.22 is not standardized anywhere as a textphone transport, and as I understand it, Only Dutch next generation textphone (HGT teksttelefoon) supports V.22 (1200) and V.22bis. It called TDD. See dutch summery: http://home.planet.nl/~hgtgm000/Downloads/TT_appendix_A_en_B.pdf all Dutch V.22 textphones can also do automatic switching to DTMF based text telephony. Yes. Dutch old generation textphones (Goedhart visicom and PTT teksttelefoon) supports only DTMF.
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
On 2012-07-09 17:05, Mark Rejhon wrote: I propose a shorter section added to Interoperability, since it is listed as one of the Requirements (TTY alternative) in Section 2, so it is very prudent that I expand on how it's accomplished, by adding this section to Interoperability: *8.3 TTY and Textphones* *Real-time text is implemented in assistive telephone devices that operate on the PSTN (e.g. TTY in North America, textphone in Europe), using various text telephone modulation protocols such as those specified in ITU-T V.18 and its annexes (e.g. Baudot, DTMF). It is possible to implement gateways between them and XEP-0301 based real-time text, and can be combined with an audio protocol such as XEP-0166 (e.g. for Voice Carry Over). * Good. Just one little modification. My view is that textphone or text telephone is the generic technical term for these devices. Then every country has their name for it. USA and Canada calls it TTY and mean then the TIA-825A equipped type. UK calls the same Minicom after the product name of the same. Italy calls their EDT equipped ones DTS . Switzerland calls them Schreibtelefon. France had Minitel, Sweden has Texttelefon, Denmark has Skrivtelefon, Holland has Schreibtelfon ( I think). Summary. Use TTY for the North American type and Textphone as the general term. I usually name TTY and Nrth America because Americans usually do not even realize that textphone is a wider used term for the same thing. I also recommend that we do not introduce the old term Voice Carry Over that will raise new questions among the ones not knowing accessible communication history. Therefore, I suggest some small modifications resulting in this: *8.3 Textphones (Including TTY) * *Real-time text is implemented in assistive text telephone devices that operate on the PSTN (called TTY in North America), using various text telephone modulation protocols such as those specified in ITU-T V.18 and its annexes (e.g. Baudot, DTMF). It is possible to implement gateways between them and XEP-0301 based real-time text, that can be combined with an audio protocol e.g. XEP-0166 (e.g. for alternating audio and text). * Gunnar
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text) - on cancel
On 2012-07-09 09:51, Gunnar Hellström wrote: 14. Section 4.2.2 event='cancel'. How does this behave through multi-user chat and multiple login situations? Is the event='cancel' sent through to all? I see a risk that one user sending event='cancel' would turn off rtt for all recipients. If this is true, I see three solutions: a) Delete event='cancel'. b) Add a sentence saying event='cancel' SHALL not be used in a MUC or multi-login session. c) Add a sentence saying event='cancel' SHOULD be ignored in MUC and multi-login sessions. I have a slight preference for solution a), to delete cancel from the specification. If it is deleted, also the sections in 6.2.1 and 6.2.2 dealing with cancel shall be deleted. I noticed now that there is mentioning of cancel and MUC in section 6.5.3.1. http://xmpp.org/extensions/xep-0301.html#multiuser_chat For rtt/ elements, the event #event attribute of 'init' or 'cancel' is not appropriate for MUC since they are intended for one-on-one use. However, I do not think it is sufficient, and doubt that it is correct: I see no problem with 'init' in the muc situation. So, I suggest that init is deleted. The current wording says is not appropriate for MUC. I suggest that that is sharpened up a bit to say: For rtt/ elements, the event #event attribute of 'cancel' SHALL NOT be sent during MUC sessions and shall be ignored on reception in such sessions since it could cause all rtt actions to cease. Also in the multiple login section 6.5.3.2 this must be mentioned: For rtt/ elements, the event #event attribute of 'cancel' SHALL NOT be sent during multiple login sessions and shall be ignored on reception in such sessions, since it could cause all rtt actions to cease. 4.2.2 I suggest that the non-use of 'cancel' in MUC and multiple login situations is mentioned already in section 4.2.2 Gunnar
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Good -- but also misses a major other user for real-time text, especially with elders, and that is captioning. Also for text one way and audio the next. Without making it much longer - we can include these important but often overlooked (in an attempt to be brief) methods of communication. Addition to what Gunnar Hellström wrote On Jul 9, 2012, at 5:24 PM, : 8.3 Textphones (Including TTY) Real-time text is implemented in assistive text telephone devices that operate on the PSTN (called TTY in North America), using various text telephone modulation protocols such as those specified in ITU-T V.18 and its annexes (e.g. Baudot, DTMF). It is possible to implement gateways between them and XEP-0301 based real-time text, that can be combined with an audio protocol e.g. XEP-0166 (e.g. for alternating audio and text or text one way and audio the other). 8.x Use for Captioned Telephony XEP-0301 based real-time text can be combined with an audio protocol e.g. XEP-0166 to provide captioned telephony and can interoperate via gateways with other IP-based captioned telephony protocols such as SIP VoIP with RFC 4103. smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Mark, Really good job. My suggestions are mainly minor edits. Some (hopefully) improve the meaning. My Numbers relate to the Section numbers. They have reasons with them where appropriate. = = = = *1.* (Edit) I think the last sentence should be a separate paragraph. (It is not really part of the paragraph it is in now. And it will highlight the sentence more which is needed.) *4.* We need to add some context before we dive into the detail. Add the following (before 4.1 heading): This specification is an extension of XMPP (*XMPP Core* [8]). It uses XMPP terminology. (To this point in the specification it implies the use of XMPP but it does not explicitly state it.) *4.1* (Edit) Last sentence (immediately before Section 4.2) Make the last sentence a new paragraph on its own. (It does not relate to sentence before it and it is a requirement that should be highlighted.) *4.2.1* (Edit) Add text to clarify meaning of last sentence of 2nd paragraph . . . to keep rtt/ compact, *but should allow for *plenty of incrementing room without overflow. *4.3* Clarify what happens in the 2nd sentence. The *content of the body/ element in the *delivered message is displayed instead of the *contents of the accumulated rtt/ elements of the*real-time text message. *4.5* Clarify 2nd sentence of 2nd paragraph by removing the words 'before sending' at the end of the sentence. The words removed are misleading when present as the real-time text has been sent. The inclusion of real-time text functionality to existing client software, needs to preserve the sender's existing expectation of being able to edit their messages. *4.5.4.1* (Edit) Last sentence. “It is noted *that* conversion of line breaks into a single LINE FEED . . . . “ *5.* 2nd last paragraph. Remove the word 'is' as it should not be there. “Enabling/disabling of discovery *is* SHOULD NOT be the default method of activating/deactivating real-time text.” ***6.2.1*In the first of the 4 bullet points – remove 'else' or remove 'as well' as this is repetitive. Question – Do we need Either of those terms? Can we remove both of them? In the 2nd bullet point, remove 'also'. *6.3* 2nd paragraph 1st sentence – remove the 2 commas as they are not needed. *6.4.1* (Add) 2nd sentence – state what needs to happen “. . . simply retransmitted every Transmission Interval *with event='reset'* whenever there are any text changes.” 3rd sentence – add 'example' - “The *example* below . . . ” *6.4.4.1* (Edit) 3rd bullet point – clarify and simplify end of sentence “If there are no changes to the real-time message, then no rtt/ element needs to be transmitted.” *6.4.4.2* (Edit) Spelling 'receiving' and remove the unnecessary 'that' - “in the order they are received.” *6.5.1* Last paragraph – remove plurals – change from “. . clients that sends” to “. . clients that send” from “. . when messages reaches” to “. . when messages reach” *6.5.4* Last paragraph - remove plurals 'resumes' and 'continues' “Senders that *resume* composing a message (i.e. *continue* a ” *6.5.5* 1st paragraph, 3rd sentence – remove plural “Real-time messages *need* to be updated . . ” *7.1* (Edit) Correct text after first message example. Change HLLO to HLL. The above code sends the misspelled *HLL*, then e/e/ backspaces 2 times, then sends HELLO. The 3 examples have the words “The above code . . .”. It is not *code*. All 3 cases should be changed to start with “The *example* above . . . “ ***7.2.2* 1st sentence - Change “The below example . . “ to “The example below . . “. Better English. *7.3.1* 2nd last sentence - We should not be referring to code here. Maybe try rewording the sentence like: “This is because the text *Hello Bob, this is Alice!* is output then *d n='4' p='5'/* deletes 4 characters from position 5.” (This improves consistency with explanatory text in other sections. ) *7.3.2* Same comment as 7.3.1 applies here with different details. *7.3.3* Same comment as 7.3.1 applies here with different details. *8*First paragraph – simplify wording to: “There are other real-time text standards. Interoperability between those standards and this specification may be required. For each environment where interoperability is supported, an interoperability specification needs to be documented that covers addressing, session control, media negotiation and media transcoding.” *8.2* 2nd paragraph – several small edits – see edited whole paragraph below. Change 'addressing' to 'address' ; remove unnecessary commas, add 'for' ; add 'processing' to indicate what is being referred to. “Interoperability implies *address* translation, media negotiation and translation, and media transcoding. For media transcoding between this specification and T.140/RFC 4103, the real-time text transcoding is straight forward except *for* the editing feature of this specification. Backwards positioning and insertion or
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
On Sat, Jul 7, 2012 at 7:53 PM, Peter Saint-Andre stpe...@stpeter.imwrote: Hi Mark, Thanks for working so diligently to incorporate the mass of feedback you received recently. Given the scope of the changes, you might want to give folks more than just a few days to provide feedback before pushing out 0.4 (perhaps a week from now?). I know I plan to review it again this week. That would be fine -- I'll suggest that there's time until Friday, with a goal of submitting a Version 0.4 next week (July 16th) which will be the version that goes through LAST CALL. Cheers, Mark Rejhon
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
On 7/8/12 10:10 PM, Mark Rejhon wrote: On Sat, Jul 7, 2012 at 7:53 PM, Peter Saint-Andre stpe...@stpeter.im mailto:stpe...@stpeter.im wrote: Hi Mark, Thanks for working so diligently to incorporate the mass of feedback you received recently. Given the scope of the changes, you might want to give folks more than just a few days to provide feedback before pushing out 0.4 (perhaps a week from now?). I know I plan to review it again this week. That would be fine -- I'll suggest that there's time until Friday, with a goal of submitting a Version 0.4 next week (July 16th) which will be the version that goes through LAST CALL. Seems reasonable, thanks! Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Regarding www.xmpp.org/extensions/xep-0301.html There were so many comments and suggestions that I decided a 0.3 interim was useful. I intend to publish a 0.4 in the next few days, hopefully just minor corrections, and possibly an extra usage example or two added. I will then request LAST CALL. Comments and suggestions? Did your concern get addressed? Any issues that I missed? Any areas that you would like to see clarified or improved? Thanks On 2012-07-07 5:18 PM, XMPP Extensions Editor edi...@xmpp.org wrote: Version 0.3 of XEP-0301 (In-Band Real Time Text) has been released. Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. Changelog: Edits recommended from public discussion. (MDR) Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.2/vs/0.3 URL: http://xmpp.org/extensions/xep-0301.html
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
Hi Mark, Thanks for working so diligently to incorporate the mass of feedback you received recently. Given the scope of the changes, you might want to give folks more than just a few days to provide feedback before pushing out 0.4 (perhaps a week from now?). I know I plan to review it again this week. Peter On 7/7/12 4:48 PM, Mark Rejhon wrote: Regarding www.xmpp.org/extensions/xep-0301.html http://www.xmpp.org/extensions/xep-0301.html There were so many comments and suggestions that I decided a 0.3 interim was useful. I intend to publish a 0.4 in the next few days, hopefully just minor corrections, and possibly an extra usage example or two added. I will then request LAST CALL. Comments and suggestions? Did your concern get addressed? Any issues that I missed? Any areas that you would like to see clarified or improved? Thanks On 2012-07-07 5:18 PM, XMPP Extensions Editor edi...@xmpp.org mailto:edi...@xmpp.org wrote: Version 0.3 of XEP-0301 (In-Band Real Time Text) has been released. Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. Changelog: Edits recommended from public discussion. (MDR) Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.2/vs/0.3 URL: http://xmpp.org/extensions/xep-0301.html
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
On Mon, Mar 19, 2012 at 2:17 PM, Mark Rejhon marky...@gmail.com wrote: Version 0.2 of XEP-0301 (In-Band Real Time Text) has been released. [snip] URL: http://xmpp.org/extensions/xep-0301.html [snip] ChangeLog Summary: [snip] - Add Multi-User Chat, Simultaneous Logins, Usage with Chat States, and several other sections From testing my RealJabber software (demonstration XEP-0301 client), in terms of Chat States http://xmpp.org/extensions/xep-0301.html#usage_with_chat_states XEP-0085 (http://xmpp.org/extensions/xep-0085.html) specifies not to transmit composing/ repeatedly. That said, many chat programs such as Google Talk (GMAIL) and Pidgin, Adium, etc, automatically assume active/ for any message/ transmitted without an XEP-0085 chat state. This is never properly clarified in XEP-0085 behaviour, about how to handle messages/ not containing a chat state and what assumptions may safely be made. Therefore, XEP-0301 recommends transmitting a composing/ with every message/ that contains a rtt/ but without body/ to maintain backwards compatibility with existing chat software. Short summary: message/ without body/ and without any XEP-0085 chat state update, are still automatically assumed as active/ (wrongly? or not?) by many existing software (i.e. GMAIL, Pidgin) which could be construed as wrong behaviour, but XEP-0085 does not seem to be directly clear about this specific situation. Since real-time text transmits message/ without body/ and with rtt/, and rtt/ is real time text of the typing being composed, this is a wrong assumption to say message/ without body/ is to be assumed to be an active/ state. A huge number of vendors seem to be doing this assumption, all the way from Pidgin thru GMAIL's Google Talk. It would be nice if XEP-0085 document can be updated to clarify in this area? Thanks, Mark Rejhon
Re: [Standards] UPDATED: XEP-0301 (In-Band Real Time Text)
On Mon, Mar 19, 2012 at 1:47 PM, XMPP Extensions Editor edi...@xmpp.orgwrote: Version 0.2 of XEP-0301 (In-Band Real Time Text) has been released. Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. Changelog: Lots of edits. Simplifications, improvements and corrections. Forward and backward compatible with version 0.1. (MDR) Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.1/vs/0.2 URL: http://xmpp.org/extensions/xep-0301.html ChangeLog Summary: Versus Previous Spec - Spec is approximately the same size. - Remains forward and backward compatible with v0.1 - Protocol is simplified and easier to read (5 fewer sections) - Implementation Notes is expanded (add some new sections) Noteworthy Protocol Level Changes - Eliminate g element (use XEP-0224 instead to do same thing). No compatibility impact. - Eliminate c element (use empty t instead, does the same thing). No compatibility impact. - Eliminate rtt event='start' (the first rtt of any kind can signal start). No compatibility impact. - Simplify: rtt event='cancel' (tells the remote end to stop sending rtt). No compatibility impact. - Simplify: Tier 1 and Tier 2 is merged into a single tier - Clarify: Redundancy methods is clearly outlined (based on my work with Next Generation 9-1-1 texting) - Change: RECOMMENDED transmission interval is now 0.7s. Range can be 0.3ms to 1s. (0.7s complies with ITU-T Rec. F.700 end-to-end, including network latency). (NOTE: 0.7s is only a very slight increase in bandwidth, still a *lot* less than XEP-0047 in-band bytestreams.) Other Changes - Many minor grammar corrections made throughout - Many improved wording throughout - Many removals of redundant info throughout - Error in Example 7.9 fixed, fix error in section 4.5.1.1 - Introduction and Requirements overhauled. - Requirements also now mention an important Accessibility section - Implementation Notes has been significantly expanded with new information and sections. - Add Multi-User Chat, Simultaneous Logins, Usage with Chat States, and several other sections - Eliminated Processing Rules because it contained redundant info elsewhere in the spec. I carefully embedded remaining parts elsewhere. - Sections Ensuring Accuracy Of Attribute Values and Unicode Character Counting - I removed all words cursor (except within Optional Remote Cursor and in examples). This makes the spec less daunting. - Merged Battery Life and Performance into Performance Efficiency - Shortened and improved Body Element section - Permit auto-send of long messages to Message Length Limit, which is useful for uninterrupted typing if RTT is enabled. - Additional methods of text presentation optimized for live captioning/transcription/relay services for the deaf. - Add Lower Precision Text-Smoothing Methods, useful for performance/battery/precision constrained situations - Add Time Critical And Low Latency Methods, useful for live captioning/transcription services - Next Generation 9-1-1 is now mentioned in Requirements. It is noteworthy that XEP-0301 is currently being tested in a Next Generation 9-1-1 demonstration program (text mesaging to phone number 911 for emergency), that is one of the programs being shown in front of FCC text-to-911 demonstration during March 28-29, at: http://www.fcc.gov/events/eaac-exhibition-fair-%E2%80%9Ctext-9-1-1%E2%80%9D-mobile-solutions Thanks, Mark Rejhon
