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

Gunnar Hellström gunnar.hellstrom at omnitor.se
Wed Aug 15 05:14:49 UTC 2012


Some comments on your comments included.
Issues where I find your proposals acceptable are deleted.

On 2012-08-13 17:29, Mark Rejhon 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:
>> 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
<GH>Right, I forgot about the informational chapter.
It sounds very strange with the "preferably" for a protocol element like 
this.  It does not match the stronger language of chapter 5.

The mentioning of discovery in 6.2 is in fact redundant. It is already 
described in chapter 5. Let us separate the topics into service 
discovery in chapter 5 and Activation in section 6.2
I suggest a change in 6.2.1:

s/Before sending real-time text, it is preferable for a sender client to 
explicitly discover whether the recipient client supports the protocol 
defined herein (using Determining Support <#determining_support>). In 
the absence of explicit discovery or negotiation, the sender client can 
implicitly request and discover the use of real-time text, by sending 
<rtt event='init'/> upon activation./The sender client can request the 
use of real-time text, by sending <rtt event='init'/> upon activation./
> 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?
My proposal to introduce nearly the same language for language variant 
handling in <rtt/> as in <body/> and the other elements containing 
natural language contents were mainly from the specification consistency 
point of view. I agree that it would require an application creating 
multiple language variants of real-time text for it them to go into the 
same <rtt/> element. ( I think the same is true for <body/>) .

I see no big risk in moving the moving the explicit xml:lang support to 
the <message/> level, and still only allow one explicit lang per message.

[proposal]
I can accept the solution to add the following paragraph to chapter 9. 
Internationalization:


The <rtt/> elements inherit the 'xml:lang' value of the <message/> 
element or an element farther up in the XML hierarchy. For handling of 
multiple language versions of the same XML stream, multiple sequences of 
<message/> stanza with <rtt/> elements need to be transmitted, each 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 [XMPP-CORE 
<imap://gunnar%2Ehellstrom%40omnitor%2Ese@imap.omnitor.se:143/fetch%3EUID%3E.INBOX%3E457827#ref-XMPP-CORE>]).


>> 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.
So conclusion is to remove.
>
>> 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.
>
15. Section 6.1.3.
>> [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.
Modified proposal

s/It is acceptable for senders with bursty output to immediately 
transmit word bursts of text without buffering./It is acceptable for 
senders with bursty output to immediately transmit word or phrase bursts 
of text without buffering as long as the mean interval between 
transmissions is not under the intended transmission interval./
>
>> 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)
OK, wait.
>
>> 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)
Right, I must have looked at the Diff. The reference is there properly.
>
>
>> 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 3] rename section 6.4.4 to "Real-time text by successive 
retransmissions."
>
> 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?)
I had a simple solution to 6.2.1 proposed above as well. So by accepting 
that and resolving the few outstanding agreements above it should be in 
good shape.

Thanks,
  Gunnar

>
> Thanks,
> Mark Rejhon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120815/df75cad7/attachment.html>


More information about the Standards mailing list