On 2012-08-09 17:09, XMPP Extensions Editor wrote:
Version 0.7 of XEP-0301 (In-Band Real Time Text) has been released.
Abstract: This is a specification for real-time text transmitted in-band over
an XMPP session.
Changelog: Simplifications and grammatical corrections. Some sections (1, 6.2,
6.4) shortened with simpler language. (MDR)
Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.6/vs/0.7
URL: http://xmpp.org/extensions/xep-0301.html
Very good to see many of the discussed issues resolved in version 0.7.
Here are my findings in reviewing version 0.7.
-----------------------------------------------------------------------------------------------------------------------
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."
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/
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 ispreferable for a sender client
to/Before sending real-time text, a sender client SHALL/
4. Section 1, intro, last bullet point, to make the description of
REACH112 correct.:
c/A component within Total Conversation, used byReach112
<http://www.reach112.eu/>[4
<http://www.marky.com/realjabber/xep/xep-0301.xml#nt-idp11206912>] in
Europe, an accessible emergency service with real-time text./The
real-time text component within Total Conversation, for example used
byReach112 <http://www.reach112.eu/>[4
<http://www.marky.com/realjabber/xep/xep-0301.xml#nt-idp11206912>] in
Europe, a project for accessible communication services including
emergency service.
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.
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/
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./
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."
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/
11. Appendix A. A short name should be assigned.
[Discussion]
Some possible short names:
rtt, xmpp-rtt, real-time-text, xmpp-real-time-text
[Proposal]
real-time-text
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/TheReal-Time IM
<http://help.aol.com/help/microsites/microsite.do?cmd=displayKC&externalId=223568>[3
<http://xmpp.org/extensions/diff/api/xep/0301/diff/0.6/vs/0.7#nt-id142547>]
featurefound in AOL Instant Messenger./A real-time text feature found in
some instant messaging systems./
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.
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.
[proposal]
Add last in 4.2.3:
If 'id' is not recognized but a 'reset' with 'id' received by a
receiver, the contents should be accepted anyway and presented as a
correction.
15. Section 6.1.3.
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 bursts of text
without buffering as long as the time between transmissions is not
shorter than the intended transmission interval./
[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.
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.
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
[proposal] add reference to [18]
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.
I doubt that it should be included in the specification. The title is
misleading.
The specification does not need to describe all odd ways to use the
protocol. Implementers usually invent such ways anyway, and may use them
as long as they are within the limits of the protocol.
If this way to transmitting real-time text has many disadvantages.
It implies a risk that each rtt message gets very long. Thus it should
not be used with short transmission intervals. Wait elements cannot be
used, so for usable presentation it will rely on receiving clients
implementing time smoothing instead of keypress interval presentation,
otherwise the presentation will be unpleasantly jerky. Time smoothing
was mandated in early versions of this specification but is just
mentioned in this version, with no indication that there are situations
like this when it is essential for usability.
[proposal 1] Delete the section.
[proposal 2] if deletion is not accepted, rename section 6.4.4 to
"Retransmission of the changing real-time message."
19. Section 6.5 Receiver guidelines
[discussion]
Version 0.1 of this specification had in its "Receiver guidelines"
section the following point.
"If support for the <w> element is not possible, receiving software
SHOULD use an alternate text-smoothing method, such as time-smoothed
progressive output of received text."
This recommendation is not included in version 0.7. There are a couple
of very vague indications elsewhere that smoothing is possible, but no
clear recommendation.
Display of gradually growing text at 700 ms intervals create an
annoyingly jerky impression. Some smoothing is needed.
[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."
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]
[proposal]
Change reference to XMPP CORE [9] in 4.3.1 to XMPP IM [10]
--------------------------------
/Gunnar
___________________________________________________
Gunnar Hellström
Omnitor
gunnar.hellst...@omnitor.se
