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: *<t>my J**</t>* and *<t>uliet!</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-3937 Mob - +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/M&M/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 > M&M 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 m&m/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 insertion a new subsection in 4.2 > > > ----------------------------------------------------------------------------------------------------------------------------------------------- > > 4.2.4 Language > > Multiple instances of the <rtt/> element MAY be included in a message > stanza > > for the purpose of providing alternate versions of the same real-time > text, > > but only if each instance possesses an 'xml:lang' attribute with a > distinct > > language value (either explicitly or by inheritance from the 'xml:lang' > > value of an element farther up in the XML hierarchy, which from the > sender's > > perspective can include the XML stream header as described in RFC 6220 [ > > ]). The support for language variants SHALL follow the principles of > support > > for language variants in message bodies specified in RFC 6221[ ]. > > > > This example provides a small part of real-time text in the default > language > > English and the alternative language Check. > > > > <message from='jul...@example.com/balcony' > > id='z94nb37h' to='ro...@example.net' type='chat' xml:lang='en'> > > <rtt xmlns='urn:xmpp:rtt:0' seq='89002'><t>tho</t></rtt> > > <rtt xmlns='urn:xmpp:rtt:0' seq='32304' xml:lang='cs'> <t>ty</t></rtt> > > </message> > > > > > -------------------------------------------------------------------------------------------------------------------------------------------------- > > The second line from the bottom of 4.1 should be changed from > > "There MUST NOT be more than one <rtt/> element per <message/> stanza." > > to > > "There MUST NOT be more than one <rtt/> element per language variant in > each > > <message/> stanza." > > [Comment] > My judgement is I'm going to leave this out because it is a > non-typical case of real-time text. People aren't going to send > multiple languages simultaneously, as people can't type in more than > one language simultaneously. It is an edge case that would be useful > for things like European Union transcriptions and/or United Nations > transcriptions. From what I can see, this edge case is easily > handled simply either by having separate <threads> for each language > (already recommended in last sentence of section 4.6) .... Each thread > can easily separately use one "xml:lang" each -- harmlessly -- without > xml:lang ever needing to be specified in XEP-0301 itself. Heck, > it's also possible to use separate nicknames for each languges, or > separate MUC rooms for each language, "TranscriptEN", "TranscriptFR", > etc. There's many solutions to cover the rare edge case of multiple > simultaneous language transcripts. > > I feel that this is: > (1) This is an ultra-rare edge case; > (2) This edge case does not warrant inflating the spec by 1/2 a page. > (3) The problem can be solved without things this way. > (4) It's simpler and more backwards compatible for clients to take > advantage of multiple languages, using the above method already > recommended within XEP-0301. Other techniques are possible too (e.g. > multiple nicks, multiple MUC rooms, etc) for multiple concurrent > languages. > (5) xml:lang can be used already, in the simpler and more backwards > compatible manner > > I am thinking that many others would agree that XEP-0301 can more > easily already be used with multiple languages (and without > complicating the spec for a majority), in a different manner. On top > of it, the techniques you describe is more complicated than > alternative methods of multiple-language transcripts. I would suspect > that even Kevin (who originally suggested you were right, and maybe > that is why you bring this up again right now), now agrees with this > assessment. I'd like to hear a comment from Kevin. > > Comments from others? > > > > 10. Appendix A, dependencies need updating. > > [Discussion] > > Dependencies: now only contain XMPP Core and XEP-0020. > > XEP-0020 seems not to be used anymore, but at least XMPP IM, XEP-0030, > > XEP-0085, XEP-0115, XEP-0308 > > > > [Proposal] > > Appendix A, dependencies, > > s/XMPP Core, XEP-020/XMPP Core, XMPP IM XEP-0030, XEP--0085, XEP-0115, > > XEP-0308/ > > > [Minor Clarification Change] > Thanks, I'll sync up the dependencies. > However, XEP-0085 isn't a dependancy (it doesn't even need to be used > at all), and XEP-0115 isn't needed either (if you use XEP-0030 Service > Discovery instead). But, yes, the dependencies still need to be > updated. > Note: Precedent shows that people generally typically leave out 0030 > and 0115, so I'll do the same. > > > > 11. Appendix A. A short name should be assigned. > > [Discussion] > > Some possible short names: > > rtt, xmpp-rtt, real-time-text, xmpp-real-time-text > > [Comment] > See section "12. XMPP Registrar Considerations" as "urn:xmpp:rtt:0" > The name will be based on that. > > > > 12. Chapter 1, 5th bullet point > > [Discussion] > > This point refers to a brand name AOL. I am not used to see brand name > > references in standards. I would guess that that tradition applies to > XEPs. > > if so: > > [Proposal] > > s/The Real-Time IM [3] feature found in AOL Instant Messenger./A > real-time > > text feature found in some instant messaging systems./ > > [Comment] > I kind of agree with you, though I'm divided about removing this > entirely, because it's the only mainstream program that currently has > real-time text, and is thus a good example. But I agree about removing > brand names, too. The existence of mainstream-but-proprietary support > is also a good argument to allow the extence of an open platform > support. But your change is doable. I think it's not an LC > showstopper, though. > > > > 13. Section 4.4, second line > > s/This interval meets/This interval provides an opportunity to meet/ > > [motivation] The F.700 requirement is for end-to-end latency ( that > provides > > the human experience). We cannot guarantee network delay. Therefore the > > interval is set so that there is a good opportunity to meet the > requirements > > in most network conditions. > > [Minor Clarification Change] > Queue change is: "This interval makes it possible to meet" > > > > 14. Section 4.2.3 id > > [discussion] > > It has just been revealed in the XEP-0308 discussions that there may be > > cases when the id is not recognized by the receiver. It may be a just > logged > > on receiver, or it may be a MUC server modifying id. Therefore add > caution > > for that situation. > > [Comment] > Good point, but I will wait until XEP-0308 is updated with handling of > unrecognized 'id'. > I plan to keep in sync with XEP-0308's recommendation. > Also, this does not seem to be an issue warranting action right now, > as reset is always accepted (one way or another) anyway. > > > > [discussion] > > Extra caution needs to be added so that a bursty output sender does not > > overwhelm a receiver or the network with too frequent packets. Text > sources > > such as speech-to-text and cut and paste can produce more than one word > per > > 700 ms and may therefore need to transmit more than one word per packet. > > [Comments] > All transcription engines I've seen, even with 300-400+ WPM speakers, > tend to output in sudden phrases at a time rather than a word, so > naturally, I will instead queue a minor edit "word or phrase bursts" > rather than "word bursts" > > Also consider: > (a) It will average out -- It's not harmful to have several sudden > bursts in short periods. > (b) I already specify a range of 300ms-1000ms. > (c) Even that range is only a recommendation, so you can go less than > 300ms. > (d) Vast majority of networks today can handle a higher stanza rate > (e) Implementers can figure out that they can optimize/combine to > lower the stanza rate during transcription output. > > > > 16. Section 6.2.1 Activation. > > [discussion] > > Close to the end of this section, there is a sentence saying: > > "It is inappropriate to send any further <rtt/> elements, until support > is > > confirmed". > > I wonder if there are any one-to-many situations with a very large > number of > > recipients when it is not appropriate to expect answers from all > recipients. > > If so, this sentence should be deleted. > > [Comment] > This is only applicable to one-on-one chat, not for MUC. > Also, there was someone complaining about unsolicited <rtt>, so the > sentence can't be removed. > It can be clarified or upgraded to a Business Rule, though. (with > proper normatives and clarifications) > However, I'll wait for general section 6.2 comments (see above) > > > > 17. Section 6.2.1 and 6.6.2 Missing reference to XEP-0085 > > There are three references to XEP-0085, none of them have the customary > > reference to the reference list and a link to the document. > > One is in section 6.2.1, two are in section 6.6.2 > > [Comment] > Two things: > XEP-0085 is "Chat State Notifications" ... Are you sure you are > referring to XEP-0085? > 1. Read again -- click the Refresh button -- the first reference is > there (section 6.2.1) > 2. By precedent, only the first reference is linked. This is > applicable for everything else (example: RFC4103, T.140 is linked only > on the first time) > > > > 18. Section 6.4.4 "Basic real-time text. > > [discussion] > > This is an odd way of transmitting real-time text by sending the whole > > real-time message in each transmission. > > [Comment] > I disagree: It is not odd; > (1) It is one of the most useful sections in XEP-0301 because it > illustrates that XEP-0301 is simpler than it looks; > (2) It is very easily rapid-prototypeable. It allows quick test > programs/demonstratable programs in advance of full implementations. > (3) It can be used with stream compression, to save bandwidth. (In > fact, if stream compression is used, it uses less bandwidth than all > the alternatives) > (4) Many proprietary real time text implementations, such as Bell > IP-Relay already use retransmits as their version of real time text. > If they don't feel like implementing the full XEP-0301, they should at > least support basic XEP-0301 -- I am leaving the door open to that. > (5) Clients have asked about this already. > > Yes, the loss of key press intervals is an important big disadvantage. > But I have already said that in that section, too. > > However, I have given extenuating rationale, of keeping this section > (which is not odd to begin with). For others, here's the link: > http://xmpp.org/extensions/xep-0301.html#basic_realtime_text > As it illustrates an easy use of XEP-0301. By reading this section, I > think it is pretty clear that it warrants inclusion. > > I also prefer to keep the section title, though other good suggestions > are welcome ("Simple Real Time Text", "Easy Real Time Text"). I don't > want to use a more complicated title name for this. I could add more > text as a caveat, such as "This form of real-time text is also useful > for quick prototypes", etc. But that's sounding too much of an > implementation note. > > > > [proposal] > > Reinstate the sentence last in section 6.5 adapted to the current > guideline > > language of that chapter: > > > > "If support for the <w/> element is not possible, receiving clients are > > recommended to use an alternate text-smoothing method, such as > time-smoothed > > progressive output of received text." > > [Implementation-Related Change Made] > Thanks, I've queued this change. > > > > 20. Section 4.3.1 Wrong reference > > [discussion] > > Section 4.3.1 says that <body/> is defined in XMPP CORE. It is instead > > defined in XMPP IM [10] > > [Minor Clarification Made] > Thanks, I've queued this change. > > > Thanks for all your suggestions, all of which are essentially minor > changes and mostly implementation-notes related. > With the exception of section 6.2, which warrants further discussion > (Kevin, M&M, Peter?) > > Thanks, > Mark Rejhon >
