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" <[email protected]> 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: > > *<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 <[email protected]> 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 >> <[email protected]> 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='[email protected]/balcony' >> > id='z94nb37h' to='[email protected]' 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 >> > >
