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.hellst...@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='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?
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%2...@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
