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/
