[Standards] UPDATED: XEP-0301 (In-Band Real Time Text)

Mark Rejhon markybox at gmail.com
Tue Aug 14 01:09:21 UTC 2012


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" <btdingle at 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:
>
> *<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 <markybox at 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.hellstrom at 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='juliet at example.com/balcony'
>> >  id='z94nb37h' to='romeo at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120813/527bfb9e/attachment.html>


More information about the Standards mailing list